ashwin_kanhere


I have an application which is providing printing facility using a custom hardware interface device.
Whenever a print is required user punches in his ID number into the hardware device, and hence an underlying application gets the event and it calls a managed DLL, which inturn calls the Reporting services webservice on the same server. Problem starts after some days (typically after 2 -3 days), when the server response becomes slow and the aspnet_wp.exe restarts every now and then and after this sequence of happening, finally it crashes with some event in application in event log which reads:
The server was unable to allocate from the system nonpaged pool because the pool was empty.

Also many times the applications log file reads :
There is an error in XML document (1, 948).
I think this error starts when the aspnet_wp.exe is restarting, but I am not sure.

The server operating system is Windows 2000 SP-4, MS SQL Server 2000 Standard Edition SP-4, MS Reporting Services 2000 Standard SP-2 with .Net Framework v1.1
The Server is running many applications apart from the ones listed above and there is a moderate usage of TCP/IP sockets for communicating with certain hardware devices.
Please help me out!




Re: aspnet_wp.exe crashing intermittently

ashwin_kanhere


After so many attempts, the problem came out to be with spoolsv.exe. This is the windows print spooler service. As soon as a print command is given from any application, the spoolsv.exe used to consume a part of the non-paged pool of Kernel Memory. But the real culprit I think is the HP TCP/IP Port, which is configured for the HP Printer.

The problem was found out by adding the pooled and non-pooled columns in the windows task manager. As soon as the print is spooled the non paged pool is consumed and is not released. And goes on accumulating until it reaches near to 253 MB and ultimately the scenario happens.

There is a bug in MS Winsock Library, which might be causing the HP Driver to show this kind of behaviour. Anyway the problem is temporarily solved by restarting the Print Spooler Service.