KMDF intro question: Request not being fwd'ed / OSR sample

Hi

Just started on KMDf . I have a requirement to do something like that is described in latest NT insider - Inverted call mode.

OSR sample = the default Q handles ICOTLs, fwd ICOTL1 to NotificationQ, when ICOTL2 comes retrieve/complete ICOTL1 as well.

But I do not see requests being forwarded to the (notification) queue.
The driver I got already has a default queue and IOCTL queue.
It forwards all ICOTLs from defaultQ to IOCTL queue.
I added 2 IOCTLs and fwded those as well to IOCTL queue (EvtIODeviceControl())
Rest of below is just based on the OSR sample
***
I fwd the ICOTL1 to NotificationQ.
For ICOTL2, I try to pull IOCTL1 from NotificationQ and complete these both.

what I am observing is the ICOTL1 never gets **re-fwded*** to the Notification-Q. Just before I fwd, I do below


queueStatus = WdfIoQueueGetState(Ext->NotificationQueue, NULL, NULL );
DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL, “Q_Status = 0x%X\n”, queueStatus);

Above always (i.e. even after I send xple IOCTL1s’ from app) prints below, which means the queue is ready, but no requests are pending.
Q_Status = 0xF - WDF_IO_QUEUE_STATE

Also below call to fwd is also always success.
status = WdfRequestForwardToIoQueue(Request, Ext->NotificationQueue);
if(!NT_SUCCESS(status)) …

But it returns below
InvertedNotify: Failed to retrieve request. Status = 0x8000001a –>
#define STATUS_NO_MORE_ENTRIES ((NTSTATUS)0x8000001AL)

> I created Notification Q like below
WDF_IO_QUEUE_CONFIG_INIT(&queueConfig,
WdfIoQueueDispatchManual);

queueConfig.PowerManaged = WdfFalse;

status = WdfIoQueueCreate(Device,
&queueConfig,
WDF_NO_OBJECT_ATTRIBUTES,
&Ext->NotificationQueue);

So The call to fwd the 2nd time (to a different Q) is successful, but neither
> WdfIoQueueGetState() nor WdfIoQueueRetrieveNextRequest(NotificationQ) return what I expect/need.

Let me know anyways to debug.

Thx

Run !wdfkd.wdfqueue on both queues to see what each of their state is as well as the list of requests in each

d

Bent from my phone


From: xxxxx@yahoo.commailto:xxxxx
Sent: ?4/?24/?2013 6:26 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: [ntdev] KMDF intro question: Request not being fwd’ed / OSR sample

Hi

Just started on KMDf . I have a requirement to do something like that is described in latest NT insider - Inverted call mode.

OSR sample = the default Q handles ICOTLs, fwd ICOTL1 to NotificationQ, when ICOTL2 comes retrieve/complete ICOTL1 as well.

But I do not see requests being forwarded to the (notification) queue.
The driver I got already has a default queue and IOCTL queue.
It forwards all ICOTLs from defaultQ to IOCTL queue.
I added 2 IOCTLs and fwded those as well to IOCTL queue (EvtIODeviceControl())
Rest of below is just based on the OSR sample

I fwd the ICOTL1 to NotificationQ.
For ICOTL2, I try to pull IOCTL1 from NotificationQ and complete these both.

>what I am observing is the ICOTL1 never gets
re-fwded
** to the Notification-Q. Just before I fwd, I do below


queueStatus = WdfIoQueueGetState(Ext->NotificationQueue, NULL, NULL );
DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL, “Q_Status = 0x%X\n”, queueStatus);

Above always (i.e. even after I send xple IOCTL1s’ from app) prints below, which means the queue is ready, but no requests are pending.
Q_Status = 0xF - WDF_IO_QUEUE_STATE

Also below call to fwd is also always success.
status = WdfRequestForwardToIoQueue(Request, Ext->NotificationQueue);
if(!NT_SUCCESS(status)) …

But it returns below
InvertedNotify: Failed to retrieve request. Status = 0x8000001a –>
#define STATUS_NO_MORE_ENTRIES ((NTSTATUS)0x8000001AL)

> I created Notification Q like below
WDF_IO_QUEUE_CONFIG_INIT(&queueConfig,
WdfIoQueueDispatchManual);

queueConfig.PowerManaged = WdfFalse;

status = WdfIoQueueCreate(Device,
&queueConfig,
WDF_NO_OBJECT_ATTRIBUTES,
&Ext->NotificationQueue);

