Can someone tell me what this KMDF failure is?

Jonathan_Ludwig-3 · August 17, 2009, 5:48pm

I’m seeing a failure on KMDF. I want to see if someone can tell me what the functions in this call stack do. I don’t know what this early dispose worker is. I just need to know where to start looking at this problem.

Thanks,

Jonathan

OSR_Community_User · August 17, 2009, 5:52pm

Well, how about you show us what you have - !analyze -v, !wdfkd.wdflogdump, et. c.

Also, a description of the problem and your testing scenario (i. e. - target machine, os, et. c.) would be helpful.

Good luck,

mm

Jonathan_Ludwig-3 · August 17, 2009, 6:36pm

I've got to stop working late. I had the stack in the clipboard, but forgot to paste it. I'm sure I'm doing something wrong, but I need somedirection:

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: ffffffffffffffd8, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffffadf9eedea91, address which referenced memory

Debugging Details:

READ_ADDRESS: ffffffffffffffd8

CURRENT_IRQL: 0

FAULTING_IP:
Wdf01000!FxObject::DisposeChildrenWorker+f1
fffffadf`9eedea91 8a41d8 mov al,byte ptr [rcx-28h]

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

TRAP_FRAME: fffffadfa3a8c000 -- (.trap 0xfffffadfa3a8c000)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=fffff800013de255 rcx=0000000000000000
rdx=fffff9817dc47000 rsi=fffffadfa3a8c378 rdi=fffffadfa3a8c370
rip=fffff80001292371 rsp=fffffadfa3a8c190 rbp=fffffadfac28f490
r8=000000000000000f r9=0000000000000000 r10=0000000000000001
r11=fffffadfa3a8c290 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz ac pe cy
nt!CcMapData+0x14c:
Page 213fc not present in the dump file. Type ".hh dbgerr004" for details
fffff80001292371 0fb602 movzx eax,byte ptr [rdx] ds:fffff9817dc47000=??
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff8000102e5b4 to fffff8000102e890

STACK_TEXT:
fffffadfa3a8a808 fffff8000102e5b4 : 000000000000000a ffffffffffffffd8 0000000000000002 0000000000000000 : nt!KeBugCheckEx
fffffadfa3a8a810 fffff8000102d547 : 00000000000000f0 fffff8000103c3c3 fffffadfa3a8e000 0000000000000001 : nt!KiBugCheckDispatch+0x74
fffffadfa3a8a990 fffffadf9eedea91 : fffffadfac7595d0 fffffadf9eeb34e2 fffffadfac959db0 fffff80001030d45 : nt!KiPageFault+0x207
fffffadfa3a8ab20 fffffadf9eede5c8 : fffffadfacd43820 0000000000000001 0000000000000002 fffffabc24828f01 : Wdf01000!FxObject::DisposeChildrenWorker+0xf1
fffffadfa3a8aba0 fffffadf9eede789 : fffffadfacd43820 0000000000000000 0000000000000001 fffffadf9eead322 : Wdf01000!FxObject::PerformDisposingDisposeChildrenLocked+0xbc
fffffadfa3a8ac10 fffffadf9eede4e4 : fffffadfacd43820 0000000000000002 fffffadfabbf7c02 0000000000000005 : Wdf01000!FxObject::PerformEarlyDisposeWorkerAndUnlock+0xf5
fffffadfa3a8ac80 fffffadf9eead68a : 0000000000000000 fffffadfabbf7c50 0000000000000001 0000000000000000 : Wdf01000!FxObject::EarlyDispose+0x110
fffffadfa3a8ace0 fffffadf9ee9e13e : 0000000000000002 0000000000000001 fffffadface3a801 fffffabc25c76e10 : Wdf01000!FxRequest::CompleteInternal+0x27e
fffffadfa3a8ad90 fffffadf9ef2193e : fffffadfacc66a02 fffffadfacd43820 fffffadfac05fe70 0000052053f8f6f8 : Wdf01000!imp_WdfRequestCompleteWithInformation+0x1aa
fffffadfa3a8ae00 fffffadf9ef2d001 : 00000520532bc7d8 0000052000000000 0000000000000020 fffffadfa3a8aea8 : GenericMount!WdfRequestCompleteWithInformation+0x2e [d:\componentreleases\genericmountdriver_main\wdk\inc\wdf\kmdf\1.9\wdfrequest.h @ 1038]
fffffadfa3a8ae30 fffffadf9ef2b4cd : fffffadfac759940 0000000000000000 fffffadfa3a8af90 00000000000001ea : GenericMount!GmdProcessNextGetPendingIoRequest+0x1081 [d:\componentreleases\genericmountdriver_main\ws\genericmountdriver\dev\driver\gmdio.cpp @ 689]
fffffadfa3a8af60 fffffadf9ef265a2 : fffffadfac759940 0000052053fa0188 0000000000000000 fffffadface3a890 : GenericMount!GmdProcessIncomingIo+0x46d [d:\componentreleases\genericmountdriver_main\ws\genericmountdriver\dev\driver\gmdio.cpp @ 212]
fffffadfa3a8b020 fffffadf9eec4d43 : 0000052053f8f6f8 0000052053fa0188 0000000000001000 0000000000000007 : GenericMount!GmdFdoDeviceEvtIoRead+0x282 [d:\componentreleases\genericmountdriver_main\ws\genericmountdriver\dev\driver\gmdfdo.cpp @ 428]
fffffadfa3a8b0c0 fffffadf9eec499f : fffffadfac05fe01 fffffadfac05fe70 fffffadfac070900 fffffadfac070900 : Wdf01000!FxIoQueue::DispatchRequestToDriver+0x26b
fffffadfa3a8b140 fffffadf9eec3f98 : 0000000000000000 0000000000000001 0000000000000000 fffffadfac05ffc2 : Wdf01000!FxIoQueue::DispatchEvents+0x4df
fffffadfa3a8b1b0 fffffadf9eec9558 : fffffabc25612f01 fffffadfac05fe70 fffffabc25612ca0 fffffadfac05fe70 : Wdf01000!FxIoQueue::QueueRequest+0x2bc
fffffadfa3a8b220 fffffadf9eeb3245 : fffffadfac05fe70 fffffadfac33feb0 fffffadfa3a8b300 fffffabc25612ca0 : Wdf01000!FxPkgIo::Dispatch+0x37c
fffffadfa3a8b2a0 fffff800013de255 : 0000000000000000 fffffabc25612ca0 fffff800013de255 fffff800013de255 : Wdf01000!FxDevice::Dispatch+0xa9
fffffadfa3a8b2d0 fffff800013de255 : 0000000000000000 fffffabc25612ca0 fffffadfa2f6b7d9 fffffadfac33ff60 : nt!IovCallDriver+0x1b5
fffffadfa3a8b340 fffffadfa2f6b7d9 : 0000000000000000 fffffabc25612ca0 fffffadfac83cb70 fffffabc25612ca0 : nt!IovCallDriver+0x1b5

David_R_Cattley · August 17, 2009, 6:45pm

0xffffffffffffffd8 sure looks like the result of a NULL pointer being
adjusted backward by -40 (decimal) bytes.

I'm not sure that helps.

Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@symantec.com
Sent: Monday, August 17, 2009 6:37 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Can someone tell me what this KMDF failure is?

I've got to stop working late. I had the stack in the clipboard, but forgot
to paste it. I'm sure I'm doing something wrong, but I need somedirection:

****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at
an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: ffffffffffffffd8, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffffadf9eedea91, address which referenced memory

Debugging Details:

READ_ADDRESS: ffffffffffffffd8

CURRENT_IRQL: 0

FAULTING_IP:
Wdf01000!FxObject::DisposeChildrenWorker+f1
fffffadf`9eedea91 8a41d8 mov al,byte ptr [rcx-28h]

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

