I mostly do kernel debugging, so I’m not as familiar with process stuff, so please educate me.
I did “!vm” with one of my crash dumps and in the process list, I see a bunch of these:
2540 VNIVXMLServerD. 0 ( 0 Kb)
Now, that’s one of our processes, but there were about 150 of them. I did see that we had problems starting it, so it really was restarted many times. So, that explains why it’s there many times, but since it’s in the “!vm” list, does that mean that the process is still around?
I then did “!process” on it, and it isn’t clear to me that it is still “running” or not.
PROCESS 85e99078 SessionId: 0 Cid: 2540 Peb: 7ffd4000 ParentCid: 1e1c
DirBase: 7dffc880 ObjectTable: 00000000 HandleCount: 0.
Image: VNIVXMLServerD.exe
VadRoot 00000000 Vads 0 Clone 0 Private 1. Modified 1267. Locked 0.
DeviceMap 88208800
Token 8829e860
ElapsedTime 59 Days 11:07:11.833
UserTime 00:00:00.046
KernelTime 00:00:00.093
QuotaPoolUsage[PagedPool] 0
QuotaPoolUsage[NonPagedPool] 0
Working Set Sizes (now,min,max) (6, 50, 345) (24KB, 200KB, 1380KB)
PeakWorkingSetSize 14696
VirtualSize 89 Mb
PeakVirtualSize 92 Mb
PageFaultCount 14914
MemoryPriority BACKGROUND
BasePriority 8
CommitCharge 0
I don’t see any 0-sized processes of other tasks that would have run nightly, so it seems that these 0-sized processes really are in some zombie state.
I’m hoping that this somehow explains the cause of the system problem, also in the “!vm” output:
Committed pages: 4294962071 (17179848284 Kb)
Commit limit: 1108180 ( 4432720 Kb)
********** Number of committed pages is near limit ********
********** 10528464 commit requests have failed **********
And that of course lead to all sorts of system problems. How does the system even think that there are 17 TERAbytes (yes, look at that number above!) of committed space? This is essentially a normal PC with just 2 GB RAM and 25 GB of free space for paging.
Any assistance will be appreciated!