So The call to fwd the 2nd time (to a different Q) is successful, but neither
> WdfIoQueueGetState() nor WdfIoQueueRetrieveNextRequest(NotificationQ) return what I expect/need.

Let me know anyways to debug.

Thx


NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

Thanks, I did some debug and below is where I am at.

2: kd> dt devExt
+0x208 writesQueue : 0x0000057ff72a7fd8 WDFQUEUE__ +0x210 readsQueue : 0x0000057ff7ac8fd8 WDFQUEUE__ (IOCTL-Q)
+0x218 NotificationQueue : 0x0000057f`f7bc33a8 WDFQUEUE__ (the Q I created)

  1. Once I have fwd'ed the ICOTL-1 from (manual->IOCTL), below is the state.

>>>>>>Good I am processing the one as of now

2: kd> !WDFQUEUE 0x0000057f`f72a7fd8

Dumping WDFQUEUE 0x0000057ff72a7fd8

Sequential, Power-managed, PowerOn, Can accept, Can dispatch, Dispatching, ExecutionLevelDispatch, SynchronizationScopeNone
Number of driver owned requests: 1
!WDFREQUEST 0x0000057ff975b1a8 !IRP 0xfffffa8006bc3510
Number of waiting requests: 0

EvtIoWrite: (0xfffff88006a87a40) !EvtIoWrite
EvtIoDeviceControl: (0xfffff88006a85770) !EvtIoDeviceControl
EvtIoInternalDeviceControl: (0xfffff88006a86840) !EvtIoInternalDeviceControl
EvtIoCanceledOnQueue: (0xfffff88006a83f20) !EvtIoCanceledOnQueue

