Debugging a pool-leak crash

WINDBG
1

Howdy Folks,

I could use some help debugging a WinXP crash. I’m using the 4.0.11
version
of windbg.

The bugcheck is SESSION_HAS_VALID_POOL_ON_EXIT. The problem is, there’s
very little to go on from there. I get the size of the allocation,
paged/non-paged etc, but not who allocated it (or even the address of the
allocation – I’m using pool tagging now so that if I can find the
address,
I can see if it’s tagged). This happens when a user is logged out while
other users are logged in but “suspended” from a fast user switch.

Can anyone help me out with discovering the address of the allocation in
this bugcheck ? About all I have got now is the windbg analysis:

SESSION_HAS_VALID_POOL_ON_EXIT (ab)
Caused by a session driver not freeing its pool allocations prior to a
session unload. This typically indicates a bug in win32k.sys, atmfd.dll,
rdpdd.dll or a video driver.
Arguments:
Arg1: 00000003, session ID
Arg2: 00000000, number of paged pool bytes that are leaking
Arg3: 00001000, number of nonpaged pool bytes that are leaking
Arg4: 00010000, total number of paged and nonpaged allocations that are
leaking.
nonpaged allocations are in the upper half of this word,
paged allocations are in the lower half of this word

The call stack isn’t helpful, since it’s all NT calls to clean up a
session. As the leak is in the non-paged pool (1 4K page, 1 allocation), I
doubt it’s a video driver (they can only alloc from the paged pool as I
understand, but they are cleaned up after each session. All other kernel
drivers don’t clean up for each session on XP, or at least, that is what I
understand.) Heck, I can’t even say it’s my driver causing it (though odds
are it is…).

I can do the “!poolused” command, and have it dump out the tag and
number/total size of paged and non-paged allocations. From there I did
find
a driver with 1 4k allocation, but that isn’t a smoking gun – any driver
could have 1 of its multiple allocations being the leak, no? What I really
want is to be able to !pool the address of the leak and see its tag …

(Side question on tags: Is there a list of the common tags to be found
anywhere ? I’m curious what programs use some of the tags)

Thanks,
Nathan

You are currently subscribed to windbg as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com

2

I suggest you use DriverVerifer.
But if you know which tag is leaking memory, then you might like to read
Q298102 for more information.

Thanks,
Joshi

-----Original Message-----
From: xxxxx@symantec.com [mailto:xxxxx@symantec.com]
Sent: Monday, December 31, 2001 1:50 AM
To: Kernel Debugging Interest List
Subject: [windbg] Debugging a pool-leak crash

Howdy Folks,

I could use some help debugging a WinXP crash. I’m using the 4.0.11
version
of windbg.

The bugcheck is SESSION_HAS_VALID_POOL_ON_EXIT. The problem is, there’s
very little to go on from there. I get the size of the allocation,
paged/non-paged etc, but not who allocated it (or even the address of the
allocation – I’m using pool tagging now so that if I can find the
address,
I can see if it’s tagged). This happens when a user is logged out while
other users are logged in but “suspended” from a fast user switch.

Can anyone help me out with discovering the address of the allocation in
this bugcheck ? About all I have got now is the windbg analysis:

SESSION_HAS_VALID_POOL_ON_EXIT (ab)
Caused by a session driver not freeing its pool allocations prior to a
session unload. This typically indicates a bug in win32k.sys, atmfd.dll,
rdpdd.dll or a video driver.
Arguments:
Arg1: 00000003, session ID
Arg2: 00000000, number of paged pool bytes that are leaking
Arg3: 00001000, number of nonpaged pool bytes that are leaking
Arg4: 00010000, total number of paged and nonpaged allocations that are
leaking.
nonpaged allocations are in the upper half of this word,
paged allocations are in the lower half of this word

The call stack isn’t helpful, since it’s all NT calls to clean up a
session. As the leak is in the non-paged pool (1 4K page, 1 allocation), I
doubt it’s a video driver (they can only alloc from the paged pool as I
understand, but they are cleaned up after each session. All other kernel
drivers don’t clean up for each session on XP, or at least, that is what I
understand.) Heck, I can’t even say it’s my driver causing it (though odds
are it is…).

