Driver Verifier and non-paged pool memory leak

NTDEV
1

I have a KMDF driver that is leaking non-paged pool memory and Driver
Verifier isn’t catching it.
:
:
:
Initially I used Task Manager to detect a memory leak with an application
using my KMDF driver. The commit size and NP Pool size both went up in the
same amounts. This happened both on XP (single core) and Vista (dual core)
but the Vista (quad core) showed no memory leak using Task Manager (bug
???).

Next I used Poolmon.exe to track memory allocations using the tag I’ve
assigned for my KMDF driver. In XP I used gflags.exe to first enable pool
tagging. Gflags.exe in Vista showed pool tagging already enabled. Sure
enough, on all three boxes the NP Pool size for my KMDF driver just kept on
growing.

I was pretty sure I had used Driver Verifier on my KMDF driver for the past
month in regular usage but now I started to second guess myself. I checked
Driver Verifier and the information collected for my KMDF driver showed ‘0’
for all NP pool memory counters.

I then added Driver Verifier standard settings for the wdf01000.sys driver
and rebooted. I checked Driver Verifier information collected for my KMDF
driver and again showed ‘0’ for all NP pool memory counters. However, the
NP pool memory counters for wdf01000.sys continually went up. Why didn’t
Driver Verifier issue a stop???

I used sysinternals Strings program on wdf01000.sys to see if I could match
a character string to a tag in poolmon.exe (no luck). I then looked at
highlighted tags in Vista (quad core) to see if any of the highlighted large
differences in memory (allocation versus frees) had a tag name that might be
associated to wdf01000.sys. I found a lot of highlighted tags that had
large differences but none I could point to and say it was the wdf01000.sys
tag. Here are just some of the tags with large differences.

CcSc NP
Even NP
FIcs P
FOCX NP
File NP
HBIH NP -----> my KMDF driver
Io NP
IoNm P

:
:

My summation up to this point is that my KMDF driver is leaking NP pool
memory through the wdf01000.sys driver and I need to find out how. My
confidence in Driver Verifier has slipped quite a bit because it didn’t
catch the memory leak in my driver on any of the 3 boxes even though both
Poolmon.exe and Task Manager showed a leak. Also, Driver Verifier didn’t
stop when wdf01000.sys showed what looked like a leak. If I knew what the
tag was for wdf01000.sys I would have tried to verify the leak in
Poolmon.exe but I couldn’t find a tag.

NOTE: I haven’t tried the new Static Driver Verifier in the latest WinHec
bits but I will very soon. I’m hoping that might find the memory leak. I
did have some PreFast warnings listed below but they don’t seem to be
related to this.
c:\winddk\6000\inc\wdf\kmdf\10\wdfinterrupt.h (278): warning 28104: The
Interrupt that should have been acquired before function exit was not
acquired.
FUNCTION: WdfInterruptAcquireLock (278)
PATH: 283

c:\winddk\6000\inc\wdf\kmdf\10\wdfinterrupt.h (278): warning 28158: No IRQL
was saved into ‘Interrupt’.
FUNCTION: WdfInterruptAcquireLock (278)
PATH: 283

c:\winddk\6000\inc\wdf\kmdf\10\wdfinterrupt.h (299): warning 28103: Leaking
the Interrupt stored in ‘Interrupt’.
FUNCTION: WdfInterruptReleaseLock (299)
PATH: 304

c:\winddk\6000\inc\wdf\kmdf\10\wdfinterrupt.h (299): warning 28157: The IRQL
in ‘Interrupt’ was never restored.
FUNCTION: WdfInterruptReleaseLock (299)
PATH: 304

c:\winddk\6000\inc\wdf\kmdf\10\wdfsync.h (184): warning 28104: The SpinLock
that should have been acquired before function exit was not acquired.
FUNCTION: WdfSpinLockAcquire (184)
PATH: 189

c:\winddk\6000\inc\wdf\kmdf\10\wdfsync.h (184): warning 28158: No IRQL was
saved into ‘SpinLock’.
FUNCTION: WdfSpinLockAcquire (184)
PATH: 189

c:\winddk\6000\inc\wdf\kmdf\10\wdfsync.h (205): warning 28103: Leaking the
SpinLock stored in ‘SpinLock’.
FUNCTION: WdfSpinLockRelease (205)
PATH: 210

c:\winddk\6000\inc\wdf\kmdf\10\wdfsync.h (205): warning 28157: The IRQL in
‘SpinLock’ was never restored.
FUNCTION: WdfSpinLockRelease (205)
PATH: 210

d:\user\winsoft\hib\drivers\hibusbwdf\sys\objfre_wxp_x86\i386\hibusb.tmh
(1829): warning 6387: (PFD)‘pDevObject’ could be ‘0’: this does not adhere
to the specification for the function ‘WdfDriverRegisterTraceInfo’.
FUNCTION: WppInitKm (1784)
PATH: 1806 1807 1810 1814 1829

2

KMDF does all the memory allocations for your driver from the runtime (wdf01000.sys). DV will only catch memory leaks upon driver unload.

On a Vista system, you simply can’t unload KMDF, because it is used on drivers which cannot be unloaded. I’d have to guess for now that on your XP box you either did not unload your driver (and KMDF with it) with DV on (against KMDF, since your driver is not allocating anything), or you had other KMDF drivers running (because KMDF will not unload until all of them are gone). There may also be a special case if KMDF is running as a boot driver (at the moment, it doesn’t matter to me).

At any rate, the KMDF verifier can tell you what is leaking.

If you have access to the Server Beta 3 WDK, you can use the WdfVerifier tool to make the necessary changes (turn enhanced verification on, and you might also want to turn on handle tracking for all handles).

If you don’t have it, then you need to set the “verifierOn” DWORD switch (described in the WDK docs) to a non-zero value, and (if you want the handle tracking) “HandleTracking” REG_MULTI_SZ to a single entry of “*”.

In both cases, you will need to disable and enable your driver (or reboot) for the changes to take effect.

The debugger extensions we provided can then tell you what is leaking and (IIRC) where in your code you allocated it.

3

Should have added that the framework’s check for leaks occurs when you unload your driver, as well. But the tracking feature can be used by just breaking in and checking (!wdftagtracker, I think, but !wdfhelp gives pretty good information in the event I got it wrong). Of course, the same is true of DV (!verifier 3, IIRC).

And that I forgot that KMDF won’t leak on unload, because it will just free everything you forgot to before it goes. So the leak only exists as long as the framework stays loaded.

I probably forgot something else (worked all last weekend, and today must be the day to pay for it)- where’s my head ;-)?

But perhaps someone will arrive soon who can remember it all…

4

Thanks for the information Bob. I didn’t know that is how Driver Verifier
and a KMDF driver interacted.

With this new information I went to the XP box and verfied that my KMDF
driver is the only KMDF driver on the system (it is). So I enabled Driver
Verifier for both the Wdf01000.sys driver and my KMDF driver. With the
application running and the USB device plugged in the Wdf01000.sys Driver
Verifier memory counters continued to go up and the memory counters for my
KMDF driver remained at ‘0’. This verifies what you said, “KMDF does all
the memory allocations for your driver from the runtime (wdf01000.sys).”

When I stopped and exited the application the memory counters for
Wdf01000.sys stopped incrementing. When I unplugged the device the counters
were cleared to ‘0’. I am going to try the Server Beta 3 WDK WdfVerifier
tool to see if I can’t catch the memory leak. Driver Verifier saw that the
allocated memory was released when the device was unplugged and didn’t
trigger a stop but there is still a memory leak. If I leave the device
plugged in and just start/stop the application the allocated memory just
continues to climb until the box locks up.

“Bob Kjelgaard” wrote in message
news:xxxxx@ntdev…
KMDF does all the memory allocations for your driver from the runtime
(wdf01000.sys). DV will only catch memory leaks upon driver unload.

On a Vista system, you simply can’t unload KMDF, because it is used on
drivers which cannot be unloaded. I’d have to guess for now that on your XP
box you either did not unload your driver (and KMDF with it) with DV on
(against KMDF, since your driver is not allocating anything), or you had
other KMDF drivers running (because KMDF will not unload until all of them
are gone). There may also be a special case if KMDF is running as a boot
driver (at the moment, it doesn’t matter to me).

At any rate, the KMDF verifier can tell you what is leaking.

If you have access to the Server Beta 3 WDK, you can use the WdfVerifier
tool to make the necessary changes (turn enhanced verification on, and you
might also want to turn on handle tracking for all handles).

If you don’t have it, then you need to set the “verifierOn” DWORD switch
(described in the WDK docs) to a non-zero value, and (if you want the handle
tracking) “HandleTracking” REG_MULTI_SZ to a single entry of “*”.

In both cases, you will need to disable and enable your driver (or reboot)
for the changes to take effect.

The debugger extensions we provided can then tell you what is leaking and
(IIRC) where in your code you allocated it.

5