2: kd> !WDFQUEUE 0x0000057f`f7bc33a8

Dumping WDFQUEUE 0x0000057ff7bc33a8

Manual, Not power-managed, PowerOn, Can accept, Can dispatch, ExecutionLevelDispatch, SynchronizationScopeNone
Number of driver owned requests: 0
Number of waiting requests: 0

2: kd> !WDFREQUEST 0x0000057ff975b1a8 --> This is my ICOTL1(IRP)
!IRP 0xfffffa8006bc3510

!WDFQUEUE 0x0000057ff7bc33a8
State: Pending, Allocated by WDF for incoming IRP
System Buffer 0xfffffa80068d56c0, Length 0x0, !WDFMEMORY 0x0000057ff975b0e1
IOCTL Output Buffer 0xfffffa80068d56c0, Length 0x4, !WDFMEMORY 0x0000057ff975b0d1

  1. Then I fwd this request to my Notification queue

>>>>>>>>>>Good Notification-Q shows that request

2: kd> g
Q_Status = 0xB (WDF_IO_QUEUE_STATE)

2: kd> !WDFQUEUE 0x0000057ff72a7fd8<br><br>Dumping WDFQUEUE 0x0000057ff72a7fd8<br>=========================<br>Sequential, Power-managed, PowerOn, Can accept, Can dispatch, Dispatching, ExecutionLevelDispatch, SynchronizationScopeNone<br> Number of driver owned requests: 0<br> Number of waiting requests: 0<br><br>EvtIoWrite: (0xfffff88006a87a40) !EvtIoWrite<br> EvtIoDeviceControl: (0xfffff88006a85770) !EvtIoDeviceControl<br> EvtIoInternalDeviceControl: (0xfffff88006a86840) !EvtIoInternalDeviceControl<br> EvtIoCanceledOnQueue: (0xfffff88006a83f20) !EvtIoCanceledOnQueue<br><br>2: kd&gt; !WDFQUEUE 0x0000057ff7bc33a8 -->NotificationQ owns it now

Dumping WDFQUEUE 0x0000057ff7bc33a8 --> Notification Q now owns that IRP
=========================
Manual, Not power-managed, PowerOn, Can accept, Can dispatch, ExecutionLevelDispatch, SynchronizationScopeNone
Number of driver owned requests: 0
Number of waiting requests: 1
!WDFREQUEST 0x0000057ff975b1a8 !IRP 0xfffffa8006bc3510

3) Now I have enabled bp's all WdfRequestComplete[XXX] in my code
2: kd> be *

4) I hit below BP() which has my above Request.

*** I do not understand, my REQUEST ended up in EvtDeviceFileCreate() and that completed it!!!

2: kd> p
!EvtDeviceFileCreate+0x24c:
fffff88006a7324c 488d0575ef0100 lea rax,[TeeDriverx64!WPP_GLOBAL_Control (fffff88006a921c8)]
2: kd> !WDFREQUEST 0x0000057ff975b1a8
!IRP 0x0000000000000000
irp is NULL, the remaining results may not be correct(Reserved Requests may have a NULL IRP)...

State: Completed, Allocated by WDF for incoming IRP

I am sure I have put breakpoints on all the places I explicitly do WdfRequestComplete[XXX].
Not sure how the request(completed and reused as different request) and got to EvtDeviceFileCreate.

Will scan code again and try KMDF logs to see if I can find something.

xxxxx@yahoo.com wrote:

  1. I hit below BP() which has my above Request.

*** I do not understand, my REQUEST ended up in EvtDeviceFileCreate() and that completed it!!!

2: kd> p
!EvtDeviceFileCreate+0x24c:
fffff88006a7324c 488d0575ef0100 lea rax,[TeeDriverx64!WPP_GLOBAL_Control (fffff88006a921c8)]

Did you do a stack trace here (“kb”)? Unless your EvtDeviceFileCreate
is large, this might actually be code from another library, so that
EvtDeviceFileCreate was merely the closest symbol.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Below is the o/p. my symbols seems alright
Mydriver!EvtDeviceFileCreate+0x24c [c:\srcs\srcs.c @ 728]

2: kd> kb
RetAddr : Args to Child : Call Site
fffff88000e6e0d4 : 0000057ff72a7558 0000057ff975b1a8 0000057ff7b800c8 fffff880067554b8 : Mydriver!EvtDeviceFileCreate+0x24c [c:\srcs\srcs.c @ 728] fffff88000e6c5ff : fffff88006755680 fffffa8006713b40 fffffa8006711401 0000000000000000 : Wdf01000!FxPkgGeneral::OnCreate+0x888
fffff88000e679da : fffffa8006aec860 fffffa80084ee1c8 fffffa8006aec860 0000000000000000 : Wdf01000!FxPkgGeneral::Dispatch+0x14f fffff88000e67aa6 : fffffa8006aec860 fffffa80084ee1c8 fffffa8006ad4a30 0000000000000000 : Wdf01000!FxDevice::Dispatch+0x19a
fffff800033d0625 : 0000000000000025 fffffa80084ee1c8 fffffa8008cc4b10 fffffa8006b74de8 : Wdf01000!FxDevice::DispatchWithLock+0xa6 fffff800033ccec8 : fffffa80066b1a10 0000000000000000 fffffa80084ee010 fffff8a000000001 : nt!IopParseDevice+0x5a5
fffff800033ce0e6 : 0000000000000000 fffffa80084ee010 0000000000000000 fffffa8006713b40 : nt!ObpLookupObjectName+0x588 fffff800033cf9ec : fffffa80068d56d0 0000000000000000 fffff80003258901 fffff8a002147540 : nt!ObOpenObjectByName+0x306
fffff800033da608 : 0000000000efe7d8 fffff8a0c0100080 0000000000eff0a0 0000000000efe7f0 : nt!IopCreateFile+0x2bc fffff800030d1f93 : fffffa8006867b30 0000000000000001 fffffa8006876b60 fffff800033c9bc4 : nt!NtCreateFile+0x78
0000000076de186a : 000000007372bff7 00000000016af8ac 00000000016af8c4 00000000016aeee8 : nt!KiSystemServiceCopyEnd+0x13 000000007372bff7 : 00000000016af8ac 00000000016af8c4 00000000016aeee8 0000000000efe7b0 : ntdll!ZwCreateFile+0xa
00000000016af8ac : 00000000016af8c4 00000000016aeee8 0000000000efe7b0 0000000000000000 : 0x7372bff7 00000000016af8c4 : 00000000016aeee8 0000000000efe7b0 0000000000000000 0000000000000000 : 0x16af8ac
00000000016aeee8 : 0000000000efe7b0 0000000000000000 0000000000000000 0000000000000003 : 0x16af8c4 0000000000efe7b0 : 0000000000000000 0000000000000000 0000000000000003 0000000000000001 : 0x16aeee8
0000000000000000 : 0000000000000000 0000000000000003 0000000000000001 00000000`00000040 : 0xefe7b0

Below is what I see in CreateDevice. So I have this handler in code.
WDF_FILEOBJECT_CONFIG_INIT(
&fileConfig,
EvtDeviceFileCreate,
EvtDeviceFileClose,
WDF_NO_EVENT_CALLBACK
);

