bsod - csrss.exe

[MagicAndre1981]

your nonpaged pool is used too much:

	NonPagedPool Usage:    65534 (    262136 Kb)
	NonPagedPool Max:      65536 (    262144 Kb)

I can't see which tag is causing it:

unable to get PoolTrackTable - pool tagging is disabled, enable it to use this command

Use gflags.exe and check the box that says "Enable pool tagging"

So you have to download the Debugger and enable the the option "Enable pool tagging" or run this:

gflags /r +ptg

now create a new dump, compres the dump with 7-zip (http://sourceforge.net/projects/sevenzip/files/7-Zip/9.20/) as 7z file with ULTRA compression and upload it to mediafire:

http://www.mediafire.com/

André

Why are all those is360.exe running? Do you need this program? If not remove it.

[cluberti]

There it is - nonpaged pool is almost 100% used:

0: kd> !vm

*** Virtual Memory Usage ***
	Physical Memory:      851723 (   3406892 Kb)
	Page File: \??\C:\pagefile.sys
	  Current:   2095104 Kb  Free Space:   1846332 Kb
	  Minimum:   2095104 Kb  Maximum:      4190208 Kb
	Available Pages:      593384 (   2373536 Kb)
	ResAvail Pages:       754659 (   3018636 Kb)
	Locked IO Pages:          43 (       172 Kb)
	Free System PTEs:     125876 (    503504 Kb)
	Free NP PTEs:              0 (         0 Kb)
	Free Special NP:           0 (         0 Kb)
	Modified Pages:          448 (      1792 Kb)
	Modified PF Pages:       448 (      1792 Kb)
	NonPagedPool Usage:    65534 (    262136 Kb)
	NonPagedPool Max:      65536 (    262144 Kb)
	********** Excessive NonPaged Pool Usage *****
	PagedPool 0 Usage:      9209 (     36836 Kb)
	PagedPool 1 Usage:      1122 (      4488 Kb)
	PagedPool 2 Usage:      1075 (      4300 Kb)
	PagedPool 3 Usage:      1090 (      4360 Kb)
	PagedPool 4 Usage:      1088 (      4352 Kb)
	PagedPool Usage:       13584 (     54336 Kb)
	PagedPool Maximum:     92160 (    368640 Kb)

	********** 434 pool allocations have failed **********

	Session Commit:         1958 (      7832 Kb)
	Shared Commit:         57142 (    228568 Kb)
	Special Pool:              0 (         0 Kb)
	Shared Process:         4826 (     19304 Kb)
	PagedPool Commit:      13584 (     54336 Kb)
	Driver Commit:          4313 (     17252 Kb)
	Committed pages:      250189 (   1000756 Kb)
	Commit limit:        1334017 (   5336068 Kb)

0: kd> !poolused 1
unable to get PoolTrackTable - pool tagging is disabled, enable it to use this command
Use gflags.exe and check the box that says "Enable pool tagging".

It says pool tagging is disabled, so I would check that - but this is enabled by default in XP, so this error could be in fact because at the time of the dump the memory that contains this information is corrupt - assuming pool tagging is enabled, this is a likely source. However, we can use poolmon now that we're sure it's running out of nonpaged pool to "catch the thief" without resorting to crashing the box.

1. Download poolmon3vbs.zip from here
   
2. Extract this zip file to C:\Poolmon3
   
3. Double click C:\Poolmon3\_LogPool-as-a-service.cmd to start logging
   

This should start a cmd prompt and start dumping log files to C:\Poolmon3. Let this run for about 24 hours, and then run C:\Poolmon3\_RemovePoolmon3service.cmd to stop the logging. Zip and upload the contents of C:\Poolmon3 so we can see what's happening.

[dorddor]

There it is - nonpaged pool is almost 100% used:

0: kd> !vm

*** Virtual Memory Usage ***
	Physical Memory:      851723 (   3406892 Kb)
	Page File: \??\C:\pagefile.sys
	  Current:   2095104 Kb  Free Space:   1846332 Kb
	  Minimum:   2095104 Kb  Maximum:      4190208 Kb
	Available Pages:      593384 (   2373536 Kb)
	ResAvail Pages:       754659 (   3018636 Kb)
	Locked IO Pages:          43 (       172 Kb)
	Free System PTEs:     125876 (    503504 Kb)
	Free NP PTEs:              0 (         0 Kb)
	Free Special NP:           0 (         0 Kb)
	Modified Pages:          448 (      1792 Kb)
	Modified PF Pages:       448 (      1792 Kb)
	NonPagedPool Usage:    65534 (    262136 Kb)
	NonPagedPool Max:      65536 (    262144 Kb)
	********** Excessive NonPaged Pool Usage *****
	PagedPool 0 Usage:      9209 (     36836 Kb)
	PagedPool 1 Usage:      1122 (      4488 Kb)
	PagedPool 2 Usage:      1075 (      4300 Kb)
	PagedPool 3 Usage:      1090 (      4360 Kb)
	PagedPool 4 Usage:      1088 (      4352 Kb)
	PagedPool Usage:       13584 (     54336 Kb)
	PagedPool Maximum:     92160 (    368640 Kb)

	********** 434 pool allocations have failed **********

	Session Commit:         1958 (      7832 Kb)
	Shared Commit:         57142 (    228568 Kb)
	Special Pool:              0 (         0 Kb)
	Shared Process:         4826 (     19304 Kb)
	PagedPool Commit:      13584 (     54336 Kb)
	Driver Commit:          4313 (     17252 Kb)
	Committed pages:      250189 (   1000756 Kb)
	Commit limit:        1334017 (   5336068 Kb)

0: kd> !poolused 1
unable to get PoolTrackTable - pool tagging is disabled, enable it to use this command
Use gflags.exe and check the box that says "Enable pool tagging".

It says pool tagging is disabled, so I would check that - but this is enabled by default in XP, so this error could be in fact because at the time of the dump the memory that contains this information is corrupt - assuming pool tagging is enabled, this is a likely source. However, we can use poolmon now that we're sure it's running out of nonpaged pool to "catch the thief" without resorting to crashing the box.

1. Download poolmon3vbs.zip from here
   
2. Extract this zip file to C:\Poolmon3
   
3. Double click C:\Poolmon3\_LogPool-as-a-service.cmd to start logging
   

This should start a cmd prompt and start dumping log files to C:\Poolmon3. Let this run for about 24 hours, and then run C:\Poolmon3\_RemovePoolmon3service.cmd to stop the logging. Zip and upload the contents of C:\Poolmon3 so we can see what's happening.

i uploaded the output folder of the poolmon3 as u asked for:

http://www.mediafire.com/?w76pqod7f72ikj1

i hope it will help

thanks

[cluberti]

Something on this machine is leaking process and thread handles - the tags "Proc" and "Thre" (for process and thread object handles, respectively) are increasing in a steady climb over the time this was taken, so I'm going to go back to your .dmp file to see if I can pinpoint any handle or process object leaks there. It is worth noting that there are two processes, according to the spreadsheet this tool creates, that are *very* active during the time the leak is happening - is360srv.exe and SYSTEM. Given that IOBit probably has a kernel driver on top of it's service, this application is suspicious. The system is also showing a steady - small, but steady increase in MmSt, which is the tag you'd see if there was heavy activity on the disk or in memory, for example (moreso than just your everyday usage - it would ebb and flow, rather than show a steady increase with no real step down afterwards). I also see a fairly hefty leak in handles in is360srv.exe when looking at the process data spreadsheet, which also corresponds almost 100% with the Proc and Thre tag leak, making it my suspicious offender thus far. It will take some time to figure for sure from the .dmp (now that I know what I'm looking for), but this is the likely culprit going on my experience with this sort of behavior and what sort of thing causes these particular tags to leak (processes consuming and not releasing handles, probably to process and thread objects).

Edit - yes, the dump shows is360.exe with *many* orphaned processes - there's a PEB, but there's no handle count and no threads. IOBit is the culprit here.

Edited December 5, 2010 by cluberti
Updated with dump information