TRAP_FRAME: fffffadfa3a8c000 -- (.trap 0xfffffadfa3a8c000)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=fffff800013de255 rcx=0000000000000000
rdx=fffff9817dc47000 rsi=fffffadfa3a8c378 rdi=fffffadfa3a8c370
rip=fffff80001292371 rsp=fffffadfa3a8c190 rbp=fffffadfac28f490
r8=000000000000000f r9=0000000000000000 r10=0000000000000001
r11=fffffadfa3a8c290 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz ac pe cy
nt!CcMapData+0x14c:
Page 213fc not present in the dump file. Type ".hh dbgerr004" for details
fffff80001292371 0fb602 movzx eax,byte ptr [rdx] ds:fffff9817dc47000=??
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff8000102e5b4 to fffff8000102e890

STACK_TEXT:
fffffadfa3a8a808 fffff8000102e5b4 : 000000000000000a ffffffffffffffd8
0000000000000002 0000000000000000 : nt!KeBugCheckEx
fffffadfa3a8a810 fffff8000102d547 : 00000000000000f0 fffff8000103c3c3
fffffadfa3a8e000 0000000000000001 : nt!KiBugCheckDispatch+0x74
fffffadfa3a8a990 fffffadf9eedea91 : fffffadfac7595d0 fffffadf9eeb34e2
fffffadfac959db0 fffff80001030d45 : nt!KiPageFault+0x207
fffffadfa3a8ab20 fffffadf9eede5c8 : fffffadfacd43820 0000000000000001
0000000000000002 fffffabc24828f01 :
Wdf01000!FxObject::DisposeChildrenWorker+0xf1
fffffadfa3a8aba0 fffffadf9eede789 : fffffadfacd43820 0000000000000000
0000000000000001 fffffadf9eead322 :
Wdf01000!FxObject::PerformDisposingDisposeChildrenLocked+0xbc
fffffadfa3a8ac10 fffffadf9eede4e4 : fffffadfacd43820 0000000000000002
fffffadfabbf7c02 0000000000000005 :
Wdf01000!FxObject::PerformEarlyDisposeWorkerAndUnlock+0xf5
fffffadfa3a8ac80 fffffadf9eead68a : 0000000000000000 fffffadfabbf7c50
0000000000000001 0000000000000000 : Wdf01000!FxObject::EarlyDispose+0x110
fffffadfa3a8ace0 fffffadf9ee9e13e : 0000000000000002 0000000000000001
fffffadface3a801 fffffabc25c76e10 :
Wdf01000!FxRequest::CompleteInternal+0x27e
fffffadfa3a8ad90 fffffadf9ef2193e : fffffadfacc66a02 fffffadfacd43820
fffffadfac05fe70 0000052053f8f6f8 :
Wdf01000!imp_WdfRequestCompleteWithInformation+0x1aa
fffffadfa3a8ae00 fffffadf9ef2d001 : 00000520532bc7d8 0000052000000000
0000000000000020 fffffadfa3a8aea8 :
GenericMount!WdfRequestCompleteWithInformation+0x2e
[d:\componentreleases\genericmountdriver_main\wdk\inc\wdf\kmdf\1.9\wdfreques
t.h @ 1038]
fffffadfa3a8ae30 fffffadf9ef2b4cd : fffffadfac759940 0000000000000000
fffffadfa3a8af90 00000000000001ea :
GenericMount!GmdProcessNextGetPendingIoRequest+0x1081
[d:\componentreleases\genericmountdriver_main\ws\genericmountdriver\dev\driv
er\gmdio.cpp @ 689]
fffffadfa3a8af60 fffffadf9ef265a2 : fffffadfac759940 0000052053fa0188
0000000000000000 fffffadface3a890 :
GenericMount!GmdProcessIncomingIo+0x46d
[d:\componentreleases\genericmountdriver_main\ws\genericmountdriver\dev\driv
er\gmdio.cpp @ 212]
fffffadfa3a8b020 fffffadf9eec4d43 : 0000052053f8f6f8 0000052053fa0188
0000000000001000 0000000000000007 :
GenericMount!GmdFdoDeviceEvtIoRead+0x282
[d:\componentreleases\genericmountdriver_main\ws\genericmountdriver\dev\driv
er\gmdfdo.cpp @ 428]
fffffadfa3a8b0c0 fffffadf9eec499f : fffffadfac05fe01 fffffadfac05fe70
fffffadfac070900 fffffadfac070900 :
Wdf01000!FxIoQueue::DispatchRequestToDriver+0x26b
fffffadfa3a8b140 fffffadf9eec3f98 : 0000000000000000 0000000000000001
0000000000000000 fffffadfac05ffc2 :
Wdf01000!FxIoQueue::DispatchEvents+0x4df
fffffadfa3a8b1b0 fffffadf9eec9558 : fffffabc25612f01 fffffadfac05fe70
fffffabc25612ca0 fffffadfac05fe70 : Wdf01000!FxIoQueue::QueueRequest+0x2bc
fffffadfa3a8b220 fffffadf9eeb3245 : fffffadfac05fe70 fffffadfac33feb0
fffffadfa3a8b300 fffffabc25612ca0 : Wdf01000!FxPkgIo::Dispatch+0x37c
fffffadfa3a8b2a0 fffff800013de255 : 0000000000000000 fffffabc25612ca0
fffff800013de255 fffff800013de255 : Wdf01000!FxDevice::Dispatch+0xa9
fffffadfa3a8b2d0 fffff800013de255 : 0000000000000000 fffffabc25612ca0
fffffadfa2f6b7d9 fffffadfac33ff60 : nt!IovCallDriver+0x1b5
fffffadfa3a8b340 fffffadfa2f6b7d9 : 0000000000000000 fffffabc25612ca0
fffffadfac83cb70 fffffabc25612ca0 : nt!IovCallDriver+0x1b5