fileConfig.FileObjectClass = WdfFileObjectCanBeOptional | WdfFileObjectWdfCanUseFsContext;

WdfDeviceInitSetFileObjectConfig(
DeviceInit,
&fileConfig,
&fileAttributes
);

xxxxx@yahoo.com wrote:

Below is the o/p. my symbols seems alright
Mydriver!EvtDeviceFileCreate+0x24c [c:\srcs\srcs.c @ 728]

Well, KMDF would not have reused the handle unless it had been released
in some way. There’s just not enough information here to chase it down
without seeing your code. You can send me your source code by private
email, if you wish, and I’ll give it a quick look.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Just after FWD'ing ICOTL-1 - REQ<0x0000057ff9722a08>[IRP:0xfffffa800847c0c0]

Dumping WDFQUEUE 0x0000057ff79453a8

Manual, Not power-managed, PowerOn, Can accept, Can dispatch, ExecutionLevelDispatch, SynchronizationScopeNone
Number of driver owned requests: 0
Number of waiting requests: 1
!WDFREQUEST 0x0000057ff9722a08 !IRP 0xfffffa800847c0c0

0: kd> !WDFREQUEST 0x0000057ff9722a08
!IRP 0xfffffa800847c0c0

!WDFQUEUE 0x0000057ff79453a8
State: Pending, Allocated by WDF for incoming IRP
System Buffer 0xfffffa80088d6900, Length 0x0, !WDFMEMORY 0x0000057ff9722941
IOCTL Output Buffer 0xfffffa80088d6900, Length 0x4, !WDFMEMORY 0x0000057ff9722931

Now enabled all BP()'s on all WDFRequestCompletexxx;
0: kd> be *
0: kd> g
EvtDeviceFileCreate - Call WdfRequestComplete. Request: 0x0000057FF9722A08, Info: 0x0 status: !STATUS!
Breakpoint 4 hit
MyDriver!EvtDeviceFileCreate+0x1bd:

2: kd> !WDFREQUEST 0x0000057ff9722a08
!IRP 0xfffffa8006949ea0

!WDFQUEUE 0x0000057ff9754fd8
State: Pending, Allocated by WDF for incoming IRP

Somehow my REQ<0x0000057ff9722a08>[IRP:0xfffffa800847c0c0]
got complete and KMDF used that REQ<0x0000057ff9722a08> to contain a different [IRP:0xfffffa8006949ea0] in this case IRP_MJ_CREATE

IS there any mechanism in KMDF that the framework decides all by itself to cancel (or complete) a REQ.? !

Looking at drain/purge path/workarounds. Scanning code again and also kmdf logs as well...

I don' think you are actually setting the breakpoints you think are setting. All Wdf API calls are really forceinline calls to invoke a jump through a table. The compiler can easily not embed the actual api name in the image. You are seeing the same request value because kmdf uses a lookaside list to allocate requests, so what most likely happened is you completed the request and kmdf reused the memory. There is a canceledonqueue callback you can register for. Otherwise, I suggest trying to debug a debug/chk version of the driver where the linker tends to respect the WDF API names in the image and the BPs you set are going to be closer to correct
d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Thursday, April 25, 2013 4:43 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] KMDF intro question: Request not being fwd'ed / OSR sample

Just after FWD'ing ICOTL-1 - REQ<0x0000057ff9722a08>[IRP:0xfffffa800847c0c0]

Dumping WDFQUEUE 0x0000057ff79453a8

Manual, Not power-managed, PowerOn, Can accept, Can dispatch, ExecutionLevelDispatch, SynchronizationScopeNone
Number of driver owned requests: 0
Number of waiting requests: 1
!WDFREQUEST 0x0000057ff9722a08 !IRP 0xfffffa800847c0c0

0: kd> !WDFREQUEST 0x0000057ff9722a08
!IRP 0xfffffa800847c0c0

!WDFQUEUE 0x0000057ff79453a8
State: Pending, Allocated by WDF for incoming IRP
System Buffer 0xfffffa80088d6900, Length 0x0, !WDFMEMORY 0x0000057ff9722941
IOCTL Output Buffer 0xfffffa80088d6900, Length 0x4, !WDFMEMORY 0x0000057ff9722931