!wdftagtracker is for leaked ref counts, not for leaked pool.
!wdfkd.wdfpoolusage is one command that should dump pool, but I think it
it will only track pool if KMDF verifier is on.

Let’s take a step back for a moment though. How are you allocating
memory? ExAllcoatePool? WDFMEMORY objects? Or just object contexts?
Each of these patterns have different ways to diagnose the leak.
ExAllocatePool can be tracked with DV. WDFMEMORY or contexts using KMDF
debugger commands.

First thing I would do is when you suspect a leak has occurred is to run
!wdfdriverinfo <your driver name no .sys> 0xFFF. This will dump every
KMDF object in your driver. Look for suspect objects (like tons of
WDFREQUESTS even though your device is idle). This might give you a
clue about the usage.

OTOH, this could be a false positive if the suspected leaked pool goes
away when your device is disabled/driver is unloaded. KMDF uses a
lookaside list for WDFREQUESTs. The lookaside list might contain a lot
of “freed” requests (which are still charged as allocated), giving the
impressions that there is a leak (but if you turn on DV on wdf01000.sys,
the lookaside list will never contain any freed entries).

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bob Kjelgaard
Sent: Friday, May 25, 2007 8:13 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Driver Verifier and non-paged pool memory leak

Should have added that the framework’s check for leaks occurs when you
unload your driver, as well. But the tracking feature can be used by
just breaking in and checking (!wdftagtracker, I think, but !wdfhelp
gives pretty good information in the event I got it wrong). Of course,
the same is true of DV (!verifier 3, IIRC).

And that I forgot that KMDF won’t leak on unload, because it will just
free everything you forgot to before it goes. So the leak only exists
as long as the framework stays loaded.

I probably forgot something else (worked all last weekend, and today
must be the day to pay for it)- where’s my head ;-)?

But perhaps someone will arrive soon who can remember it all…

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

6

Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset=“us-ascii”
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Return-Path: xxxxx@microsoft.com

The other thing I forgot surfaced (check the registry switch names before y=
ou post!). It’s “TrackHandles”, not “HandleTracking”. Sorry- once I encod=
ed the names in WdfVerifier, I didn’t see a need to keep remembering them…=
.

At any rate, that ought to get you close to finding your leak. Sorry about=
the belated corrections.

7

As a side note- your driver can still call OS /WDM DDI, so it CAN allocate memory with (e.g.) the ExAllocatePool… DDI, in which case it is “charged” to your driver, and DV will see it that way.

Also, as I later mentioned, the leak ends when your driver is unloaded (even if KMDF remains) because all allocations are parented to your WDFDRIVER (at the minimum) and cleaned up when it leaves. But if the KMDF verifier is on, it will tell you about the leak.

8

I’m assuming when you say to turn on the KMDF verifier you mean to set this
in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\statbus\Parameters\Wdf"VerifierOn"=dword:00000001

When this is set, Driver Verifier still didn’t stop.

“Bob Kjelgaard” wrote in message
news:xxxxx@ntdev…
As a side note- your driver can still call OS /WDM DDI, so it CAN allocate
memory with (e.g.) the ExAllocatePool… DDI, in which case it is “charged”
to your driver, and DV will see it that way.

Also, as I later mentioned, the leak ends when your driver is unloaded (even
if KMDF remains) because all allocations are parented to your WDFDRIVER (at
the minimum) and cleaned up when it leaves. But if the KMDF verifier is on,
it will tell you about the leak.

9

That’s the correct key if statbus is your driver. You also need to stop and restart the driver for these settings to take effect. Did you do this?

As Doron noted earlier, you can use the !wdfdriverinfo extension to see all of the objects you allocated from your driver at any time. You can do this even without the verifier on.

If the framework sees a leak, it will bugcheck (10D). DV isn’t really a factor in this.

10

I’m still using KMDF version 1.5 for this but this is the result so far.
Nothing looks out of the ordinary so far. I’m still looking.

1: kd> !wdfkd.wdfdriverinfo hibusb 0x10

Default driver image name: hibusb
WDF library image name: Wdf01000
FxDriverGlobals 0x9faecf18
WdfBindInfo 0x87af63a4
Version v1.5 build(6000)

Driver Handles:
WDFDRIVER 0x5ceb30d0
WDFDEVICE 0x5ce7d260
WDFQUEUE 0x6050b1e8
WDFQUEUE 0x6593d1e8
WDFQUEUE 0x627eb1e8
WDFCMRESLIST 0x5dc2d058
WDFCMRESLIST 0x5cfad058
WDFCHILDLIST 0x5e7690c8
WDFIOTARGET 0x5e2630b8
WDFUSBDEVICE 0x605b5108
WDFUSBINTERFACE 0x5ccb3058
WDFUSBPIPE 0x5dc450e0
WDFUSBPIPE 0x5cd7d0e0
WDFUSBPIPE 0x638bf0e0
WDFREQUEST 0x5efaf0b0
WDFREQUEST 0x5f6bd0b0
WDFHANDLE 0x5ce45050
WDFHANDLE 0x5cf53088
WDFREQUEST 0x613850b0
WDFREQUEST 0x638f90b0

“Bob Kjelgaard” wrote in message
news:xxxxx@ntdev…
That’s the correct key if statbus is your driver. You also need to stop and
restart the driver for these settings to take effect. Did you do this?

As Doron noted earlier, you can use the !wdfdriverinfo extension to see all
of the objects you allocated from your driver at any time. You can do this
even without the verifier on.

If the framework sees a leak, it will bugcheck (10D). DV isn’t really a
factor in this.

11

David-

KMDF 1.5 is the latest we can support (the 1.7 in the Beta3 WDK can only be used on the Beta 3 LHS build, IIRC), so that’s not a problem.

If hibusb is your driver, then the key you want to change is hklm/system/currentcontrolset/services/hibusb/parameters/wdf, not the one in your earlier post. !wdfdriverinfo will tell you if the verifier is on for your driver (but you may need to turn on additional flag bits to see that level of detail).

Also, Doron tells me that we won’t consider it a leak unless it has references outstanding at unload time (which makes sense, of course). So if (for instance) you just allocate a lot of WDFMEMORY parented to your driver and never delete any of it, it won’t get caught [we can’t really tell what you want that memory for in that case].

If you’re still seeing large amounts of pool consumed, and wdfdriverinfo isn’t showing any additional objects, then (assuming you are still using DV against wdf01000.sys) please try !verifier 3 wdf01000.sys. It should show everything the framework has allocated. If that’s a lot of output you can email it to me as an attachment.

Thanks for your persistence- if this is somehow a framework bug, we don’t want it to escape. If it isn’t, it’s still valuable to understand what works for you and what doesn’t.

12

More good info, thanks

Adjusting to hklm/system/currentcontrolset/services/hibusb/parameters/wdf is
helping. I will let you know what I find soon (if I can keep from
continually getting interrupted).

-Dave

“Bob Kjelgaard” wrote in message
news:xxxxx@ntdev…
David-

KMDF 1.5 is the latest we can support (the 1.7 in the Beta3 WDK can only be
used on the Beta 3 LHS build, IIRC), so that’s not a problem.

If hibusb is your driver, then the key you want to change is
hklm/system/currentcontrolset/services/hibusb/parameters/wdf, not the one in
your earlier post. !wdfdriverinfo will tell you if the verifier is on for
your driver (but you may need to turn on additional flag bits to see that
level of detail).

Also, Doron tells me that we won’t consider it a leak unless it has
references outstanding at unload time (which makes sense, of course). So if
(for instance) you just allocate a lot of WDFMEMORY parented to your driver
and never delete any of it, it won’t get caught [we can’t really tell what
you want that memory for in that case].

If you’re still seeing large amounts of pool consumed, and wdfdriverinfo
isn’t showing any additional objects, then (assuming you are still using DV
against wdf01000.sys) please try !verifier 3 wdf01000.sys. It should show
everything the framework has allocated. If that’s a lot of output you can
email it to me as an attachment.

Thanks for your persistence- if this is somehow a framework bug, we don’t
want it to escape. If it isn’t, it’s still valuable to understand what
works for you and what doesn’t.

13

It looks like I’m leaking some WDFHANDLES. With the WDFVerifier on, should
I expect a stop to be issued or is it now a matter of taking a closer look
at the driver code to see where I"m allocating a WDFHANDLE?

0: kd> !wdfkd.wdfdriverinfo hibusb 0xfff

Default driver image name: hibusb
WDF library image name: Wdf01000
FxDriverGlobals 0x84267900
WdfBindInfo 0x89574fa4
Version v1.5 build(6000)