NTDEV is sponsored by OSR

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

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

Jonathan_Ludwig-3 · August 17, 2009, 6:51pm

Yes it is, but I don’t know anything about the dispose children work item so I have no idea what the pointer is.

OSR_Community_User · August 17, 2009, 7:01pm

Possibly the KMDF logs might have information about what happened.
http://blogs.msdn.com/iliast/archive/2009/06/09/viewing-wdf-logs-in-windbg.aspx has information about how to view them.

Ilias

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@symantec.com
Sent: Monday, August 17, 2009 3:52 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Can someone tell me what this KMDF failure is?

Yes it is, but I don’t know anything about the dispose children work item so I have no idea what the pointer is.

NTDEV is sponsored by OSR

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

Abhishek_R · August 17, 2009, 7:13pm

What is the output of !wdfrequest and !wdfobject debugger extensions for the
request that you’re trying to complete?
If the problem is reproducible, I’d suggest you collect the above
information just before the WdfRequestCompleteWithInformation method is
called.

wrote in message news:xxxxx@ntdev…
> I’ve got to stop working late. I had the stack in the clipboard, but
> forgot to paste it. I’m sure I’m doing something wrong, but I need
> somedirection:
>
> ***
> *
>
> * Bugcheck Analysis
>
> *
>
>
>
> DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
> An attempt was made to access a pageable (or completely invalid) address
> at an
> interrupt request level (IRQL) that is too high. This is usually
> caused by drivers using improper addresses.
> If kernel debugger is available get stack backtrace.
> Arguments:
> Arg1: ffffffffffffffd8, memory referenced
> Arg2: 0000000000000002, IRQL
> Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
> Arg4: fffffadf9eedea91, address which referenced memory
>
> Debugging Details:
> ------------------
>
>
> READ_ADDRESS: ffffffffffffffd8
>
> CURRENT_IRQL: 0
>
> FAULTING_IP:
> Wdf01000!FxObject::DisposeChildrenWorker+f1
> fffffadf9eedea91 8a41d8 mov al,byte ptr [rcx-28h] > > DEFAULT_BUCKET_ID: DRIVER_FAULT > > BUGCHECK_STR: 0xD1 > > TRAP_FRAME: fffffadfa3a8c000 -- (.trap 0xfffffadfa3a8c000) > NOTE: The trap frame does not contain all registers. > Some register values may be zeroed or incorrect. > rax=0000000000000000 rbx=fffff800013de255 rcx=0000000000000000 > rdx=fffff9817dc47000 rsi=fffffadfa3a8c378 rdi=fffffadfa3a8c370 > rip=fffff80001292371 rsp=fffffadfa3a8c190 rbp=fffffadfac28f490 > r8=000000000000000f r9=0000000000000000 r10=0000000000000001 > r11=fffffadfa3a8c290 r12=0000000000000000 r13=0000000000000000 > r14=0000000000000000 r15=0000000000000000 > iopl=0 nv up ei ng nz ac pe cy > nt!CcMapData+0x14c: > Page 213fc not present in the dump file. Type ".hh dbgerr004" for details > fffff80001292371 0fb602 movzx eax,byte ptr [rdx]
> ds:fffff9817dc47000=?? > Resetting default scope > > LAST_CONTROL_TRANSFER: from fffff8000102e5b4 to fffff8000102e890 > > STACK_TEXT: > fffffadfa3a8a808 fffff8000102e5b4 : 000000000000000a ffffffffffffffd8 > 0000000000000002 0000000000000000 : nt!KeBugCheckEx > fffffadfa3a8a810 fffff8000102d547 : 00000000000000f0 fffff8000103c3c3 > fffffadfa3a8e000 0000000000000001 : nt!KiBugCheckDispatch+0x74 > fffffadfa3a8a990 fffffadf9eedea91 : fffffadfac7595d0 fffffadf9eeb34e2 > fffffadfac959db0 fffff80001030d45 : nt!KiPageFault+0x207 > fffffadfa3a8ab20 fffffadf9eede5c8 : fffffadfacd43820 0000000000000001 > 0000000000000002 fffffabc24828f01 : > Wdf01000!FxObject::DisposeChildrenWorker+0xf1 > fffffadfa3a8aba0 fffffadf9eede789 : fffffadfacd43820 0000000000000000 > 0000000000000001 fffffadf9eead322 : > Wdf01000!FxObject::PerformDisposingDisposeChildrenLocked+0xbc > fffffadfa3a8ac10 fffffadf9eede4e4 : fffffadfacd43820 0000000000000002 > fffffadfabbf7c02 0000000000000005 : > Wdf01000!FxObject::PerformEarlyDisposeWorkerAndUnlock+0xf5 > fffffadfa3a8ac80 fffffadf9eead68a : 0000000000000000 fffffadfabbf7c50 > 0000000000000001 0000000000000000 : > Wdf01000!FxObject::EarlyDispose+0x110 > fffffadfa3a8ace0 fffffadf9ee9e13e : 0000000000000002 0000000000000001 > fffffadface3a801 fffffabc25c76e10 : > Wdf01000!FxRequest::CompleteInternal+0x27e > fffffadfa3a8ad90 fffffadf9ef2193e : fffffadfacc66a02 fffffadfacd43820 > fffffadfac05fe70 0000052053f8f6f8 : > Wdf01000!imp_WdfRequestCompleteWithInformation+0x1aa > fffffadfa3a8ae00 fffffadf9ef2d001 : 00000520532bc7d8 0000052000000000 > 0000000000000020 fffffadfa3a8aea8 : > GenericMount!WdfRequestCompleteWithInformation+0x2e > [d:\componentreleases\genericmountdriver_main\wdk\inc\wdf\kmdf\1.9\wdfrequest.h > @ 1038] > fffffadfa3a8ae30 fffffadf9ef2b4cd : fffffadfac759940 0000000000000000 > fffffadfa3a8af90 00000000000001ea : > GenericMount!GmdProcessNextGetPendingIoRequest+0x1081 > [d:\componentreleases\genericmountdriver_main\ws\genericmountdriver\dev\driver\gmdio.cpp > @ 689] > fffffadfa3a8af60 fffffadf9ef265a2 : fffffadfac759940 0000052053fa0188 > 0000000000000000 fffffadface3a890 : > GenericMount!GmdProcessIncomingIo+0x46d > [d:\componentreleases\genericmountdriver_main\ws\genericmountdriver\dev\driver\gmdio.cpp > @ 212] > fffffadfa3a8b020 fffffadf9eec4d43 : 0000052053f8f6f8 0000052053fa0188 > 0000000000001000 0000000000000007 : > GenericMount!GmdFdoDeviceEvtIoRead+0x282 > [d:\componentreleases\genericmountdriver_main\ws\genericmountdriver\dev\driver\gmdfdo.cpp > @ 428] > fffffadfa3a8b0c0 fffffadf9eec499f : fffffadfac05fe01 fffffadfac05fe70 > fffffadfac070900 fffffadfac070900 : > Wdf01000!FxIoQueue::DispatchRequestToDriver+0x26b > fffffadfa3a8b140 fffffadf9eec3f98 : 0000000000000000 0000000000000001 > 0000000000000000 fffffadfac05ffc2 : > Wdf01000!FxIoQueue::DispatchEvents+0x4df > fffffadfa3a8b1b0 fffffadf9eec9558 : fffffabc25612f01 fffffadfac05fe70 > fffffabc25612ca0 fffffadfac05fe70 : > Wdf01000!FxIoQueue::QueueRequest+0x2bc > fffffadfa3a8b220 fffffadf9eeb3245 : fffffadfac05fe70 fffffadfac33feb0 > fffffadfa3a8b300 fffffabc25612ca0 : Wdf01000!FxPkgIo::Dispatch+0x37c > fffffadfa3a8b2a0 fffff800013de255 : 0000000000000000 fffffabc25612ca0 > fffff800013de255 fffff800013de255 : Wdf01000!FxDevice::Dispatch+0xa9 > fffffadfa3a8b2d0 fffff800013de255 : 0000000000000000 fffffabc25612ca0 > fffffadfa2f6b7d9 fffffadfac33ff60 : nt!IovCallDriver+0x1b5 > fffffadfa3a8b340 fffffadfa2f6b7d9 : 0000000000000000 fffffabc25612ca0 > fffffadfac83cb70 fffffabc`25612ca0 : nt!IovCallDriver+0x1b5
>
>

Jonathan_Ludwig-3 · August 17, 2009, 7:54pm

I can get this information from the crash dump for the request I've just completed. Unfortunately the failure is random although it has happened more than once.

This is the request:

0: kd> !wdfrequest 0x00000520`532bc7d8
!IRP 0xfffffabc25c76e10
State: Completed, Allocated by WDF for incoming IRP
System Buffer 0xfffffadfacc4bb80, Length 0x4, !WDFMEMORY 0x00000520532bc709
IOCTL Output Buffer 0xfffffadf9ecf0000, Length 0x10000, MDL 0xfffffadfacc6f120, !WDFMEMORY 0x00000520532bc6f9