Now enabled all BP()'s on all WDFRequestCompletexxx;
0: kd> be *
0: kd> g
EvtDeviceFileCreate - Call WdfRequestComplete. Request: 0x0000057FF9722A08, Info: 0x0 status: !STATUS!
Breakpoint 4 hit
MyDriver!EvtDeviceFileCreate+0x1bd:

2: kd> !WDFREQUEST 0x0000057ff9722a08
!IRP 0xfffffa8006949ea0

!WDFQUEUE 0x0000057ff9754fd8
State: Pending, Allocated by WDF for incoming IRP

Somehow my REQ<0x0000057ff9722a08>[IRP:0xfffffa800847c0c0]
got complete and KMDF used that REQ<0x0000057ff9722a08> to contain a different [IRP:0xfffffa8006949ea0] in this case IRP_MJ_CREATE

IS there any mechanism in KMDF that the framework decides all by itself to cancel (or complete) a REQ.? !

Looking at drain/purge path/workarounds. Scanning code again and also kmdf logs as well...


NTDEV is sponsored by OSR

OSR is HIRING!! See Careers – OSR

For our schedule of WDF, WDM, debugging and other seminars visit:

To unsubscribe, visit the List Server section of OSR Online at ListServer/Forum

xxxxx@yahoo.com wrote:

Now enabled all BP()'s on all WDFRequestCompletexxx;
0: kd> be *
0: kd> g
EvtDeviceFileCreate - Call WdfRequestComplete. Request: 0x0000057FF9722A08, Info: 0x0 status: !STATUS!
Breakpoint 4 hit
MyDriver!EvtDeviceFileCreate+0x1bd:

Why is there another call to EvtDeviceFileCreate? Is your test
application creating another handle?

Rather than sprinkling breakpoints in your own code, why not put a
breakpoint on WdfRequestComplete? Then you can look at the traceback to
figure out where it was called.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Thanks Both.

My ICOTL-Q already had EvtIoCanceledOnQueue, but it was never called in this situation.

So I added EvtIoCanceledOnQueue() to my new manual/NotificiationQ as well.
I see it being called immediatly below once ICOTL-1 is returned as pending.

Basically loosk like my cmdline cpp app is wrong, I did not modify that well. It was like below :-)… sry…

option1: wait for notify
a) createFile
b)DeviceIoControl(IOCTL1) –> expect it to return pending
c)Close file

option:trigger notify
a) createFile
b)DeviceIoControl(IOCTL2) –> complete IOCTL1 and 2 as well
c)Close file

So I am taking it as, after option1.c, I/O mgr requested KMDF to cancel all IRPs’

>
Why is there another call to EvtDeviceFileCreate? Is your test
application creating another handle?

The driver I got exists in such ecosystem, soembody is calling CreateFile()/DeviceIOCtrl/ MJ_READ/WRITE continously (even before I fire my app).
I got lost in those o/put and was chasing for a WdfReQcomplete() breakpoint/print, until i was nudged about EvtIoCanceledOnQueue()

