The debugger will indicate that there have been pool allocation failures if at some point the machine could not allocate pool memory. Is required for this to work successfully.įrom the server while it is in a problematic state or consuming high paged pool memory will confirm if MmSt is the responsible pool tag. It is the least intrusive method of accomplishing this. Process Explorer can be used live on the your machines to determine the maximum paged and nonpaged pool memory limits without needing to dump the machine. Depending on the maximum paged pool limit on the machine, this could be too much and cause the system to fail additional pool allocations. Mm section object prototype ptes, Binary: nt!mm The poolmon log should run until the symptoms occur, and should end up looking something like this: A poolmon log indicates how much pool memory is being used by all paged and nonpaged pool memory tags. Poolmon will be one of the primary tools you use to determine which pool tag is consuming most of the memory. LiveKD can be used to collect a memory dump without bugchecking the machine
Using poolmon.exe how to#
How to use Memory Pool Monitor (Poolmon.exe) to troubleshoot kernel mode memory leaksĭetermine if the trend is related to high file I/OĬheck if the system failed to allocate paged pool memory and which tags were using the most paged pool memoryĬheck the limits of the paged and nonpaged pool on the machineĬheck for memory mapped file usage and $MFT size (Note: runs on Vista+ OSes only) Indicates total paged pool usage and which tags are consuming the most
If it is in fact the MmSt tag causing the server to run out of paged pool memory then you will typically want to collect data to confirm this and find root cause. You will need to use a tool such as Poolmon, Process Explorer, a memory dump, or a LiveKD dump to first confirm that you have a paged pool issue, and second to determine if MmSt is the tag consuming most of the paged pool memory. Identifying the MmSt pool tag as the issue Large $MFT due to fragmentation or many files on the volume VSS (Volume Shadow Copy) snapshots aren’t dismounting
NSF files being stored on the server and opened over the network Heavy file I/O because too many files or large files are opened simultaneously The Memory Manager cannot trim paged pool memory quickly enough before allocations start failing Most Common Root Causes for high MmSt pool usage SQL backups or consistency checks performing heavy file I/O will fail to complete Users are unable to RDP or access file shares on the serverīackups or large file copies fail with insufficient resourcesĮrror 1450: Insufficient resources exist to complete the requested serverĮrror 1130: Not enough server storage is available to process this command The symptoms for issues dealing with high MmSt paged pool usage are common to most other paged pool depletion issues including:Įvent ID 333 - An I/O operation initiated by the Registry failed The Cache Manager should reduce its MmSt allocations when paged pool memory pressure occurs, but this may not always happen quickly enough to prevent some issues. MmSt allocations are most commonly seen when the system is under heavy file I/O and has many open files mapped into the memory cache. A prototype PTE is a structure that maps the physical location of a page or set of pages to a memory mapped file.
The MmSt pool tag is used by the Memory Manager when reserving memory for section prototype PTEs. This post is to go much further in depth to the use of this tag and common issues we see related to it.