This is the underlying IRP:

0: kd> !IRP 0xfffffabc25c76e10
Irp is active with 4 stacks 2 is current (= 0xfffffabc25c76f28)
Mdl=fffffadfacc6f120: System buffer=fffffadfacc4bb80: Thread fffffadfacc80bf0: Irp stack trace.
cmd flg cl Device File Completion-Context
[0, 0] 0 10 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[e, 0] 5 e1 fffffadfac83ecf0 fffffadfac820d30 fffff800013f5200-fffffabc25c76f70 Success Error Cancel pending
\Driver\GenericMount nt!IovpInternalCompletionTrap
Args: 00010000 00000004 4d474032 00000000
[e, 0] 5 e1 fffffadfac2d0590 fffffadfac820d30 fffff800013f5200-fffffabc25c76fb8 Success Error Cancel pending
\Driver\GenericMount nt!IovpInternalCompletionTrap
Args: 00010000 00000004 4d474032 00000000
[e, 0] 5 0 fffffadfac1b4810 fffffadfac820d30 00000000-00000000
\DRIVER\VERIFIER_FILTER
Args: 00010000 00000004 4d474032 00000000

This is handle:

Dumping WDFHANDLE 0x00000520532bc7d8

Handle type is WDFREQUEST
Refcount: 1
Contexts:

!wdfobject 0xfffffadfacd43820

This is the !wdfobject output:

0: kd> !wdfobject 0xfffffadfacd43820

The type for object 0xfffffadfacd43820 is FxRequest
State: FxObjectStateDisposingDisposeChildren (0x4)
!wdfhandle 0x00000520532bc7d8

dt FxRequest 0xfffffadfacd43820

Contexts:

Object debug extension fffffadfacd43800
WARNING: Unable to verify timestamp for ATMFD.DLL
ERROR: Module load completed but symbols could not be loaded for ATMFD.DLL
ERROR: Module load completed but symbols could not be loaded for dump_mraid35x.sys
ERROR: Module load completed but symbols could not be loaded for secdrv.sys
ERROR: Module load completed but symbols could not be loaded for mraid35x.sys
ERROR: Module load completed but symbols could not be loaded for pnpfiltr.sys
ERROR: Module load completed but symbols could not be loaded for vmmemctl.sys
ERROR: Module load completed but symbols could not be loaded for CdaD10BA.sys
ERROR: Module load completed but symbols could not be loaded for CdaC15BA.sys
**********************************************************************
******
******
Your debugger is not using the correct symbols
******
In order for this command to work properly, your symbol path
must point to .pdb files that have full type information.
******
Certain .pdb files (such as the public OS symbols) do not
contain the required information. Contact the group that
provided you with these symbols if you need this command to
work.
******
Type referenced: FxObjectDebugExtensionValues
******
*************************************************************************
Extension signature incorrect...expected 0x0, got 0x444f7846
Verifier lock 0xfffffadfacd43700

I can't seem to get the symbols to work for this structure.

This is the FxRequest object:

0: kd> dt FxRequest 0xfffffadfacd43820
Wdf01000!FxRequest
+0x000 __VFN_table : 0xfffffadf9ef05260 +0x008 m_Type : 0x1008 +0x00a m_ObjectSize : 0x160 +0x00c m_Refcnt : 1 +0x010 m_Globals : 0xfffffadface3a890 _FX_DRIVER_GLOBALS
+0x018 m_ObjectFlags : 0x188
+0x018 m_ObjectFlagsByName : FxObject::::<unnamed-type-m_objectflagsbyname>
+0x01a m_ObjectState : 4
+0x020 m_ChildListHead : _LIST_ENTRY [0x0000000000000000 - 0xfffffadfacd43840]
+0x030 m_SpinLock : MxLock
+0x038 m_ParentObject : (null)
+0x040 m_ChildEntry : _LIST_ENTRY [0xfffffadfacd43860 - 0xfffffadfacd43860]
+0x050 m_DisposeSingleEntry : _SINGLE_LIST_ENTRY
+0x058 m_DeviceBase : 0xfffffadfac7595d0 FxDeviceBase +0x058 m_Device : 0xfffffadfac7595d0 FxDevice
+0x060 m_NPLock : MxLock
+0x068 m_CsqContext : _IO_CSQ_IRP_CONTEXT
+0x068 m_ListEntry : _LIST_ENTRY [0xfffffadf`00000001 - 0x0]
+0x080 m_DrainSingleEntry : _SINGLE_LIST_ENTRY
+0x080 m_NextStackLocationFormatted : 0 ''
+0x088 m_Irp : FxIrp
+0x090 m_Target : (null)
+0x098 m_RequestContext : (null)
+0x0a0 m_Timer : (null)
+0x0a8 m_CancelRoutine : FxRequestCancelCallback
+0x0b0 m_CompletionRoutine : FxRequestCompletionCallback
+0x0b8 m_TargetCompletionContext : (null)
+0x0c0 m_IrpCompletionReferenceCount : 0
+0x0c4 m_TargetFlags : 0 ''
+0x0c4 m_TargetFlagsByName : FxRequestBase::::<unnamed-type-m_targetflagsbyname>
+0x0c5 m_IrpAllocation : 0 ''
+0x0c6 m_Completed : 0x1 ''
+0x0c7 m_Canceled : 0 ''
+0x0c8 m_IrpReferenceCount : 0
+0x0d0 m_SystemBufferOffset : 0xd0
+0x0d2 m_VerifierFlags : 5
+0x0d2 m_VeriferFlagsByName : FxRequestBase::::<unnamed-type-m_veriferflagsbyname>
+0x0d8 m_IrpQueue : (null)
+0x0e0 m_OutputBufferOffset : 0xe0
+0x0e2 m_RequestBaseFlags : 0x2 ''
+0x0e2 m_RequestBaseFlagsByName : FxRequestBase::::<unnamed-type-m_requestbaseflagsbyname>
+0x0e3 m_RequestBaseStaticFlags : 0x1 ''
+0x0e3 m_RequestBaseStaticFlagsByName : FxRequestBase::::<unnamed-type-m_requestbasestaticflagsbyname>
+0x0e4 m_CompletionState : 0 ''
+0x0e8 m_AllocatedMdl : (null)
+0x0f0 m_IoQueue : (null)
+0x0f8 m_SystemBuffer : FxRequestSystemBuffer
+0x108 m_OutputBuffer : FxRequestOutputBuffer
+0x118 m_OwnerListEntry : _LIST_ENTRY [0xfffffadf`acd43938 - 0xfffffadf`acd43938]
+0x128 m_OwnerListEntry2 : _LIST_ENTRY [0xfffffadf`abbf7d68 - 0xfffffadf`abbf7d68]
+0x138 m_ForwardProgressList : _LIST_ENTRY [0xfffffadf`acd43958 - 0xfffffadf`acd43958]
+0x148 m_ForwardProgressQueue : (null)
+0x150 m_Presented : 0x1 ''
+0x151 m_PowerStopState : 0 ''
+0x152 m_Reserved : 0 ''
+0x153 m_ForwardRequestToParent : 0 ''</unnamed-type-m_requestbasestaticflagsbyname></unnamed-type-m_requestbaseflagsbyname></unnamed-type-m_veriferflagsbyname></unnamed-type-m_targetflagsbyname></unnamed-type-m_objectflagsbyname>

Doron_Holan · August 17, 2009, 8:38pm

What objects are you creating as children (or deeper) of the WDFREQUEST?

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: xxxxx@symantec.com
Sent: Monday, August 17, 2009 4:55 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Can someone tell me what this KMDF failure is?

I can get this information from the crash dump for the request I’ve just completed. Unfortunately the failure is random although it has happened more than once.

This is the request:

0: kd> !wdfrequest 0x00000520532bc7d8 !IRP 0xfffffabc25c76e10 State: Completed, Allocated by WDF for incoming IRP System Buffer 0xfffffadfacc4bb80, Length 0x4, !WDFMEMORY 0x00000520532bc709 IOCTL Output Buffer 0xfffffadf9ecf0000, Length 0x10000, MDL 0xfffffadfacc6f120, !WDFMEMORY 0x00000520532bc6f9 This is the underlying IRP: 0: kd> !IRP 0xfffffabc25c76e10 Irp is active with 4 stacks 2 is current (= 0xfffffabc25c76f28) Mdl=fffffadfacc6f120: System buffer=fffffadfacc4bb80: Thread fffffadfacc80bf0: Irp stack trace. cmd flg cl Device File Completion-Context [0, 0] 0 10 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 00000000 >[e, 0] 5 e1 fffffadfac83ecf0 fffffadfac820d30 fffff800013f5200-fffffabc25c76f70 Success Error Cancel pending \Driver\GenericMount nt!IovpInternalCompletionTrap Args: 00010000 00000004 4d474032 00000000 [e, 0] 5 e1 fffffadfac2d0590 fffffadfac820d30 fffff800013f5200-fffffabc25c76fb8 Success Error Cancel pending \Driver\GenericMount nt!IovpInternalCompletionTrap Args: 00010000 00000004 4d474032 00000000 [e, 0] 5 0 fffffadfac1b4810 fffffadfac820d30 00000000-00000000 \DRIVER\VERIFIER_FILTER Args: 00010000 00000004 4d474032 00000000 This is handle: Dumping WDFHANDLE 0x00000520532bc7d8 ============================= Handle type is WDFREQUEST Refcount: 1 Contexts: <no associated contexts or attribute callbacks> !wdfobject 0xfffffadfacd43820 This is the !wdfobject output: 0: kd> !wdfobject 0xfffffadfacd43820 The type for object 0xfffffadfacd43820 is FxRequest State: FxObjectStateDisposingDisposeChildren (0x4) !wdfhandle 0x00000520532bc7d8 dt FxRequest 0xfffffadfacd43820 Contexts: <no associated contexts or attribute callbacks> Object debug extension fffffadfacd43800 ***WARNING: Unable to verify timestamp for ATMFD.DLL *** ERROR: Module load completed but symbols could not be loaded for ATMFD.DLL ***ERROR: Module load completed but symbols could not be loaded for dump_mraid35x.sys *** ERROR: Module load completed but symbols could not be loaded for secdrv.sys ***ERROR: Module load completed but symbols could not be loaded for mraid35x.sys *** ERROR: Module load completed but symbols could not be loaded for pnpfiltr.sys ***ERROR: Module load completed but symbols could not be loaded for vmmemctl.sys *** ERROR: Module load completed but symbols could not be loaded for CdaD10BA.sys ***ERROR: Module load completed but symbols could not be loaded for CdaC15BA.sys ************************************************************************* ****** ****** ***Your debugger is not using the correct symbols*** ****** ***In order for this command to work properly, your symbol path*** ***must point to .pdb files that have full type information.*** ****** ***Certain .pdb files (such as the public OS symbols) do not*** ***contain the required information. Contact the group that*** ***provided you with these symbols if you need this command to*** ***work.*** ****** ***Type referenced: FxObjectDebugExtensionValues*** ****** ************************************************************************* Extension signature incorrect...expected 0x0, got 0x444f7846 Verifier lock 0xfffffadfacd43700 I can't seem to get the symbols to work for this structure. This is the FxRequest object: 0: kd> dt FxRequest 0xfffffadfacd43820 Wdf01000!FxRequest +0x000 __VFN_table : 0xfffffadf9ef05260
+0x008 m_Type : 0x1008
+0x00a m_ObjectSize : 0x160
+0x00c m_Refcnt : 1
+0x010 m_Globals : 0xfffffadface3a890 _FX_DRIVER_GLOBALS +0x018 m_ObjectFlags : 0x188 +0x018 m_ObjectFlagsByName : FxObject::<unnamed-tag>::<unnamed-type-m_objectflagsbyname> +0x01a m_ObjectState : 4 +0x020 m_ChildListHead : _LIST_ENTRY [0x0000000000000000 - 0xfffffadfacd43840] +0x030 m_SpinLock : MxLock +0x038 m_ParentObject : (null) +0x040 m_ChildEntry : _LIST_ENTRY [0xfffffadfacd43860 - 0xfffffadfacd43860] +0x050 m_DisposeSingleEntry : _SINGLE_LIST_ENTRY +0x058 m_DeviceBase : 0xfffffadfac7595d0 FxDeviceBase
+0x058 m_Device : 0xfffffadfac7595d0 FxDevice +0x060 m_NPLock : MxLock +0x068 m_CsqContext : _IO_CSQ_IRP_CONTEXT +0x068 m_ListEntry : _LIST_ENTRY [0xfffffadf00000001 - 0x0]
+0x080 m_DrainSingleEntry : _SINGLE_LIST_ENTRY
+0x080 m_NextStackLocationFormatted : 0 ‘’
+0x088 m_Irp : FxIrp
+0x090 m_Target : (null)
+0x098 m_RequestContext : (null)
+0x0a0 m_Timer : (null)
+0x0a8 m_CancelRoutine : FxRequestCancelCallback
+0x0b0 m_CompletionRoutine : FxRequestCompletionCallback
+0x0b8 m_TargetCompletionContext : (null)
+0x0c0 m_IrpCompletionReferenceCount : 0
+0x0c4 m_TargetFlags : 0 ‘’
+0x0c4 m_TargetFlagsByName : FxRequestBase::::<unnamed-type-m_targetflagsbyname>
+0x0c5 m_IrpAllocation : 0 ‘’
+0x0c6 m_Completed : 0x1 ‘’
+0x0c7 m_Canceled : 0 ‘’
+0x0c8 m_IrpReferenceCount : 0
+0x0d0 m_SystemBufferOffset : 0xd0
+0x0d2 m_VerifierFlags : 5
+0x0d2 m_VeriferFlagsByName : FxRequestBase::::<unnamed-type-m_veriferflagsbyname>
+0x0d8 m_IrpQueue : (null)
+0x0e0 m_OutputBufferOffset : 0xe0
+0x0e2 m_RequestBaseFlags : 0x2 ‘’
+0x0e2 m_RequestBaseFlagsByName : FxRequestBase::::<unnamed-type-m_requestbaseflagsbyname>
+0x0e3 m_RequestBaseStaticFlags : 0x1 ‘’
+0x0e3 m_RequestBaseStaticFlagsByName : FxRequestBase::::<unnamed-type-m_requestbasestaticflagsbyname>
+0x0e4 m_CompletionState : 0 ‘’
+0x0e8 m_AllocatedMdl : (null)
+0x0f0 m_IoQueue : (null)
+0x0f8 m_SystemBuffer : FxRequestSystemBuffer
+0x108 m_OutputBuffer : FxRequestOutputBuffer
+0x118 m_OwnerListEntry : _LIST_ENTRY [0xfffffadfacd43938 - 0xfffffadfacd43938]
+0x128 m_OwnerListEntry2 : _LIST_ENTRY [0xfffffadfabbf7d68 - 0xfffffadfabbf7d68]
+0x138 m_ForwardProgressList : _LIST_ENTRY [0xfffffadfacd43958 - 0xfffffadfacd43958]
+0x148 m_ForwardProgressQueue : (null)
+0x150 m_Presented : 0x1 ‘’
+0x151 m_PowerStopState : 0 ‘’
+0x152 m_Reserved : 0 ‘’
+0x153 m_ForwardRequestToParent : 0 ‘’

—
NTDEV is sponsored by OSR

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</unnamed-type-m_requestbasestaticflagsbyname></unnamed-type-m_requestbaseflagsbyname></unnamed-type-m_veriferflagsbyname></unnamed-type-m_targetflagsbyname></unnamed-type-m_objectflagsbyname>

Jonathan_Ludwig-3 · August 17, 2009, 9:49pm

I didn’t make any objects the children of this request. Are the children being disposed children of the request object? I searched my code and I don’t make any objects children of this type of request.

Is making an object a child of a request bad? Can I do this to tie the lifetime of the object created to the request. I do this for an entirely different request with a timer object that will timeout the request. Is this OK?

Doron_Holan · August 18, 2009, 3:07am

Making an object a child of a WDFREQUEST is not bad generically, but it has caveats and is a bit complicated. In general yes, the object hierarchy makes cleanup very simple. You delete the root and all child objects get deleted as well in a clean fashion.

Here are some rules:
o a kmdf handle type can require that the cleanup() callback is invoked at passive. This means that if you delete the object at dispatch level, the delete will be deferred via a work item to passive

o cleanup() is invoked on all children before it is invoked on the parent

o due to the previous rule any object in a hierarchy of objects can push the cleanup() invocations of all objects in the tree to passive if the root of the tree is deleted at dispatch()

requests are special. When you complete a request (which is an implicit delete after the PIRP is completed) does the following
1 invoke cleanup() on the children (internally this is referred to as early dispose, or just dispose).
2 IoCompleteRequest
3 delete the request object and all of its children objects

Step 1 is the key here. When the driver writer calls WdfRequestComplete he expects that the request is completed by the time the API call returns. This means that if any child object under the request requires passive cleanup() and the request is completed at dispatch we have a conflict of interest between immediate request completion and the 3rd bullet in the initial list of rules. Because of this conflict, requests have a special rule: if completed at dispatch, a request cannot have child objects which do not require passive level cleanup(). If completed at dispatch and the object tree requires passive, an error under verifier is reported. Otherwise, I am pretty sure you can see the error you are getting where the children are disposed at dispatch but the work item is still queued and retries the cleanup() path.

So, what types require passive cleanup()? Well WDFTIMER and WDFDPC are two of them off the top of my head. I am pretty sure the docs call each of these out under their respective pages as well as the restriction around children of requests and passive cleanup().

I would recommend that you do not create a WDFTIMER as a child of the request, make it a sibling (parent it to the WDFDEVICE or a WDFFILEOBJECT if you have file handle based semantics) of the request. Also, test your driver with the WDF driver verifier and see if you are violating any of the rules.

d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@symantec.com
Sent: Monday, August 17, 2009 6:51 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Can someone tell me what this KMDF failure is?

I didn’t make any objects the children of this request. Are the children being disposed children of the request object? I searched my code and I don’t make any objects children of this type of request.

Is making an object a child of a request bad? Can I do this to tie the lifetime of the object created to the request. I do this for an entirely different request with a timer object that will timeout the request. Is this OK?

NTDEV is sponsored by OSR

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

Maxim_S_Shatskih · August 18, 2009, 4:50pm

> 0xffffffffffffffd8 sure looks like the result of a NULL pointer being

adjusted backward by -40 (decimal) bytes.

Probably this is a CONTAINING_RECORD (or the similar C++ trick) inside KMDF to get the private header area of some public structure like WDFDEVICE or such.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Jonathan_Ludwig-3 · August 18, 2009, 5:48pm

Yes, I’ve though that. I just don’t know what structure it was taken from. I would need to know more about KMDF implementation details to know what it should be.