(I have asked the primary driver owner on who is calling createfile/DeviceIO() so often, so that I can disable those services/apps untill I finish/test my code! :slight_smile:

KMDF is good!

>
I suggest trying to debug a debug/chk version of the driver where the
linker tends to respect the WDF API names in the image and the BPs you set are
going to be closer to correct
<<
WDK dirs did not list a debug KMDF.sys = Wdf01000.sys?
or do I need to install chk ver of OS?
or just chk versions of wdfcoinst*.dlls’?

Thx

and the call stack is

fffff8800284d4f0 fffff88000fb75cf Mydrv!EvtIoCanceledOnQueue+0x55c [c:\srcs\c.c @ 2476]
fffff8800284d5d0 fffff88000f36f7c Wdf01000!FxIoQueue::ProcessCancelledRequestsOnQueue+0x1bf
fffff8800284d640 fffff88000fb6b1f Wdf01000!FxIoQueue::DispatchEvents+0x1bc
fffff8800284d6c0 fffff88000f4343b Wdf01000!FxIoQueue::CancelForQueue+0x32f
fffff8800284d730 fffff88000f41537 Wdf01000!FxPkgIo::FlushAllQueuesByFileObject+0x1ab
fffff8800284d7c0 fffff88000f40583 Wdf01000!FxPkgGeneral::OnCleanup+0x117
fffff8800284d810 fffff88000f3b9da Wdf01000!FxPkgGeneral::Dispatch+0xd3
fffff8800284d870 fffff88000f3baa6 Wdf01000!FxDevice::Dispatch+0x19a
fffff8800284d8b0 fffff8000338a09f Wdf01000!FxDevice::DispatchWithLock+0xa6
fffff8800284d8f0 fffff80003379844 nt!IopCloseFile+0x11f
fffff8800284d980 fffff80003379601 nt!ObpDecrementHandleCount+0xb4
fffff8800284da00 fffff80003379bc4 nt!ObpCloseHandleTableEntry+0xb1
fffff8800284da90 fffff80003081f93 nt!ObpCloseHandle+0x94
fffff8800284dae0 000000007799140a nt!KiSystemServiceCopyEnd+0x13
000000000021f508 000007fefd941863 ntdll!ZwClose+0xa
000000000021f510 0000000077842f61 KERNELBASE!CloseHandle+0x13
000000000021f540 000007fef7181c79 kernel32!CloseHandleImplementation+0x3d
000000000021f650 cccccccccccccccc 0x000007fef7181c79 000000000021f658 cccccccccccccccc 0xcccccccccccccccc
000000000021f660 cccccccccccccccc 0xcccccccccccccccc 000000000021f668 cccccccccccccccc 0xcccccccccccccccc
000000000021f670 000000000021f730 0xcccccccccccccccc 000000000021f678 000000013f625c62 0x21f730 000000000021f680 000000000021f6d8 0x000000013f625c62
000000000021f688 000007fef09ccec0 0x21f6d8
000000000021f690 0000000000000000 MSVCP110D!IsProcessorFeaturePresent+0x3a50

You close the handle all io sent on thay handle gets purged . If stateful, you need to deal with that in this callback

d

Bent from my phone


From: xxxxx@yahoo.commailto:xxxxx
Sent: ?4/?25/?2013 7:56 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] KMDF intro question: Request not being fwd’ed / OSR sample

and the call stack is

fffff8800284d4f0 fffff88000fb75cf Mydrv!EvtIoCanceledOnQueue+0x55c [c:\srcs\c.c @ 2476]
fffff8800284d5d0 fffff88000f36f7c Wdf01000!FxIoQueue::ProcessCancelledRequestsOnQueue+0x1bf
fffff8800284d640 fffff88000fb6b1f Wdf01000!FxIoQueue::DispatchEvents+0x1bc
fffff8800284d6c0 fffff88000f4343b Wdf01000!FxIoQueue::CancelForQueue+0x32f
fffff8800284d730 fffff88000f41537 Wdf01000!FxPkgIo::FlushAllQueuesByFileObject+0x1ab
fffff8800284d7c0 fffff88000f40583 Wdf01000!FxPkgGeneral::OnCleanup+0x117
fffff8800284d810 fffff88000f3b9da Wdf01000!FxPkgGeneral::Dispatch+0xd3
fffff8800284d870 fffff88000f3baa6 Wdf01000!FxDevice::Dispatch+0x19a
fffff8800284d8b0 fffff8000338a09f Wdf01000!FxDevice::DispatchWithLock+0xa6
fffff8800284d8f0 fffff80003379844 nt!IopCloseFile+0x11f
fffff8800284d980 fffff80003379601 nt!ObpDecrementHandleCount+0xb4
fffff8800284da00 fffff80003379bc4 nt!ObpCloseHandleTableEntry+0xb1
fffff8800284da90 fffff80003081f93 nt!ObpCloseHandle+0x94
fffff8800284dae0 000000007799140a nt!KiSystemServiceCopyEnd+0x13
000000000021f508 000007fefd941863 ntdll!ZwClose+0xa
000000000021f510 0000000077842f61 KERNELBASE!CloseHandle+0x13
000000000021f540 000007fef7181c79 kernel32!CloseHandleImplementation+0x3d
000000000021f650 cccccccccccccccc 0x000007fef7181c79<br>000000000021f658 cccccccccccccccc 0xcccccccccccccccc
000000000021f660 cccccccccccccccc 0xcccccccccccccccc<br>000000000021f668 cccccccccccccccc 0xcccccccccccccccc
000000000021f670 000000000021f730 0xcccccccccccccccc<br>000000000021f678 000000013f625c62 0x21f730<br>000000000021f680 000000000021f6d8 0x000000013f625c62
000000000021f688 000007fef09ccec0 0x21f6d8
000000000021f690 0000000000000000 MSVCP110D!IsProcessorFeaturePresent+0x3a50


NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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