I can do the “!poolused” command, and have it dump out the tag and
number/total size of paged and non-paged allocations. From there I did
find
a driver with 1 4k allocation, but that isn’t a smoking gun – any driver
could have 1 of its multiple allocations being the leak, no? What I really
want is to be able to !pool the address of the leak and see its tag …

(Side question on tags: Is there a list of the common tags to be found
anywhere ? I’m curious what programs use some of the tags)

Thanks,
Nathan

You are currently subscribed to windbg as:
xxxxx@exchange.sandiegoca.ncr.com
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to windbg as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com

3

Verifier will not flag this problem when attached with the debugger. I do
not get a Bug Check 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION. I still get
the SESSION_HAS_VALID_POOL_ON_EXIT (ab). So it would appear that verifier
does not catch this, since the driver may not be unloaded during a session
change (the only error verifier will pick up on is, "The driver is
unloading without first freeing all its memory pools. " Since it’s a
session change, the driver may not unload.)

However, !verifier will give pool dump information that can be handy on a
per-driver basis (for fun, look at the fastfat driver…). But I still have
no way of identifying the driver that has the leak. I can do a !drivers and
then go one by one down the list doing a !verifier 3 and look
for ones that have an allocation of the same size, but boy is that slow …

Thus I’ll ask again if anyone knows how to find out what driver is causing
the SESSION_HAS_VALID_POOL_ON_EXIT error, or at least the allocation in
question.

As for finding debug strings, the MS pooltag.txt provided file is in
\triage\pooltag.txt. I may poke around my system 32 directory, but
that will be slow.

Thanks,
Nathan

On 12/31/01, ““Joshi, Venu” ” wrote:
> I suggest you use DriverVerifer.
> But if you know which tag is leaking memory, then you might like to read
> Q298102 for more information.
>
> Thanks,
> Joshi
>
> -----Original Message-----
> From: xxxxx@symantec.com [mailto:xxxxx@symantec.com]
> Sent: Monday, December 31, 2001 1:50 AM
> To: Kernel Debugging Interest List
> Subject: [windbg] Debugging a pool-leak crash
>
>
> Howdy Folks,
>
> I could use some help debugging a WinXP crash. I’m using the 4.0.11
> version
> of windbg.
>
> The bugcheck is SESSION_HAS_VALID_POOL_ON_EXIT. The problem is, there’s
> very little to go on from there. I get the size of the allocation,
> paged/non-paged etc, but not who allocated it (or even the address of the
> allocation – I’m using pool tagging now so that if I can find the
> address,
> I can see if it’s tagged). This happens when a user is logged out while
> other users are logged in but “suspended” from a fast user switch.
>
> Can anyone help me out with discovering the address of the allocation in
> this bugcheck ? About all I have got now is the windbg analysis:
>
> SESSION_HAS_VALID_POOL_ON_EXIT (ab)
> Caused by a session driver not freeing its pool allocations prior to a
> session unload. This typically indicates a bug in win32k.sys, atmfd.dll,
> rdpdd.dll or a video driver.
> Arguments:
> Arg1: 00000003, session ID
> Arg2: 00000000, number of paged pool bytes that are leaking
> Arg3: 00001000, number of nonpaged pool bytes that are leaking
> Arg4: 00010000, total number of paged and nonpaged allocations that are
> leaking.
> nonpaged allocations are in the upper half of this word,
> paged allocations are in the lower half of this word
>
> The call stack isn’t helpful, since it’s all NT calls to clean up a
> session. As the leak is in the non-paged pool (1 4K page, 1 allocation), I
> doubt it’s a video driver (they can only alloc from the paged pool as I
> understand, but they are cleaned up after each session. All other kernel
> drivers don’t clean up for each session on XP, or at least, that is what I
> understand.) Heck, I can’t even say it’s my driver causing it (though odds
> are it is…).
>
> I can do the “!poolused” command, and have it dump out the tag and
> number/total size of paged and non-paged allocations. From there I did
> find
> a driver with 1 4k allocation, but that isn’t a smoking gun – any driver
> could have 1 of its multiple allocations being the leak, no? What I really
> want is to be able to !pool the address of the leak and see its tag …
>
> (Side question on tags: Is there a list of the common tags to be found
> anywhere ? I’m curious what programs use some of the tags)
>
> Thanks,
> Nathan
>

—
You are currently subscribed to windbg as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com