Driver Handles:
dt FxDriver 0x84370710 : WDFDRIVER 0x7bc8f8e8
dt FxDevice 0x84361048 : WDFDEVICE 0x7bc9efb0 Context
84361210
dt FxDefaultIrpHandler 0x9473D048 : WDF INTERNAL
dt FxPkgGeneral 0x856F89D0 : WDF INTERNAL
dt FxWmiIrpHandler 0x842EA6D0 : WDF INTERNAL
dt FxPkgIo 0x8436E410 : WDF INTERNAL
dt FxIoQueue 0x84372290 : WDFQUEUE 0x7bc8dd68
dt FxIoQueue 0x84374588 : WDFQUEUE 0x7bc8ba70
dt FxIoQueue 0x84363B60 : WDFQUEUE 0x7bc9c498
dt FxPkgFdo 0x84342770 : WDF INTERNAL
dt FxCmResList 0x842D9600 : WDFCMRESLIST 0x7bd269f8
dt FxCmResList 0x842DA140 : WDFCMRESLIST 0x7bd25eb8
dt FxChildList 0x84342658 : WDFCHILDLIST 0x7bcbd9a0
dt FxIoTarget 0x8436FCC8 : WDFIOTARGET 0x7bc90330
dt FxUsbDevice 0x8435DA38 : WDFUSBDEVICE 0x7bca25c0
dt FxUsbInterface 0x842271E8 : WDFUSBINTERFACE
0x7bdd8e10
dt FxUsbPipe 0x84343830 : WDFUSBPIPE
0x7bcbc7c8
dt FxUsbPipe 0x84364680 : WDFUSBPIPE
0x7bc9b978
dt FxUsbPipe 0x843643D0 : WDFUSBPIPE
0x7bc9bc28
dt FxFileObject 0x8430E508 : WDFFILEOBJECT 0x7bcf1af0
dt FxFileObject 0x84323FA0 : WDFFILEOBJECT 0x7bcdc058
dt FxRequest 0x8451BF48 : WDFREQUEST 0x7bae40b0
dt FxRequest 0x84342070 : WDFREQUEST 0x7bcbdf88
dt FxRequest 0x843700E0 : WDFREQUEST 0x7bc8ff18
dt FxObject 0x937DFB50 : WDFHANDLE 0x6c8204a8
dt FxObject 0x83F80B20 : WDFHANDLE 0x7c07f4d8
:
:
:
:
dt FxObject 0x91F3EE70 : WDFHANDLE 0x6e0c1188
dt FxObject 0x842DC048 : WDFHANDLE 0x7bd23fb0
dt FxObject 0x842F1378 : WDFHANDLE 0x7bd0ec80
dt FxObject 0x84384700 : WDFHANDLE 0x7bc7b8f8
dt FxObject 0x845CA3D0 : WDFHANDLE 0x7ba35c28
dt FxObject 0x8458A780 : WDFHANDLE 0x7ba75878
dt FxObject 0x848FE2F0 : WDFHANDLE 0x7b701d08
dt FxObject 0x84319318 : WDFHANDLE 0x7bce6ce0
dt FxObject 0x845DDA48 : WDFHANDLE 0x7ba225b0

No objects in a state where they could have been leaked.
(An object must not be in the created state to be detected.)

WDF Verifier settings for hibusb.sys is ON
Pool tracking is ON
Handle verification is ON
IO verification is ON
Lock verification is ON
Handle reference tracking is ON for the following types:
WDFDRIVER WDFDEVICE WDFQUEUE WDFWMIPROVIDER WDFKEY WDFSTRING WDFREQUEST
WDFLOOKASIDE WDFMEMORY WDFOBJECT WDFCOLLECTION WDFDPC WDFFILEOBJECT
WDFWAITLOCK WDFSPINLOCK WDFWORKITEM WDFINTERRUPT WDFTIMER WDFCHILDLIST
WDFWMIINSTANCE WDFIORESLIST WDFCMRESLIST WDFIORESREQLIST WDFIOTARGET
WDFUSBDEVICE WDFUSBPIPE WDFUSBINTERFACE WDFDMAENABLER WDFDMATRANSACTION
WDFCOMMONBUFFER

“Bob Kjelgaard” wrote in message
news:xxxxx@ntdev…
David-

KMDF 1.5 is the latest we can support (the 1.7 in the Beta3 WDK can only be
used on the Beta 3 LHS build, IIRC), so that’s not a problem.

If hibusb is your driver, then the key you want to change is
hklm/system/currentcontrolset/services/hibusb/parameters/wdf, not the one in
your earlier post. !wdfdriverinfo will tell you if the verifier is on for
your driver (but you may need to turn on additional flag bits to see that
level of detail).

Also, Doron tells me that we won’t consider it a leak unless it has
references outstanding at unload time (which makes sense, of course). So if
(for instance) you just allocate a lot of WDFMEMORY parented to your driver
and never delete any of it, it won’t get caught [we can’t really tell what
you want that memory for in that case].

If you’re still seeing large amounts of pool consumed, and wdfdriverinfo
isn’t showing any additional objects, then (assuming you are still using DV
against wdf01000.sys) please try !verifier 3 wdf01000.sys. It should show
everything the framework has allocated. If that’s a lot of output you can
email it to me as an attachment.

Thanks for your persistence- if this is somehow a framework bug, we don’t
want it to escape. If it isn’t, it’s still valuable to understand what
works for you and what doesn’t.

14

run the dt command in first column (e.g. dt FxObject 0x937DFB50). That
will dump the object and its derived type, please send the output. Are
you calling WdfObjectCreate in your driver?

If you are not calling WdfObjectReference/Dereference explicitly, the
KMDF verifier will not consider these handles leaks b/c it will be able
to free them on unload. I think you need to look at how you create
these handles and consider assigning them a different ParentObject whose
lifetime matches more closely to the lifetime of the WDFOBJET (probably
the WDFDEVICE or a WDFREQUEST) so that the WDFHANDLEs are freed when
they are no longer needed.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Voeller
Sent: Friday, May 25, 2007 2:59 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Re:Re:Re:Driver Verifier and non-paged pool memory
leak

It looks like I’m leaking some WDFHANDLES. With the WDFVerifier on,
should
I expect a stop to be issued or is it now a matter of taking a closer
look
at the driver code to see where I"m allocating a WDFHANDLE?

0: kd> !wdfkd.wdfdriverinfo hibusb 0xfff

Default driver image name: hibusb
WDF library image name: Wdf01000
FxDriverGlobals 0x84267900
WdfBindInfo 0x89574fa4
Version v1.5 build(6000)

Driver Handles:
dt FxDriver 0x84370710 : WDFDRIVER 0x7bc8f8e8
dt FxDevice 0x84361048 : WDFDEVICE 0x7bc9efb0
Context
84361210
dt FxDefaultIrpHandler 0x9473D048 : WDF INTERNAL
dt FxPkgGeneral 0x856F89D0 : WDF INTERNAL
dt FxWmiIrpHandler 0x842EA6D0 : WDF INTERNAL
dt FxPkgIo 0x8436E410 : WDF INTERNAL
dt FxIoQueue 0x84372290 : WDFQUEUE
0x7bc8dd68
dt FxIoQueue 0x84374588 : WDFQUEUE
0x7bc8ba70
dt FxIoQueue 0x84363B60 : WDFQUEUE
0x7bc9c498
dt FxPkgFdo 0x84342770 : WDF INTERNAL
dt FxCmResList 0x842D9600 : WDFCMRESLIST
0x7bd269f8
dt FxCmResList 0x842DA140 : WDFCMRESLIST
0x7bd25eb8
dt FxChildList 0x84342658 : WDFCHILDLIST
0x7bcbd9a0
dt FxIoTarget 0x8436FCC8 : WDFIOTARGET
0x7bc90330
dt FxUsbDevice 0x8435DA38 : WDFUSBDEVICE
0x7bca25c0
dt FxUsbInterface 0x842271E8 : WDFUSBINTERFACE
0x7bdd8e10
dt FxUsbPipe 0x84343830 : WDFUSBPIPE
0x7bcbc7c8
dt FxUsbPipe 0x84364680 : WDFUSBPIPE
0x7bc9b978
dt FxUsbPipe 0x843643D0 : WDFUSBPIPE
0x7bc9bc28
dt FxFileObject 0x8430E508 : WDFFILEOBJECT
0x7bcf1af0
dt FxFileObject 0x84323FA0 : WDFFILEOBJECT
0x7bcdc058
dt FxRequest 0x8451BF48 : WDFREQUEST
0x7bae40b0
dt FxRequest 0x84342070 : WDFREQUEST 0x7bcbdf88
dt FxRequest 0x843700E0 : WDFREQUEST 0x7bc8ff18
dt FxObject 0x937DFB50 : WDFHANDLE 0x6c8204a8
dt FxObject 0x83F80B20 : WDFHANDLE 0x7c07f4d8
:
:
:
:
dt FxObject 0x91F3EE70 : WDFHANDLE 0x6e0c1188
dt FxObject 0x842DC048 : WDFHANDLE 0x7bd23fb0
dt FxObject 0x842F1378 : WDFHANDLE 0x7bd0ec80
dt FxObject 0x84384700 : WDFHANDLE 0x7bc7b8f8
dt FxObject 0x845CA3D0 : WDFHANDLE 0x7ba35c28
dt FxObject 0x8458A780 : WDFHANDLE 0x7ba75878
dt FxObject 0x848FE2F0 : WDFHANDLE 0x7b701d08
dt FxObject 0x84319318 : WDFHANDLE 0x7bce6ce0
dt FxObject 0x845DDA48 : WDFHANDLE 0x7ba225b0

