0-sized Zombie Processes?

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!

Does !object show elevated handle or reference counts? That would prevent the process from being completely torn down.

-scott
OSR
@OSRDrivers

OK, I’ve taken it the next step, but cannot figure out how to find get the handles to find out what they’re pointing to.

0: kd> !object 85e99078
Object: 85e99078 Type: (83a44ab8) Process
ObjectHeader: 85e99060 (old version)
HandleCount: 1 PointerCount: 2

0: kd> dt nt!_OBJECT_HEADER 85e99060
+0x000 PointerCount : 0n2
+0x004 HandleCount : 0n1
+0x004 NextToFree : 0x00000001 Void
+0x008 Type : 0x83a44ab8 _OBJECT_TYPE
+0x00c NameInfoOffset : 0 ‘’
+0x00d HandleInfoOffset : 0 ‘’
+0x00e QuotaInfoOffset : 0 ‘’
+0x00f Flags : 0x20 ’ ’
+0x010 ObjectCreateInfo : 0x81d4c840 _OBJECT_CREATE_INFORMATION
+0x010 QuotaBlockCharged : 0x81d4c840 Void
+0x014 SecurityDescriptor : 0x882034c2 Void
+0x018 Body : _QUAD

I looked at the handle count for all of the “zombie” processes and it’s just 1 in each case.

So, I don’t think that this explains the cause of the system problem, seen 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 **********

I’ve been doing a lot of reading today and it doesn’t seem like it’s possible to get into the state that I see where the Committed Pages is at the maximum 16 TB (4294962071 == 0xFFFFEB97) but my system has a Commit Limit of a reasonable 4 GB. How are my systems committing more than the commit limit?!?!

Committed pages: 4294962071 (17179848284 Kb)
Commit limit: 1108180 ( 4432720 Kb)
********** Number of committed pages is near limit ********
********** 10528464 commit requests have failed **********

Also, this was an interesting tidbit in that my systems show 3 of the 4 types of commit request failures.

0: kd> dd nt!MiChargeCommitmentFailures
81d51f80 0093b93f 00000000 000c7189 00007c08

MiChargeCommitmentFailures[0] - If the system failed a commit request and an expansion of the pagefile has failed.
MiChargeCommitmentFailures[1] - If the system failed a commit and we have already reached the maximum pagefile size.
MiChargeCommitmentFailures[2] - If the system failed a commit while the pagefile lock is held.
MiChargeCommitmentFailures[3] - If the system failed a commit and the NewCommitValue is less than or equal to CurrentCommitValue.

You can read about “zombie processes” here https://blogs.msdn.microsoft.com/oldnewthing/20150918-00/?p=91561
Use ps command from DbgKit http://www.andreybazhan.com/dbgkit.html to investigate what other of your processes still have
opened handle to the process. Also, you can check memory usage information in View->System Information, Memory tab, just to make sure
that WinDbg !vm output is correct.

“Taed Wynnell” wrote in message news:xxxxx@windbg…
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!

Thanks; I had never run into your DbgKit.DLL before, and it was useful. As mentioned somewhere, it really is just like Process Explorer within WinDbg. I did track down the handle issue, and I now suspect that’s just a red herring for my committed memory issue.

Your DLL also allowed me to sanity check the 16 TB committed memory, as it agrees with the value, though that’s likely just due to them both getting it from the same place.

So, that’s where I’m still stuck right now…