Build a great reporting interface using Splunk, one of the leaders in the Security Information and Event Management (SIEM) field, linking the collected Windows events to www.eventid.net. The EventId.Net for Splunk Add-on assumes that Splunk is collecting information from Windows servers and workstation via the Splunk Universal Forwarder.
The server was unable to allocate from the system nonpaged pool because the pool was empty.
|English: This information is only available to subscribers. An example of English, please!|
If you have ever modified the SystemPages setting under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management (perhaps as suggested by ME304101 in response to delayed write failures) you may have unwittingly caused your memory pool problems all on your own (just as I did).
Entering a manual value in SystemPages can cause the OS to run out of paged pool memory, generating errors 2019 and 2021.
Even if you modified the SystemPages value with a new value, then set it back to the old value, you can still cause this error (just as I did.) The OS requires this setting to be 0, for automatic calculation. Setting it manually overrides the OS'' ability to automatically calculate a value. More info on the setting is here: T976159.
So, change SystemPages to 0 and restart the box, and your problem will disappear.
From a newsgroup post: "Open your registry and find the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters. Create a new DWORD value, or modify the existing value, named "IRPstackSize" and set it to equal the required stack size between 1 and 12, the default is 4. Restart Windows for the change to take effect". See the link to EV100076 - "Change the IRP Stack Size" for more details.
As per Microsoft: "This problem may occur when the Single Instance Storage driver (Sis.sys) leaks the NtFC nonpaged pool memory while the driver processes an alternative stream. This alternative stream may be generated by a third-party program". See ME950310 for a hotfix applicable to Microsoft Windows Server 2003.
This problem occurs because the DFS service does not manage the allocated nonpaged pools very well. When allocated nonpaged pools are not managed well, memory leaks may occur. The DFS domain root server stops responding because the system nonpaged pool is empty. See ME938666 for a hotfix applicable to Microsoft Windows Server 2003.
This issue may occur because a Microsoft Windows Management Instrumentation (WMI) provider or a third-party WMI provider exceeds values that are set for the MemoryPerHost or HandlesPerHost properties. These values are defined in the __ProviderHostQuotaConfiguration class of the root namespace. See ME895477 for a hotfix applicable to Microsoft Windows Server 2003 and Microsoft Systems Management Server 2003.
This event might occur when you run a custom Winsock network program that uses the Winsock Select function. See ME917114 for a hotfix applicable to Microsoft Windows Server 2003.
If you receive this event with Norton AntiVirus for Windows NT (NAVNT) and Auto-Protect running, see the link to "Symantec Knowledge Base Document ID: 1999048654612044".
If you have an Intel network adapter, see WITP79049.
See ME293857, ME912376, ME923360, ME933999, ME947476, WITP71861, WITP74899, and WITP74726 for additional information about this event.
I used the memsnap tool to diagnose my problem, which I found to be more useful than poolmon. Try running the following commands:
memsnap /m memsnap.log
memsnap /a memsnap.log
Memsnap led me to spoolvs.exe as the problem. I then turned off the print spool to confirm it as the problem. In the end, the problem turned out to be caused by a third-party process by Canon, which was leaking memory. See the link to "Memsnap Overview" for information on this tool.
According to ME821546, this problem has been identified as an issue that affects Visual Basic 6.0 n-Tier applications that are using COM+ packages that have been exported as an "Application Proxy" and installed on a client "Citrix" server. The "Authenticated Users" group must be given the "Impersonate a client after authentication" user right. This can be achieved in Administrative Tools -> Local Security Policy -> Local Policies -> User Rights Assignment.
Without the right the "Services.exe" process (which runs the COM+/DCOM sub system) will start to eat up Non-Paged Pool memory until it is gone, causing the Server to quit responding. This error is logged to the system event log.
To resolve this issue, identify the user account that is used to run the AFS Packages, and then assign the "Impersonate a client after authentication" user right to that user account. To do this, follow these steps:
1. Click Start, point to Programs, point to Administrative Tools, and then click Local Security Policy.
2. Expand Local Policies, and then click User Rights Assignment.
3. In the right pane, double-click Impersonate a client after authentication.
4. In the Local Security Policy Setting dialog box, click Add.
5. In the Select Users or Group dialog box, click the user account that you want to add, click Add, and then click OK. (Adding the user group "Authenticated Users" fixed our issue.
6. Click OK.
This issue is commonly misdiagnosed, however, 90% of the time it is actually quite possible to determine the resolution quickly without any serious effort at all. See the link to "Understanding Pool Consumption and Event ID: 2020 or 2019" for more information.
In my case, on Windows Server 2003 SP1, enabling the Indexing Service gave me this error. Disabling it solved this problem.
If you received this error after you installed Symantec AntiVirus Corporate Edition 10.0 or Symantec Client Security 3.0, see "Symantec Knowledge Base Document ID: 2005082910334448".
In my case, this problem occured after installing the HP2430DTN printer. Reloading Printer Drivers for PCL 5E & PCL 6 as suggested by HP did not help. Shutting down the print spool service and restarting it solved the problem.
See ME886226 for a hotfix applicable to Microsoft BizTalk Server 2004.
See ME887598 for a hotfix applicable to Microsoft Windows 2000.
See ME888928 if you are using McAfee VirusScan Enterprise 8.0i.
Your Windows 2000-based server may start to run very slowly, and it may eventually stop responding (hang). See ME833266 to find out why this happens.
If you are using ISA Server then you should look at ME321844.
A computer that is running Windows 2000 Server or Windows 2000 Advanced Server with the 3Com 1807 hardware driver or 3Com port driver (3c1807.sys) may experience this problem. See ME312021 to find out how to fix this problem.
If you are running Norton Antivirus 2000 suite on Windows 2000, this may be the cause of your problem. Users have reported that removing the Antivirus has helped them to get rid of this error. Try to install a newer version of NAV.
This problem might occur because of a memory leak in the code of the Volume Shadow Copy Service backup infrastructure. See ME826751 for a hotfix.
Check ME822219 for additional information on fixing this error.
You can also use the Memory Pool Monitor (Poolmon.exe) from Microsoft to troubleshoot kernel mode memory leaks.
From a newsgroup post: "We had exactly the same problem several months ago. It was our main SQL server, so when we could not find the solution we placed a call to Microsoft. They told us that the article ME133384 does apply to NT4.0, not just to 3.51. In our case, it turned out that “ARCServe” was not freeing up memory after running a backup every night, so that was the source of our leak. Follow the instructions in ME133384 and you will find your culprit".
From a newsgroup post: "After using MemTriage I tracked the problem down to the Promise Array Management software (PAM). PAM consists of two server processes msgsvr.exe and msgagt.exe. One of these was continuously allocating memory but never releasing any back. I've uninstalled the Promise s/w and the NP Pool usage is now pretty constant. The version of PAM that caused this is 3.2.1, build 13".
See McAfee Solution ID kb45505 for a patch from McAfee. Go to the McAfee Knowledge Search page and search for this solution to read it.
See ME320298 and the link to "EventID 2019 from source NCP Server" for more details on this event.
See the link to WITP71861 and "MonitorWare Support" for information about this event.
This could happen when using VMware ESX Server 2.x running Windows 2003 or Windows XP guests. There is a patch available to solve the problem. See the link to “VMware Support Answer ID 1549” for further details on this issue.
I recently went rounds trying to troubleshoot this issue. None of the solutions worked for my server. The problem ended up being the cache on our SAN. One of the drives went out, which apparently disabled the cache for the SAN. We have an EMC FC4700. After determining the problem was that I/O's were backing up because the disk system couldn't fill the requests quickly enough, I decided to take a look at our SAN even log. Sure enough, one of the drives was offline. After replacing the drive, the system returned to a normal state. Article ME317249 was helpful, but ultimately, I had to find the component responsible for the I/O backup. For those encountering this problem, it would be worthwhile checking cache for RAID or SAN devices and ensure the disk subsystem is in an optimal state.
As per Microsoft: "A memory leak may occur in an application that uses the Volume Shadow Copy service on a computer that is running Microsoft Windows Server 2003. This problem occurs because of a memory leak in cryptographic services (Cryptsvc.dll). Any application that is using cryptographic services, such as the Volume Shadow Copy service, may experience this problem". I experienced this problem using Veritas Backup Exec. Installing the hotfix ME870973 will resolve this problem.
I got this error on one of my DCs with Windows 2000 SP4. The problem turned out to be a memory leak in the TDI driver from McAfee VirusScan Enterprise 8.0.0.i. A memory leak occurred in non-paged pool memory when accessing files via the network redirector. The TDI driver did not released memory that had been allocated for identifying Source IP information. See the link to “Network Associates Support Solution ID: KB38267” for details on fixing this issue.
Under certain circumstances, heavy usage of particular programs can cause non-paged pool memory to become exhausted. This can happen due to various reasons. Some of these problems are fixed by Windows 2000 Service Pack 2. See the links below for some examples.
See ME317249 on how to troubleshoot this type of events as they typicall occur when the Server service cannot process the requested network I/O items to the hard disk quickly enough to prevent the Server service from running out of resources.
As per ME226513, this may be caused by a Memory Leak within the Server service. It should've been fixed by SP 6.
As per Microsoft: "Nonpaged pool pages cannot be paged out to the Paging File, but instead remain in main memory as long as they are allocated. An application is probably incorrectly making system calls and using up all allocated nonpaged pool. You might also see the following error on a local or remote system: Not enough storage available to process this command.
To find the faulty application, use the Performance Monitor to look at each
application's nonpaged pool allocation. As an alternative, monitor the system with a utility such as PMON.EXE from the Windows 2000 Resource Kit."
As per Microsoft: "This behavior can occur because the kernel-mode tag, Dynamic Access Protocol version 4 (DAP4), is leaking memory. This tag is provided by 3com. The tag is a driver that is loaded into the computer for the 3Com 3C980C-TXM network adapter.". See ME294346
In Microsoft Small Business Server 2000 the windows proxy service leaks memory when a USRobotics PCI 56K faxmodem is installed with the drivers from the box. On a system with 512meg of ram it takes about 15 hours for the nonpaging pool to be exhausted. Downloading updated drivers from the USR web site seems to fix the problem.
See ME130926 - Using Performance Monitor to Identify a Pool Leak
I got this error on one of my DC with Windows 2k SP3. I got a Memory Leak which was caused by Open File Manager 7.x (see the service OFMNT.exe using pmon.exe). This program is supposed to allow the backup of open files. Since I stopped this service, I have no more this problem. The new version 8.1 of OFM behaves without creating a memory leak which leaves you the choice to upgrade or uninstall OFM 7.x.
|Private comment: Subscribers only. See example of private comment|
|Links: Symantec Knowledge Base Document ID: 1999048654612044, Symantec Knowledge Base Document ID: 2005082910334448, Network Associates Support Solution ID: KB38836, Memtriage.exe: Resource Leak Triage Tool, VMware Support Answer ID 1549, EventID 2019 from source NCP Server, MonitorWare Support, McAfee Knowledge Search, Understanding Pool Consumption and Event ID: 2020 or 2019, Memsnap Overview, Memory Management - Understanding Pool Resources|
|Search: Google - Bing - Microsoft - Yahoo - EventID.Net Queue (4) - More links...|
|Custom search for *****: Google - Bing - Microsoft - Yahoo|
Send comments or solutions
- Notify me when updated