No objects in a state where they could have been leaked.
(An object must not be in the created state to be detected.)

WDF Verifier settings for hibusb.sys is ON
Pool tracking is ON
Handle verification is ON
IO verification is ON
Lock verification is ON
Handle reference tracking is ON for the following types:
WDFDRIVER WDFDEVICE WDFQUEUE WDFWMIPROVIDER WDFKEY WDFSTRING
WDFREQUEST
WDFLOOKASIDE WDFMEMORY WDFOBJECT WDFCOLLECTION WDFDPC WDFFILEOBJECT
WDFWAITLOCK WDFSPINLOCK WDFWORKITEM WDFINTERRUPT WDFTIMER
WDFCHILDLIST
WDFWMIINSTANCE WDFIORESLIST WDFCMRESLIST WDFIORESREQLIST WDFIOTARGET
WDFUSBDEVICE WDFUSBPIPE WDFUSBINTERFACE WDFDMAENABLER
WDFDMATRANSACTION
WDFCOMMONBUFFER

“Bob Kjelgaard” wrote in message
news:xxxxx@ntdev…
David-

KMDF 1.5 is the latest we can support (the 1.7 in the Beta3 WDK can only
be
used on the Beta 3 LHS build, IIRC), so that’s not a problem.

If hibusb is your driver, then the key you want to change is
hklm/system/currentcontrolset/services/hibusb/parameters/wdf, not the
one in
your earlier post. !wdfdriverinfo will tell you if the verifier is on
for
your driver (but you may need to turn on additional flag bits to see
that
level of detail).

Also, Doron tells me that we won’t consider it a leak unless it has
references outstanding at unload time (which makes sense, of course).
So if
(for instance) you just allocate a lot of WDFMEMORY parented to your
driver
and never delete any of it, it won’t get caught [we can’t really tell
what
you want that memory for in that case].

If you’re still seeing large amounts of pool consumed, and wdfdriverinfo

isn’t showing any additional objects, then (assuming you are still using
DV
against wdf01000.sys) please try !verifier 3 wdf01000.sys. It should
show
everything the framework has allocated. If that’s a lot of output you
can
email it to me as an attachment.

Thanks for your persistence- if this is somehow a framework bug, we
don’t
want it to escape. If it isn’t, it’s still valuable to understand what
works for you and what doesn’t.

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

15

In addition to Doron’s advice, I thought that I’d mention that at least one of the extensions (either !wdfhandle or !wdfobject- I don’t have a suitable test vehicle available at the moment or I could just tell you) will list the “context” for those suspect WDFHANDLEs- that is, it will tell you the address of and (your) type of the object context. That is usually enough for me to be able to tell what it is that is leaking, since it’s now in “my” design space.

My assumption is that you are using something like WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE to initialize the attributes prior to calling WdfObjectCreate for these handles.

16

I am not calling WdfObjectReference/Dereference explicitly.
I am not calling WdfObjectCreate explicitly.
I believe that Doron is correct in that whatever is happening it is a parent
child relationship that is wrong but I still don’t know enough to fix it.
This is some WinDbg output. I have several questions but one is the
“m_Type” that is reported by the “dt” command, where are the values defined?

0: kd> !wdfkd.wdfdriverinfo HibUsb 0xfff

Default driver image name: HibUsb
WDF library image name: Wdf01000
FxDriverGlobals 0x94191538
WdfBindInfo 0x94a8cfa4
Version v1.5 build(6000)

Driver Handles:
dt FxDriver 0x941F2C48 : WDFDRIVER 0x6be0d3b0
dt FxDevice 0x84820B90 : WDFDEVICE 0x7b7df468 Context
84820d58
dt FxDefaultIrpHandler 0x84B511E8 : WDF INTERNAL
dt FxPkgGeneral 0x859DAB70 : WDF INTERNAL
dt FxWmiIrpHandler 0x847BE7F8 : WDF INTERNAL
dt FxPkgIo 0x84567798 : WDF INTERNAL
dt FxIoQueue 0x84C9A6A8 : WDFQUEUE 0x7b365950
dt FxIoQueue 0x847DF760 : WDFQUEUE 0x7b820898
dt FxIoQueue 0x84CB9180 : WDFQUEUE 0x7b346e78
dt FxPkgFdo 0x84820308 : WDF INTERNAL
dt FxCmResList 0x845651E0 : WDFCMRESLIST 0x7ba9ae18
dt FxCmResList 0x8496E498 : WDFCMRESLIST 0x7b691b60
dt FxChildList 0x847E1238 : WDFCHILDLIST 0x7b81edc0
dt FxIoTarget 0x84CA7B48 : WDFIOTARGET 0x7b3584b0
dt FxUsbDevice 0x849AC388 : WDFUSBDEVICE 0x7b653c70
dt FxUsbInterface 0x84645878 : WDFUSBINTERFACE
0x7b9ba780
dt FxUsbPipe 0x847E4218 : WDFUSBPIPE
0x7b81bde0
dt FxUsbPipe 0x848562E0 : WDFUSBPIPE
0x7b7a9d18
dt FxUsbPipe 0x8977BC28 : WDFUSBPIPE
0x768843d0
dt FxFileObject 0x84645C60 : WDFFILEOBJECT 0x7b9ba398
dt FxFileObject 0x84575048 : WDFFILEOBJECT 0x7ba8afb0
dt FxRequest 0x8494E750 : WDFREQUEST 0x7b6b18a8
dt FxRequest 0x845428C8 : WDFREQUEST 0x7babd730
dt FxRequest 0x847E5C48 : WDFREQUEST 0x7b81a3b0
dt FxObject 0x849DC148 : WDFHANDLE 0x7b623eb0
dt FxObject 0x84628D20 : WDFHANDLE 0x7b9d72d8
dt FxRequest 0x848C2D00 : WDFREQUEST 0x7b73d2f8
dt FxRequest 0x950D7D68 : WDFREQUEST 0x6af28290
dt FxObject 0x8465DA80 : WDFHANDLE 0x7b9a2578
dt FxObject 0x845980D8 : WDFHANDLE 0x7ba67f20
dt FxObject 0x95002A88 : WDFHANDLE 0x6affd570
dt FxObject 0x896F94E0 : WDFHANDLE 0x76906b18
:

0: kd> dt FxDriver 0x941F2C48
+0x000 __VFN_table : 0x8070c9a8
+0x004 m_Type : 0x1001
+0x006 m_ObjectSize : 0xc0
+0x008 m_Refcnt : 1
+0x00c m_Globals : 0x94191538 _FX_DRIVER_GLOBALS
+0x010 m_ObjectFlags : 0x29b
+0x010 m_ObjectFlagsByName : FxObject::::
+0x012 m_ObjectState : 1
+0x014 m_ChildListHead : _LIST_ENTRY [0x84820bb4 - 0x8457a984]
+0x01c m_SpinLock : 0
+0x020 m_ParentObject : (null)
+0x024 m_ChildEntry : _LIST_ENTRY [0x941f2c6c - 0x941f2c6c]
+0x02c m_DisposeSingleEntry : _SINGLE_LIST_ENTRY
+0x030 m_NPLock : 0
+0x034 __VFN_table : 0x8070c9a0
+0x038 m_DriverObject : 0x8da15330 _DRIVER_OBJECT
+0x03c m_RegistryPath : _UNICODE_STRING
“\REGISTRY\MACHINE\SYSTEM\ControlSet001\Services\HibUsb”
+0x044 m_DebuggerConnected : 0x1 ‘’
+0x045 m_InternalTracingInitialized : 0x1 ‘’
+0x048 m_FdoCount : 1
+0x04c m_DriverDeviceAdd : FxDriverDeviceAdd
+0x054 m_WdfInternalTraceDevice : (null)
+0x058 m_WdfExternalTraceDevice : (null)
+0x05c m_ExecutionLevel : 3 ( WdfExecutionLevelDispatch )
+0x060 m_SynchronizationScope : 4 ( WdfSynchronizationScopeNone )
+0x064 m_CallbackMutexLock : FxCallbackMutexLock
+0x09c m_CallbackLockPtr : 0x941f2cac FxCallbackLock
+0x0a0 m_CallbackLockObjectPtr : 0x941f2c48 FxObject
+0x0a4 m_Config : _WDF_DRIVER_CONFIG
+0x0b8 m_DisposeList : 0x8457c338 FxDisposeList
+0x0bc m_DriverUnload : FxDriverUnload

