Fixed - Driver Verifier and non-paged pool memory leak

It always seems so obvious once you find the problem.

I was calling “WdfMemoryCreate” without first setting the parent object to
something meaningful like the request object. This caused WDFHANDLE objects
to be left over until the device was unplugged. I’ve now set the parent
using:
WDF_OBJECT_ATTRIBUTES_INIT(&memAttributes);
memAttributes.ParentObject = pDC->m_hIoRequest;
WdfMemoryCreate(&memAttributes,…)

Thanks to everyone who helped.

-Dave

“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

I forgot the WDFMEMORYs show up as WDFOBJECTS (due to an internal
bookkeeping reason). I should blog about that and make sure this gets
captured in the documentation. Glad you found the issue

d

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

It always seems so obvious once you find the problem.

I was calling “WdfMemoryCreate” without first setting the parent object
to
something meaningful like the request object. This caused WDFHANDLE
objects
to be left over until the device was unplugged. I’ve now set the parent

using:
WDF_OBJECT_ATTRIBUTES_INIT(&memAttributes);
memAttributes.ParentObject = pDC->m_hIoRequest;
WdfMemoryCreate(&memAttributes,…)

Thanks to everyone who helped.

-Dave

“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


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