0: kd> dt FxObject 0x8465DA80
+0x000__VFN_table : 0x8070cd14
+0x004 m_Type : 0x1000
+0x006 m_ObjectSize : 0x40
+0x008 m_Refcnt : 1
+0x00c m_Globals : 0x94191538 _FX_DRIVER_GLOBALS
+0x010 m_ObjectFlags : 0x288
+0x010 m_ObjectFlagsByName : FxObject::::
+0x012 m_ObjectState : 1
+0x014 m_ChildListHead : _LIST_ENTRY [0x8465da94 - 0x8465da94]
+0x01c m_SpinLock : 0
+0x020 m_ParentObject : 0x941f2c48 FxObject
+0x024 m_ChildEntry : _LIST_ENTRY [0x845980fc - 0x950d7d8c]
+0x02c m_DisposeSingleEntry : _SINGLE_LIST_ENTRY

“Doron Holan” wrote in message
news:xxxxx@ntdev…

run the dt command in first column (e.g. dt FxObject 0x937DFB50). That
will dump the object and its derived type, please send the output. Are
you calling WdfObjectCreate in your driver?

If you are not calling WdfObjectReference/Dereference explicitly, the
KMDF verifier will not consider these handles leaks b/c it will be able
to free them on unload. I think you need to look at how you create
these handles and consider assigning them a different ParentObject whose
lifetime matches more closely to the lifetime of the WDFOBJET (probably
the WDFDEVICE or a WDFREQUEST) so that the WDFHANDLEs are freed when
they are no longer needed.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Voeller
Sent: Friday, May 25, 2007 2:59 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Re:Re:Re:Driver Verifier and non-paged pool memory
leak

It looks like I’m leaking some WDFHANDLES. With the WDFVerifier on,
should
I expect a stop to be issued or is it now a matter of taking a closer
look
at the driver code to see where I"m allocating a WDFHANDLE?

0: kd> !wdfkd.wdfdriverinfo hibusb 0xfff
----------------------------------
Default driver image name: hibusb
WDF library image name: Wdf01000
FxDriverGlobals 0x84267900
WdfBindInfo 0x89574fa4
Version v1.5 build(6000)
----------------------------------
Driver Handles:
dt FxDriver 0x84370710 : WDFDRIVER 0x7bc8f8e8
dt FxDevice 0x84361048 : WDFDEVICE 0x7bc9efb0
Context
84361210
dt FxDefaultIrpHandler 0x9473D048 : WDF INTERNAL
dt FxPkgGeneral 0x856F89D0 : WDF INTERNAL
dt FxWmiIrpHandler 0x842EA6D0 : WDF INTERNAL
dt FxPkgIo 0x8436E410 : WDF INTERNAL
dt FxIoQueue 0x84372290 : WDFQUEUE
0x7bc8dd68
dt FxIoQueue 0x84374588 : WDFQUEUE
0x7bc8ba70
dt FxIoQueue 0x84363B60 : WDFQUEUE
0x7bc9c498
dt FxPkgFdo 0x84342770 : WDF INTERNAL
dt FxCmResList 0x842D9600 : WDFCMRESLIST
0x7bd269f8
dt FxCmResList 0x842DA140 : WDFCMRESLIST
0x7bd25eb8
dt FxChildList 0x84342658 : WDFCHILDLIST
0x7bcbd9a0
dt FxIoTarget 0x8436FCC8 : WDFIOTARGET
0x7bc90330
dt FxUsbDevice 0x8435DA38 : WDFUSBDEVICE
0x7bca25c0
dt FxUsbInterface 0x842271E8 : WDFUSBINTERFACE
0x7bdd8e10
dt FxUsbPipe 0x84343830 : WDFUSBPIPE
0x7bcbc7c8
dt FxUsbPipe 0x84364680 : WDFUSBPIPE
0x7bc9b978
dt FxUsbPipe 0x843643D0 : WDFUSBPIPE
0x7bc9bc28
dt FxFileObject 0x8430E508 : WDFFILEOBJECT
0x7bcf1af0
dt FxFileObject 0x84323FA0 : WDFFILEOBJECT
0x7bcdc058
dt FxRequest 0x8451BF48 : WDFREQUEST
0x7bae40b0
dt FxRequest 0x84342070 : WDFREQUEST 0x7bcbdf88
dt FxRequest 0x843700E0 : WDFREQUEST 0x7bc8ff18
dt FxObject 0x937DFB50 : WDFHANDLE 0x6c8204a8
dt FxObject 0x83F80B20 : WDFHANDLE 0x7c07f4d8
:
:
:
:
dt FxObject 0x91F3EE70 : WDFHANDLE 0x6e0c1188
dt FxObject 0x842DC048 : WDFHANDLE 0x7bd23fb0
dt FxObject 0x842F1378 : WDFHANDLE 0x7bd0ec80
dt FxObject 0x84384700 : WDFHANDLE 0x7bc7b8f8
dt FxObject 0x845CA3D0 : WDFHANDLE 0x7ba35c28
dt FxObject 0x8458A780 : WDFHANDLE 0x7ba75878
dt FxObject 0x848FE2F0 : WDFHANDLE 0x7b701d08
dt FxObject 0x84319318 : WDFHANDLE 0x7bce6ce0
dt FxObject 0x845DDA48 : WDFHANDLE 0x7ba225b0
----------------------------------
No objects in a state where they could have been leaked.
(An object must not be in the created state to be detected.)
----------------------------------

WDF Verifier settings for hibusb.sys is ON
Pool tracking is ON
Handle verification is ON
IO verification is ON
Lock verification is ON
Handle reference tracking is ON for the following types:
WDFDRIVER WDFDEVICE WDFQUEUE WDFWMIPROVIDER WDFKEY WDFSTRING
WDFREQUEST
WDFLOOKASIDE WDFMEMORY WDFOBJECT WDFCOLLECTION WDFDPC WDFFILEOBJECT
WDFWAITLOCK WDFSPINLOCK WDFWORKITEM WDFINTERRUPT WDFTIMER
WDFCHILDLIST
WDFWMIINSTANCE WDFIORESLIST WDFCMRESLIST WDFIORESREQLIST WDFIOTARGET
WDFUSBDEVICE WDFUSBPIPE WDFUSBINTERFACE WDFDMAENABLER
WDFDMATRANSACTION
WDFCOMMONBUFFER
----------------------------------

“Bob Kjelgaard” wrote in message
news:xxxxx@ntdev…
David-

KMDF 1.5 is the latest we can support (the 1.7 in the Beta3 WDK can only
be
used on the Beta 3 LHS build, IIRC), so that’s not a problem.

If hibusb is your driver, then the key you want to change is
hklm/system/currentcontrolset/services/hibusb/parameters/wdf, not the
one in
your earlier post. !wdfdriverinfo will tell you if the verifier is on
for
your driver (but you may need to turn on additional flag bits to see
that
level of detail).

Also, Doron tells me that we won’t consider it a leak unless it has
references outstanding at unload time (which makes sense, of course).
So if
(for instance) you just allocate a lot of WDFMEMORY parented to your
driver
and never delete any of it, it won’t get caught [we can’t really tell
what
you want that memory for in that case].

If you’re still seeing large amounts of pool consumed, and wdfdriverinfo

isn’t showing any additional objects, then (assuming you are still using
DV
against wdf01000.sys) please try !verifier 3 wdf01000.sys. It should
show
everything the framework has allocated. If that’s a lot of output you
can
email it to me as an attachment.

Thanks for your persistence- if this is somehow a framework bug, we
don’t
want it to escape. If it isn’t, it’s still valuable to understand what
works for you and what doesn’t.

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

17

m_Type’s types are internal, 0x1000 is the start of the object type list
though (as well as WDFOBJECT’s type).

Instead of running dt in the output, run !wdfobject
,

For instance instead of this
dt FxObject 0x8465DA80

run this (Which will also dump a
!wdfobject 0x8465DA80

This would give you the type of the object in string form. I think
things might be easier if you can send me the src to your driver as a
zipfile, it might speed things up.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Voeller
Sent: Tuesday, May 29, 2007 9:46 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Re:Re:Re:Driver Verifier and non-paged pool memory
leak

I am not calling WdfObjectReference/Dereference explicitly.
I am not calling WdfObjectCreate explicitly.
I believe that Doron is correct in that whatever is happening it is a
parent
child relationship that is wrong but I still don’t know enough to fix
it.
This is some WinDbg output. I have several questions but one is the
“m_Type” that is reported by the “dt” command, where are the values
defined?

0: kd> !wdfkd.wdfdriverinfo HibUsb 0xfff
----------------------------------
Default driver image name: HibUsb
WDF library image name: Wdf01000
FxDriverGlobals 0x94191538
WdfBindInfo 0x94a8cfa4
Version v1.5 build(6000)
----------------------------------
Driver Handles:
dt FxDriver 0x941F2C48 : WDFDRIVER 0x6be0d3b0
dt FxDevice 0x84820B90 : WDFDEVICE 0x7b7df468
Context
84820d58
dt FxDefaultIrpHandler 0x84B511E8 : WDF INTERNAL
dt FxPkgGeneral 0x859DAB70 : WDF INTERNAL
dt FxWmiIrpHandler 0x847BE7F8 : WDF INTERNAL
dt FxPkgIo 0x84567798 : WDF INTERNAL
dt FxIoQueue 0x84C9A6A8 : WDFQUEUE
0x7b365950
dt FxIoQueue 0x847DF760 : WDFQUEUE
0x7b820898
dt FxIoQueue 0x84CB9180 : WDFQUEUE
0x7b346e78
dt FxPkgFdo 0x84820308 : WDF INTERNAL
dt FxCmResList 0x845651E0 : WDFCMRESLIST
0x7ba9ae18
dt FxCmResList 0x8496E498 : WDFCMRESLIST
0x7b691b60
dt FxChildList 0x847E1238 : WDFCHILDLIST
0x7b81edc0
dt FxIoTarget 0x84CA7B48 : WDFIOTARGET
0x7b3584b0
dt FxUsbDevice 0x849AC388 : WDFUSBDEVICE
0x7b653c70
dt FxUsbInterface 0x84645878 : WDFUSBINTERFACE
0x7b9ba780
dt FxUsbPipe 0x847E4218 : WDFUSBPIPE
0x7b81bde0
dt FxUsbPipe 0x848562E0 : WDFUSBPIPE
0x7b7a9d18
dt FxUsbPipe 0x8977BC28 : WDFUSBPIPE
0x768843d0
dt FxFileObject 0x84645C60 : WDFFILEOBJECT
0x7b9ba398
dt FxFileObject 0x84575048 : WDFFILEOBJECT
0x7ba8afb0
dt FxRequest 0x8494E750 : WDFREQUEST
0x7b6b18a8
dt FxRequest 0x845428C8 : WDFREQUEST 0x7babd730
dt FxRequest 0x847E5C48 : WDFREQUEST 0x7b81a3b0
dt FxObject 0x849DC148 : WDFHANDLE 0x7b623eb0
dt FxObject 0x84628D20 : WDFHANDLE 0x7b9d72d8
dt FxRequest 0x848C2D00 : WDFREQUEST 0x7b73d2f8
dt FxRequest 0x950D7D68 : WDFREQUEST 0x6af28290
dt FxObject 0x8465DA80 : WDFHANDLE 0x7b9a2578
dt FxObject 0x845980D8 : WDFHANDLE 0x7ba67f20
dt FxObject 0x95002A88 : WDFHANDLE 0x6affd570
dt FxObject 0x896F94E0 : WDFHANDLE 0x76906b18
:

0: kd> dt FxDriver 0x941F2C48
+0x000 __VFN_table : 0x8070c9a8
+0x004 m_Type : 0x1001
+0x006 m_ObjectSize : 0xc0
+0x008 m_Refcnt : 1
+0x00c m_Globals : 0x94191538 _FX_DRIVER_GLOBALS
+0x010 m_ObjectFlags : 0x29b
+0x010 m_ObjectFlagsByName : FxObject::::
+0x012 m_ObjectState : 1
+0x014 m_ChildListHead : _LIST_ENTRY [0x84820bb4 - 0x8457a984]
+0x01c m_SpinLock : 0
+0x020 m_ParentObject : (null)
+0x024 m_ChildEntry : _LIST_ENTRY [0x941f2c6c - 0x941f2c6c]
+0x02c m_DisposeSingleEntry : _SINGLE_LIST_ENTRY
+0x030 m_NPLock : 0
+0x034__VFN_table : 0x8070c9a0
+0x038 m_DriverObject : 0x8da15330 _DRIVER_OBJECT
+0x03c m_RegistryPath : _UNICODE_STRING
“\REGISTRY\MACHINE\SYSTEM\ControlSet001\Services\HibUsb”
+0x044 m_DebuggerConnected : 0x1 ‘’
+0x045 m_InternalTracingInitialized : 0x1 ‘’
+0x048 m_FdoCount : 1
+0x04c m_DriverDeviceAdd : FxDriverDeviceAdd
+0x054 m_WdfInternalTraceDevice : (null)
+0x058 m_WdfExternalTraceDevice : (null)
+0x05c m_ExecutionLevel : 3 ( WdfExecutionLevelDispatch )
+0x060 m_SynchronizationScope : 4 ( WdfSynchronizationScopeNone )
+0x064 m_CallbackMutexLock : FxCallbackMutexLock
+0x09c m_CallbackLockPtr : 0x941f2cac FxCallbackLock
+0x0a0 m_CallbackLockObjectPtr : 0x941f2c48 FxObject
+0x0a4 m_Config : _WDF_DRIVER_CONFIG
+0x0b8 m_DisposeList : 0x8457c338 FxDisposeList
+0x0bc m_DriverUnload : FxDriverUnload

0: kd> dt FxObject 0x8465DA80
+0x000 __VFN_table : 0x8070cd14
+0x004 m_Type : 0x1000
+0x006 m_ObjectSize : 0x40
+0x008 m_Refcnt : 1
+0x00c m_Globals : 0x94191538 _FX_DRIVER_GLOBALS
+0x010 m_ObjectFlags : 0x288
+0x010 m_ObjectFlagsByName : FxObject::::
+0x012 m_ObjectState : 1
+0x014 m_ChildListHead : _LIST_ENTRY [0x8465da94 - 0x8465da94]
+0x01c m_SpinLock : 0
+0x020 m_ParentObject : 0x941f2c48 FxObject
+0x024 m_ChildEntry : _LIST_ENTRY [0x845980fc - 0x950d7d8c]
+0x02c m_DisposeSingleEntry : _SINGLE_LIST_ENTRY

“Doron Holan” wrote in message
news:xxxxx@ntdev…

run the dt command in first column (e.g. dt FxObject 0x937DFB50). That
will dump the object and its derived type, please send the output. Are
you calling WdfObjectCreate in your driver?

If you are not calling WdfObjectReference/Dereference explicitly, the
KMDF verifier will not consider these handles leaks b/c it will be able
to free them on unload. I think you need to look at how you create
these handles and consider assigning them a different ParentObject whose
lifetime matches more closely to the lifetime of the WDFOBJET (probably
the WDFDEVICE or a WDFREQUEST) so that the WDFHANDLEs are freed when
they are no longer needed.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Voeller
Sent: Friday, May 25, 2007 2:59 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Re:Re:Re:Driver Verifier and non-paged pool memory
leak

It looks like I’m leaking some WDFHANDLES. With the WDFVerifier on,
should
I expect a stop to be issued or is it now a matter of taking a closer
look
at the driver code to see where I"m allocating a WDFHANDLE?

0: kd> !wdfkd.wdfdriverinfo hibusb 0xfff
----------------------------------
Default driver image name: hibusb
WDF library image name: Wdf01000
FxDriverGlobals 0x84267900
WdfBindInfo 0x89574fa4
Version v1.5 build(6000)
----------------------------------
Driver Handles:
dt FxDriver 0x84370710 : WDFDRIVER 0x7bc8f8e8
dt FxDevice 0x84361048 : WDFDEVICE 0x7bc9efb0
Context
84361210
dt FxDefaultIrpHandler 0x9473D048 : WDF INTERNAL
dt FxPkgGeneral 0x856F89D0 : WDF INTERNAL
dt FxWmiIrpHandler 0x842EA6D0 : WDF INTERNAL
dt FxPkgIo 0x8436E410 : WDF INTERNAL
dt FxIoQueue 0x84372290 : WDFQUEUE
0x7bc8dd68
dt FxIoQueue 0x84374588 : WDFQUEUE
0x7bc8ba70
dt FxIoQueue 0x84363B60 : WDFQUEUE
0x7bc9c498
dt FxPkgFdo 0x84342770 : WDF INTERNAL
dt FxCmResList 0x842D9600 : WDFCMRESLIST
0x7bd269f8
dt FxCmResList 0x842DA140 : WDFCMRESLIST
0x7bd25eb8
dt FxChildList 0x84342658 : WDFCHILDLIST
0x7bcbd9a0
dt FxIoTarget 0x8436FCC8 : WDFIOTARGET
0x7bc90330
dt FxUsbDevice 0x8435DA38 : WDFUSBDEVICE
0x7bca25c0
dt FxUsbInterface 0x842271E8 : WDFUSBINTERFACE
0x7bdd8e10
dt FxUsbPipe 0x84343830 : WDFUSBPIPE
0x7bcbc7c8
dt FxUsbPipe 0x84364680 : WDFUSBPIPE
0x7bc9b978
dt FxUsbPipe 0x843643D0 : WDFUSBPIPE
0x7bc9bc28
dt FxFileObject 0x8430E508 : WDFFILEOBJECT
0x7bcf1af0
dt FxFileObject 0x84323FA0 : WDFFILEOBJECT
0x7bcdc058
dt FxRequest 0x8451BF48 : WDFREQUEST
0x7bae40b0
dt FxRequest 0x84342070 : WDFREQUEST 0x7bcbdf88
dt FxRequest 0x843700E0 : WDFREQUEST 0x7bc8ff18
dt FxObject 0x937DFB50 : WDFHANDLE 0x6c8204a8
dt FxObject 0x83F80B20 : WDFHANDLE 0x7c07f4d8
:
:
:
:
dt FxObject 0x91F3EE70 : WDFHANDLE 0x6e0c1188
dt FxObject 0x842DC048 : WDFHANDLE 0x7bd23fb0
dt FxObject 0x842F1378 : WDFHANDLE 0x7bd0ec80
dt FxObject 0x84384700 : WDFHANDLE 0x7bc7b8f8
dt FxObject 0x845CA3D0 : WDFHANDLE 0x7ba35c28
dt FxObject 0x8458A780 : WDFHANDLE 0x7ba75878
dt FxObject 0x848FE2F0 : WDFHANDLE 0x7b701d08
dt FxObject 0x84319318 : WDFHANDLE 0x7bce6ce0
dt FxObject 0x845DDA48 : WDFHANDLE 0x7ba225b0
----------------------------------
No objects in a state where they could have been leaked.
(An object must not be in the created state to be detected.)
----------------------------------

WDF Verifier settings for hibusb.sys is ON
Pool tracking is ON
Handle verification is ON
IO verification is ON
Lock verification is ON
Handle reference tracking is ON for the following types:
WDFDRIVER WDFDEVICE WDFQUEUE WDFWMIPROVIDER WDFKEY WDFSTRING
WDFREQUEST
WDFLOOKASIDE WDFMEMORY WDFOBJECT WDFCOLLECTION WDFDPC WDFFILEOBJECT
WDFWAITLOCK WDFSPINLOCK WDFWORKITEM WDFINTERRUPT WDFTIMER
WDFCHILDLIST
WDFWMIINSTANCE WDFIORESLIST WDFCMRESLIST WDFIORESREQLIST WDFIOTARGET
WDFUSBDEVICE WDFUSBPIPE WDFUSBINTERFACE WDFDMAENABLER
WDFDMATRANSACTION
WDFCOMMONBUFFER
----------------------------------

“Bob Kjelgaard” wrote in message
news:xxxxx@ntdev…
David-

KMDF 1.5 is the latest we can support (the 1.7 in the Beta3 WDK can only
be
used on the Beta 3 LHS build, IIRC), so that’s not a problem.

If hibusb is your driver, then the key you want to change is
hklm/system/currentcontrolset/services/hibusb/parameters/wdf, not the
one in
your earlier post. !wdfdriverinfo will tell you if the verifier is on
for
your driver (but you may need to turn on additional flag bits to see
that
level of detail).

Also, Doron tells me that we won’t consider it a leak unless it has
references outstanding at unload time (which makes sense, of course).
So if
(for instance) you just allocate a lot of WDFMEMORY parented to your
driver
and never delete any of it, it won’t get caught [we can’t really tell
what
you want that memory for in that case].

If you’re still seeing large amounts of pool consumed, and wdfdriverinfo

isn’t showing any additional objects, then (assuming you are still using
DV
against wdf01000.sys) please try !verifier 3 wdf01000.sys. It should
show
everything the framework has allocated. If that’s a lot of output you
can
email it to me as an attachment.

Thanks for your persistence- if this is somehow a framework bug, we
don’t
want it to escape. If it isn’t, it’s still valuable to understand what
works for you and what doesn’t.

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

18

Doron,

I sent you my email via your blog but this is it also xxxxx@hunter.com.

At the moment I’m attacking this by taking out functionality in the driver
until I find the problem. It is a fairly narrow path of code that is
executed so I’m hoping it doesn’t take too long. I’ve already learned quite
a bit as a result of this problem and I’m sure I’m going to learn more
before "m done.

This is the result of the last command
0: kd> !wdfkd.wdfobject 0x84563568

The type for object 0x84563568 is FxObject
State: FxObjectStateCreated (0x1)

!wdfhandle 0x7ba9ca90

dt FxObject 0x84563568



Object debug extension 84563550
Extension signature incorrect…expected 0x0, got 0x444f7846
!wdftagtracker 0x84be5d80

State history:
[0] FxObjectStateCreated (0x1)

“Doron Holan” wrote in message
news:xxxxx@ntdev…
m_Type’s types are internal, 0x1000 is the start of the object type list
though (as well as WDFOBJECT’s type).

Instead of running dt in the output, run !wdfobject
,

For instance instead of this
dt FxObject 0x8465DA80

run this (Which will also dump a
!wdfobject 0x8465DA80

This would give you the type of the object in string form. I think
things might be easier if you can send me the src to your driver as a
zipfile, it might speed things up.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Voeller
Sent: Tuesday, May 29, 2007 9:46 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Re:Re:Re:Driver Verifier and non-paged pool memory
leak

I am not calling WdfObjectReference/Dereference explicitly.
I am not calling WdfObjectCreate explicitly.
I believe that Doron is correct in that whatever is happening it is a
parent
child relationship that is wrong but I still don’t know enough to fix
it.
This is some WinDbg output. I have several questions but one is the
“m_Type” that is reported by the “dt” command, where are the values
defined?

0: kd> !wdfkd.wdfdriverinfo HibUsb 0xfff
----------------------------------
Default driver image name: HibUsb
WDF library image name: Wdf01000
FxDriverGlobals 0x94191538
WdfBindInfo 0x94a8cfa4
Version v1.5 build(6000)
----------------------------------
Driver Handles:
dt FxDriver 0x941F2C48 : WDFDRIVER 0x6be0d3b0
dt FxDevice 0x84820B90 : WDFDEVICE 0x7b7df468
Context
84820d58
dt FxDefaultIrpHandler 0x84B511E8 : WDF INTERNAL
dt FxPkgGeneral 0x859DAB70 : WDF INTERNAL
dt FxWmiIrpHandler 0x847BE7F8 : WDF INTERNAL
dt FxPkgIo 0x84567798 : WDF INTERNAL
dt FxIoQueue 0x84C9A6A8 : WDFQUEUE
0x7b365950
dt FxIoQueue 0x847DF760 : WDFQUEUE
0x7b820898
dt FxIoQueue 0x84CB9180 : WDFQUEUE
0x7b346e78
dt FxPkgFdo 0x84820308 : WDF INTERNAL
dt FxCmResList 0x845651E0 : WDFCMRESLIST
0x7ba9ae18
dt FxCmResList 0x8496E498 : WDFCMRESLIST
0x7b691b60
dt FxChildList 0x847E1238 : WDFCHILDLIST
0x7b81edc0
dt FxIoTarget 0x84CA7B48 : WDFIOTARGET
0x7b3584b0
dt FxUsbDevice 0x849AC388 : WDFUSBDEVICE
0x7b653c70
dt FxUsbInterface 0x84645878 : WDFUSBINTERFACE
0x7b9ba780
dt FxUsbPipe 0x847E4218 : WDFUSBPIPE
0x7b81bde0
dt FxUsbPipe 0x848562E0 : WDFUSBPIPE
0x7b7a9d18
dt FxUsbPipe 0x8977BC28 : WDFUSBPIPE
0x768843d0
dt FxFileObject 0x84645C60 : WDFFILEOBJECT
0x7b9ba398
dt FxFileObject 0x84575048 : WDFFILEOBJECT
0x7ba8afb0
dt FxRequest 0x8494E750 : WDFREQUEST
0x7b6b18a8
dt FxRequest 0x845428C8 : WDFREQUEST 0x7babd730
dt FxRequest 0x847E5C48 : WDFREQUEST 0x7b81a3b0
dt FxObject 0x849DC148 : WDFHANDLE 0x7b623eb0
dt FxObject 0x84628D20 : WDFHANDLE 0x7b9d72d8
dt FxRequest 0x848C2D00 : WDFREQUEST 0x7b73d2f8
dt FxRequest 0x950D7D68 : WDFREQUEST 0x6af28290
dt FxObject 0x8465DA80 : WDFHANDLE 0x7b9a2578
dt FxObject 0x845980D8 : WDFHANDLE 0x7ba67f20
dt FxObject 0x95002A88 : WDFHANDLE 0x6affd570
dt FxObject 0x896F94E0 : WDFHANDLE 0x76906b18
:

0: kd> dt FxDriver 0x941F2C48
+0x000 __VFN_table : 0x8070c9a8
+0x004 m_Type : 0x1001
+0x006 m_ObjectSize : 0xc0
+0x008 m_Refcnt : 1
+0x00c m_Globals : 0x94191538 _FX_DRIVER_GLOBALS
+0x010 m_ObjectFlags : 0x29b
+0x010 m_ObjectFlagsByName : FxObject::::
+0x012 m_ObjectState : 1
+0x014 m_ChildListHead : _LIST_ENTRY [0x84820bb4 - 0x8457a984]
+0x01c m_SpinLock : 0
+0x020 m_ParentObject : (null)
+0x024 m_ChildEntry : _LIST_ENTRY [0x941f2c6c - 0x941f2c6c]
+0x02c m_DisposeSingleEntry : _SINGLE_LIST_ENTRY
+0x030 m_NPLock : 0
+0x034__VFN_table : 0x8070c9a0
+0x038 m_DriverObject : 0x8da15330 _DRIVER_OBJECT
+0x03c m_RegistryPath : _UNICODE_STRING
“\REGISTRY\MACHINE\SYSTEM\ControlSet001\Services\HibUsb”
+0x044 m_DebuggerConnected : 0x1 ‘’
+0x045 m_InternalTracingInitialized : 0x1 ‘’
+0x048 m_FdoCount : 1
+0x04c m_DriverDeviceAdd : FxDriverDeviceAdd
+0x054 m_WdfInternalTraceDevice : (null)
+0x058 m_WdfExternalTraceDevice : (null)
+0x05c m_ExecutionLevel : 3 ( WdfExecutionLevelDispatch )
+0x060 m_SynchronizationScope : 4 ( WdfSynchronizationScopeNone )
+0x064 m_CallbackMutexLock : FxCallbackMutexLock
+0x09c m_CallbackLockPtr : 0x941f2cac FxCallbackLock
+0x0a0 m_CallbackLockObjectPtr : 0x941f2c48 FxObject
+0x0a4 m_Config : _WDF_DRIVER_CONFIG
+0x0b8 m_DisposeList : 0x8457c338 FxDisposeList
+0x0bc m_DriverUnload : FxDriverUnload

0: kd> dt FxObject 0x8465DA80
+0x000 __VFN_table : 0x8070cd14
+0x004 m_Type : 0x1000
+0x006 m_ObjectSize : 0x40
+0x008 m_Refcnt : 1
+0x00c m_Globals : 0x94191538 _FX_DRIVER_GLOBALS
+0x010 m_ObjectFlags : 0x288
+0x010 m_ObjectFlagsByName : FxObject::::
+0x012 m_ObjectState : 1
+0x014 m_ChildListHead : _LIST_ENTRY [0x8465da94 - 0x8465da94]
+0x01c m_SpinLock : 0
+0x020 m_ParentObject : 0x941f2c48 FxObject
+0x024 m_ChildEntry : _LIST_ENTRY [0x845980fc - 0x950d7d8c]
+0x02c m_DisposeSingleEntry : _SINGLE_LIST_ENTRY

“Doron Holan” wrote in message
news:xxxxx@ntdev…

run the dt command in first column (e.g. dt FxObject 0x937DFB50). That
will dump the object and its derived type, please send the output. Are
you calling WdfObjectCreate in your driver?

If you are not calling WdfObjectReference/Dereference explicitly, the
KMDF verifier will not consider these handles leaks b/c it will be able
to free them on unload. I think you need to look at how you create
these handles and consider assigning them a different ParentObject whose
lifetime matches more closely to the lifetime of the WDFOBJET (probably
the WDFDEVICE or a WDFREQUEST) so that the WDFHANDLEs are freed when
they are no longer needed.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Voeller
Sent: Friday, May 25, 2007 2:59 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Re:Re:Re:Driver Verifier and non-paged pool memory
leak

It looks like I’m leaking some WDFHANDLES. With the WDFVerifier on,
should
I expect a stop to be issued or is it now a matter of taking a closer
look
at the driver code to see where I"m allocating a WDFHANDLE?

0: kd> !wdfkd.wdfdriverinfo hibusb 0xfff
----------------------------------
Default driver image name: hibusb
WDF library image name: Wdf01000
FxDriverGlobals 0x84267900
WdfBindInfo 0x89574fa4
Version v1.5 build(6000)
----------------------------------
Driver Handles:
dt FxDriver 0x84370710 : WDFDRIVER 0x7bc8f8e8
dt FxDevice 0x84361048 : WDFDEVICE 0x7bc9efb0
Context
84361210
dt FxDefaultIrpHandler 0x9473D048 : WDF INTERNAL
dt FxPkgGeneral 0x856F89D0 : WDF INTERNAL
dt FxWmiIrpHandler 0x842EA6D0 : WDF INTERNAL
dt FxPkgIo 0x8436E410 : WDF INTERNAL
dt FxIoQueue 0x84372290 : WDFQUEUE
0x7bc8dd68
dt FxIoQueue 0x84374588 : WDFQUEUE
0x7bc8ba70
dt FxIoQueue 0x84363B60 : WDFQUEUE
0x7bc9c498
dt FxPkgFdo 0x84342770 : WDF INTERNAL
dt FxCmResList 0x842D9600 : WDFCMRESLIST
0x7bd269f8
dt FxCmResList 0x842DA140 : WDFCMRESLIST
0x7bd25eb8
dt FxChildList 0x84342658 : WDFCHILDLIST
0x7bcbd9a0
dt FxIoTarget 0x8436FCC8 : WDFIOTARGET
0x7bc90330
dt FxUsbDevice 0x8435DA38 : WDFUSBDEVICE
0x7bca25c0
dt FxUsbInterface 0x842271E8 : WDFUSBINTERFACE
0x7bdd8e10
dt FxUsbPipe 0x84343830 : WDFUSBPIPE
0x7bcbc7c8
dt FxUsbPipe 0x84364680 : WDFUSBPIPE
0x7bc9b978
dt FxUsbPipe 0x843643D0 : WDFUSBPIPE
0x7bc9bc28
dt FxFileObject 0x8430E508 : WDFFILEOBJECT
0x7bcf1af0
dt FxFileObject 0x84323FA0 : WDFFILEOBJECT
0x7bcdc058
dt FxRequest 0x8451BF48 : WDFREQUEST
0x7bae40b0
dt FxRequest 0x84342070 : WDFREQUEST 0x7bcbdf88
dt FxRequest 0x843700E0 : WDFREQUEST 0x7bc8ff18
dt FxObject 0x937DFB50 : WDFHANDLE 0x6c8204a8
dt FxObject 0x83F80B20 : WDFHANDLE 0x7c07f4d8
:
:
:
:
dt FxObject 0x91F3EE70 : WDFHANDLE 0x6e0c1188
dt FxObject 0x842DC048 : WDFHANDLE 0x7bd23fb0
dt FxObject 0x842F1378 : WDFHANDLE 0x7bd0ec80
dt FxObject 0x84384700 : WDFHANDLE 0x7bc7b8f8
dt FxObject 0x845CA3D0 : WDFHANDLE 0x7ba35c28
dt FxObject 0x8458A780 : WDFHANDLE 0x7ba75878
dt FxObject 0x848FE2F0 : WDFHANDLE 0x7b701d08
dt FxObject 0x84319318 : WDFHANDLE 0x7bce6ce0
dt FxObject 0x845DDA48 : WDFHANDLE 0x7ba225b0
----------------------------------
No objects in a state where they could have been leaked.
(An object must not be in the created state to be detected.)
----------------------------------

WDF Verifier settings for hibusb.sys is ON
Pool tracking is ON
Handle verification is ON
IO verification is ON
Lock verification is ON
Handle reference tracking is ON for the following types:
WDFDRIVER WDFDEVICE WDFQUEUE WDFWMIPROVIDER WDFKEY WDFSTRING
WDFREQUEST
WDFLOOKASIDE WDFMEMORY WDFOBJECT WDFCOLLECTION WDFDPC WDFFILEOBJECT
WDFWAITLOCK WDFSPINLOCK WDFWORKITEM WDFINTERRUPT WDFTIMER
WDFCHILDLIST
WDFWMIINSTANCE WDFIORESLIST WDFCMRESLIST WDFIORESREQLIST WDFIOTARGET
WDFUSBDEVICE WDFUSBPIPE WDFUSBINTERFACE WDFDMAENABLER
WDFDMATRANSACTION
WDFCOMMONBUFFER
----------------------------------

“Bob Kjelgaard” wrote in message
news:xxxxx@ntdev…
David-

KMDF 1.5 is the latest we can support (the 1.7 in the Beta3 WDK can only
be
used on the Beta 3 LHS build, IIRC), so that’s not a problem.

If hibusb is your driver, then the key you want to change is
hklm/system/currentcontrolset/services/hibusb/parameters/wdf, not the
one in
your earlier post. !wdfdriverinfo will tell you if the verifier is on
for
your driver (but you may need to turn on additional flag bits to see
that
level of detail).

Also, Doron tells me that we won’t consider it a leak unless it has
references outstanding at unload time (which makes sense, of course).
So if
(for instance) you just allocate a lot of WDFMEMORY parented to your
driver
and never delete any of it, it won’t get caught [we can’t really tell
what
you want that memory for in that case].

If you’re still seeing large amounts of pool consumed, and wdfdriverinfo

isn’t showing any additional objects, then (assuming you are still using
DV
against wdf01000.sys) please try !verifier 3 wdf01000.sys. It should
show
everything the framework has allocated. If that’s a lot of output you
can
email it to me as an attachment.

Thanks for your persistence- if this is somehow a framework bug, we
don’t
want it to escape. If it isn’t, it’s still valuable to understand what
works for you and what doesn’t.

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer