Win7x64 - Devpathexer - BSOD - 0x10D_6_3

NTDEV
1

Hi All,

When I am running Devpathexer on Win7x64, I am getting bugcheck 10D.

I was able to capture the dump info:

It says same Request is being sent to the target,
This behaviour is specific to one device only, and on different device and same driver, devpathexer is working fine.

How can I ensure, the same request is not sent again?

BugCheck 10D, {6, 3, 57ffc3b9ba8, fffffa8003594db0}
.
.
!analyze -v

WDF_VIOLATION (10d)
The Kernel-Mode Driver Framework was notified that Windows detected an error
in a framework-based driver. In general, the dump file will yield additional
information about the driver that caused this bug check.
Arguments:
Arg1: 0000000000000006, A fatal error was made in handling a WDF request. In this case,
Parameter 2 further specifies the type of fatal error that has
been made, as defined by the enumeration WDF_REQUEST_FATAL_ERROR.
Arg2: 0000000000000003, The driver attempted to send a framework request that has
already been sent to an I/O target.
Arg3: 0000057ffc3b9ba8, The WDF request handle value.
Arg4: fffffa8003594db0, Reserved.

BUGCHECK_STR: 0x10D_6

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff800029bc6d2 to fffff800028bef60

STACK_TEXT:
fffff88002f1adf8 fffff800029bc6d2 : 0000000000000000 0000000000000000 0000000000000000 fffffa8003ca2000 : nt!DbgBreakPointWithStatus
fffff88002f1ae00 fffff800029bda98 : fffff80000000004 fffff80002ac5b40 000000000000000f fffff880009f1f40 : nt!HeadlessDispatch+0x192
fffff88002f1ae60 fffff800028c7004 : fffffa8003580016 fffff88002f1b598 0000000000000008 0000000000000000 : nt!KeEnterKernelDebugger+0xd48
fffff88002f1b530 fffff88000d5e589 : 000000000000010d 0000000000000006 0000000000000003 0000057ffc3b9ba8 : nt!KeBugCheckEx+0x104
fffff88002f1b570 fffff88000d5ee2b : 0000000000000000 fffff88000d7b100 0000000000000000 fffffa8003581020 : Wdf01000!FxIoTarget::SubmitLocked+0xd5
fffff88002f1b630 fffff88000d74767 : 0000000000000000 0000000000000000 0000057ffca7efd8 fffffa8003c465e0 : Wdf01000!FxIoTarget::Submit+0x63
fffff88002f1b670 fffff880045b9b80 : fffffa8003594f00 fffffa8003c46450 fffffa8003581020 fffffa8003c42370 : Wdf01000!imp_WdfRequestSend+0x413
fffff88002f1b6c0 fffff880045b9ed0 : 0000057ffcf45288 fffffa8003c42370 0000000000000040 fffffa8003581020 : MYUSBPP!StartWriteUrb+0x1a8 [c:\devpatheexrissue1apr11\win7-MY-yx-par\write.c @ 693]
fffff88002f1b760 fffff880045b9995 : fffffa8003c42370 0000000000000000 fffffa800424a2a8 fffff8800499ac8f : MYUSBPP!TransmitData+0x2dc [c:\devpatheexrissue1apr11\win7-MY-yx-par\write.c @ 925]
fffff88002f1b790 fffff88000d8922b : fffffa8003c46450 fffffa80018d22a0 fffffa80018d22a0 fffff880049d777e : MYUSBPP!OnWriteInterrupt+0x45 [c:\devpatheexrissue1apr11\win7-MY-yx-par\write.c @ 564]
fffff88002f1b7c0 fffff88000d5fc9b : fffffa8003581020 fffffa8003581020 fffffa8003581030 fffffa800359de01 : Wdf01000!FxRequestBase::CompleteSubmitted+0x177
fffff88002f1b840 fffff88000d5fdc4 : fffff980020fac02 fffff9800d3fad80 0000000000000000 fffff80002d6e40a : Wdf01000!FxIoTarget::RequestCompletionRoutine+0x1cb
fffff88002f1b8b0 fffff800028b1935 : fffff800028b18e0 fffff98002efafb8 fffff98002efae10 fffff88002f1baa0 : Wdf01000!FxIoTarget::_RequestCompletionRoutine+0x3c
fffff88002f1b8e0 fffff80002d6e5d6 : fffff98002efafb8 fffffa80030bd230 fffff88002f1baa0 fffff98002efae10 : nt!IoSetCompletionRoutineEx+0x115
fffff88002f1b910 fffff800028c9516 : fffff98002efafbb fffff80000000001 0000000000000000 fffff88000000005 : nt!NtShutdownSystem+0x261a6
fffff88002f1b970 fffff80002d6619f : fffff98002efae10 fffffa80035bf100 fffffa800366a000 0000000000000000 : nt!memset+0x496
fffff88002f1ba50 fffff88003e135d9 : fffffa800366a050 fffffa80042b7902 0000000000000002 fffffa800366a050 : nt!NtShutdownSystem+0x1dd6f
fffff88002f1bb20 fffff88003e13ab7 : fffffa8003192702 fffff98002efae10 00000000ffffffff fffffa800366aea8 : USBPORT+0x135d9
fffff88002f1bc00 fffff88003e1164f : fffffa800366aea8 fffffa800366a1a0 fffffa800366b040 0000000000000000 : USBPORT+0x13ab7
fffff88002f1bc60 fffff88003e02f89 : fffffa800366a050 0000000000000000 fffffa800366ae02 fffffa800366aea8 : USBPORT+0x1164f
fffff88002f1bca0 fffff800028d25dc : fffff880009e7180 fffffa800366aea8 fffffa800366aec0 0000000000000000 : USBPORT+0x2f89
fffff88002f1bcd0 fffff800028cf6fa : fffff880009e7180 fffff880009f1f40 0000000000000000 fffff88003e02db0 : nt!KeRemoveQueueEx+0xe1c
fffff88002f1bd80 0000000000000000 : fffff88002f1c000 fffff88002f16000 fffff88002f1bd40 0000000000000000 : nt!KeUpdateSystemTime+0x47a

STACK_COMMAND: kb

FOLLOWUP_IP:
MYUSBPP!StartWriteUrb+1a8 [c:\devpatheexrissue1apr11\win7-MY-yx-par\write.c @ 693]
fffff880`045b9b80 0fb6d8 movzx ebx,al

FAULTING_SOURCE_CODE:
691:
692: reqContext->Length = Extension->WriteSize;

693: if (!(status = WdfRequestSend(Request, WdfUsbTargetPipeGetIoTarget(pipe), WDF_NO_SEND_OPTIONS))) {
694: status = WdfRequestGetStatus(Request);
695: ASSERT(!NT_SUCCESS(status));
696: }
697:
698:

SYMBOL_STACK_INDEX: 7
SYMBOL_NAME: MYUSBPP!StartWriteUrb+1a8
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: MYUSBPP
IMAGE_NAME: MYUSBPP.sys
BUCKET_ID: WRONG_SYMBOLS
Followup: MachineOwner

2

xxxxx@gmail.com wrote:

When I am running Devpathexer on Win7x64, I am getting bugcheck 10D.

I was able to capture the dump info:

It says same Request is being sent to the target,
This behaviour is specific to one device only, and on different device and same driver, devpathexer is working fine.

How can I ensure, the same request is not sent again?

This is being called from the completion handler for a previous
request. Are you trying to reuse the same request without calling
WdfRequestReuse?

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

3

> This is being called from the completion handler for a previous request.
Yes from the Completion routine.

Are you trying to reuse the same request without calling WdfRequestReuse?
I haven’t used WdfRequestReuse, I will use this in completion routine and check

Thanks

4

Again its occurring.

This time on the device which was working previously perfect.

I have added the WdfRequestReuse in write completion routine "OnWriteInterrupt" as:

WDF_REQUEST_REUSE_PARAMS_INIT(
&params,
WDF_REQUEST_REUSE_NO_FLAGS,
STATUS_SUCCESS
);
status = WdfRequestReuse(
Request,
&params
);
ASSERT(NT_SUCCESS(status));

However, still 10D_6_3 bug check is coming below is the dump.

From the dump logs, this time, the completion routine is not called (OnWriteInterrupt), hence there is no WdfRequestReuse.
The request has originated from EvtIOWrite: MEANS I NEED TO MAKE THE REQUEST as RESUSE here itself, i.e. before completion routine?

*** Fatal System Error: 0x0000010d
(0x0000000000000006,0x0000000000000003,0x0000057FFC4279D8,0xFFFFFA8003BC3840)
Break instruction exception - code 80000003 (first chance)

Connected to Windows 7 7600 x64 target at (Thu Apr 7 10:09:23.437 2011 (UTC + 5:30)), ptr64 TRUE

BugCheck 10D, {6, 3, 57ffc4279d8, fffffa8003bc3840}

Probably caused by : MyUSBPP.sys ( MyUSBPP!StartWriteUrb+1a8 )

Followup: MachineOwner

nt!DbgBreakPointWithStatus:
fffff800`028c4f60 cc int 3

WDF_VIOLATION (10d)
The Kernel-Mode Driver Framework was notified that Windows detected an error
in a framework-based driver. In general, the dump file will yield additional
information about the driver that caused this bug check.
Arguments:
Arg1: 0000000000000006, A fatal error was made in handling a WDF request. In this case,
Parameter 2 further specifies the type of fatal error that has
been made, as defined by the enumeration WDF_REQUEST_FATAL_ERROR.
Arg2: 0000000000000003, The driver attempted to send a framework request that has
already been sent to an I/O target.
Arg3: 0000057ffc4279d8, The WDF request handle value.
Arg4: fffffa8003bc3840, Reserved.

Debugging Details:

BUGCHECK_STR: 0x10D_6
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
PROCESS_NAME: devpathexer.ex
CURRENT_IRQL: 2

LAST_CONTROL_TRANSFER: from fffff800029c26d2 to fffff800028c4f60

STACK_TEXT:
fffff88001e84cb8 fffff800029c26d2 : 0000000000000006 fffffa8004704b60 0000000000000065 fffff8000290b314 : nt!DbgBreakPointWithStatus
fffff88001e84cc0 fffff800029c34be : 0000057f00000003 0000000000000000 fffff80002907ee0 000000000000010d : nt!KiBugCheckDebugBreak+0x12
fffff88001e84d20 fffff800028cd004 : fffff88000f20016 fffff88001e85458 0000000000000008 0000000000000000 : nt!KeBugCheck2+0x71e
fffff88001e853f0 fffff88000efe589 : 000000000000010d 0000000000000006 0000000000000003 0000057ffc4279d8 : nt!KeBugCheckEx+0x104
fffff88001e85430 fffff88000efee2b : 0000000000000000 fffff88000f1b100 0000000000000000 fffffa8003bd0650 : Wdf01000!FxIoTarget::SubmitLocked+0xd5
fffff88001e854f0 fffff88000f14767 : 0000000000000000 0000000000000000 0000057ffc42f9a8 fffffa8003bd87b0 : Wdf01000!FxIoTarget::Submit+0x63
fffff88001e85530 fffff88004262bc0 : fffffa8003bc3990 fffffa8003bd8620 fffffa8003bd0650 fffffa8003bcb370 : Wdf01000!imp_WdfRequestSend+0x413
fffff88001e85580 fffff88004262f10 : 0000057ffbe4edd8 fffffa8003bcb370 0000000000000040 fffffa80047f8f30 : MyUSBPP!StartWriteUrb+0x1a8 [c:\devpatheexrissue1apr11\win7-My-Yx-par\write.c @ 707]
fffff88001e85620 fffff880042632fe : fffffa80047f8da0 fffffa8003bcc468 fffffa8003bcb370 0000000000000000 : MyUSBPP!TransmitData+0x2dc [c:\devpatheexrissue1apr11\win7-My-Yx-par\write.c @ 940]
fffff88001e85650 fffff8800425feff : fffffa80047f8da0 fffffa80047f8f30 fffffa8003bcc468 0000057ffb807258 : MyUSBPP!UsbStartWrite+0x22e [c:\devpatheexrissue1apr11\win7-My-Yx-par\write.c @ 1288]
fffff88001e856f0 fffff88004263091 : fffffa8003bcb370 0000000000000376 fffffa80047f8f30 0000000000000376 : MyUSBPP!UsbStartOrQueue+0xc3 [c:\devpatheexrissue1apr11\win7-My-Yx-par\ioctl.c @ 862]
fffff88001e85760 fffff88000f39ed9 : fffffa80047f8da0 0000057ffc431b48 fffffa8003bc3840 0000000000000376 : MyUSBPP!UsbEvtIoWrite+0x14d [c:\devpatheexrissue1apr11\win7-My-Yx-par\write.c @ 1111]
fffff88001e857d0 fffff88000f3999f : fffffa80047f8d00 fffffa80047f8da0 fffffa8003bce4b0 fffffa8003bce4b0 : Wdf01000!FxIoQueue::DispatchRequestToDriver+0x401
fffff88001e85850 fffff88000f38f98 : 0000000000000000 0000000000000000 0000000000000000 fffffa80047f8ef2 : Wdf01000!FxIoQueue::DispatchEvents+0x4df
fffff88001e858c0 fffff88000f3e558 : fffff9800ac0cf00 fffffa80047f8da0 fffff9800ac0cd30 fffffa80047f8da0 : Wdf01000!FxIoQueue::QueueRequest+0x2bc
fffff88001e85930 fffff88000f28245 : fffffa80047f8da0 fffff9800ac0cd30 0000000000000002 fffffa8003bc6c70 : Wdf01000!FxPkgIo::Dispatch+0x37c
fffff88001e859b0 fffff80002d72c16 : fffff9800ac0cd30 0000000000000002 0000000000000376 0000000000000028 : Wdf01000!FxDevice::Dispatch+0xa9
fffff88001e859e0 fffff80002be0929 : 0000000000000001 fffffa8003585860 0000000000000000 fffffa8004645980 : nt!IovCallDriver+0x566
fffff88001e85a40 fffff80002be16c3 : fffff9800ac0cff8 fffffa80035858b0 fffffa8003585860 0000000000000000 : nt!IopSynchronousServiceTail+0xf9
fffff88001e85ab0 fffff800028cc153 : fffffa8004704f01 0000000000000000 0000000000000000 0000000000000000 : nt!NtWriteFile+0x7e2
fffff88001e85bb0 00000000772cff3a : 00000000ffd789a3 0000000000000377 000000000033da00 00000000ffd689e0 : nt!KiSystemServiceCopyEnd+0x13
00000000021ff328 00000000ffd789a3 : 0000000000000377 000000000033da00 00000000ffd689e0 000000000033da00 : ntdll!NtWriteFile+0xa
00000000021ff330 000000007707f56d : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : devpathexer+0x189a3
00000000021ffc50 00000000772b3281 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : kernel32!BaseThreadInitThunk+0xd
00000000021ffc80 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : ntdll!RtlUserThreadStart+0x1d

STACK_COMMAND: kb

FOLLOWUP_IP:
MyUSBPP!StartWriteUrb+1a8 [c:\devpatheexrissue1apr11\win7-My-Yx-par\write.c @ 707]
fffff880`04262bc0 0fb6d8 movzx ebx,al

FAULTING_SOURCE_CODE:
705:
706: reqContext->Length = Extension->WriteSize;

707: if (!(status = WdfRequestSend(Request, WdfUsbTargetPipeGetIoTarget(pipe), WDF_NO_SEND_OPTIONS))) {
708: status = WdfRequestGetStatus(Request);
709: ASSERT(!NT_SUCCESS(status));
710: }
711:
712: //WdfWaitLockRelease(Extension->DeviceLock); //06apr11

SYMBOL_STACK_INDEX: 7
SYMBOL_NAME: MyUSBPP!StartWriteUrb+1a8
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: MyUSBPP
IMAGE_NAME: MyUSBPP.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4d9cbbe8
FAILURE_BUCKET_ID: X64_0x10D_6_VRF_MyUSBPP!StartWriteUrb+1a8
BUCKET_ID: X64_0x10D_6_VRF_MyUSBPP!StartWriteUrb+1a8
Followup: MachineOwner

5

What does !wdfkd.wdflogdump say? In the completion routine, are you resending the request that the completion routine is being called for or a separate request?

d

debt from my phone

-----Original Message-----
From: xxxxx@gmail.com
Sent: Wednesday, April 06, 2011 9:56 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Win7x64 - Devpathexer - BSOD - 0x10D_6_3

Again its occurring.

This time on the device which was working previously perfect.

I have added the WdfRequestReuse in write completion routine “OnWriteInterrupt” as:

WDF_REQUEST_REUSE_PARAMS_INIT(
&params,
WDF_REQUEST_REUSE_NO_FLAGS,
STATUS_SUCCESS
);
status = WdfRequestReuse(
Request,
&params
);
ASSERT(NT_SUCCESS(status));

However, still 10D_6_3 bug check is coming below is the dump.

From the dump logs, this time, the completion routine is not called (OnWriteInterrupt), hence there is no WdfRequestReuse.
The request has originated from EvtIOWrite: MEANS I NEED TO MAKE THE REQUEST as RESUSE here itself, i.e. before completion routine?

*** Fatal System Error: 0x0000010d
(0x0000000000000006,0x0000000000000003,0x0000057FFC4279D8,0xFFFFFA8003BC3840)
Break instruction exception - code 80000003 (first chance)

Connected to Windows 7 7600 x64 target at (Thu Apr 7 10:09:23.437 2011 (UTC + 5:30)), ptr64 TRUE

BugCheck 10D, {6, 3, 57ffc4279d8, fffffa8003bc3840}

Probably caused by : MyUSBPP.sys ( MyUSBPP!StartWriteUrb+1a8 )

Followup: MachineOwner
---------
nt!DbgBreakPointWithStatus:
fffff800028c4f60 cc int 3<br><br>WDF_VIOLATION (10d)<br>The Kernel-Mode Driver Framework was notified that Windows detected an error<br>in a framework-based driver. In general, the dump file will yield additional<br>information about the driver that caused this bug check.<br>Arguments:<br>Arg1: 0000000000000006, A fatal error was made in handling a WDF request. In this case,<br> Parameter 2 further specifies the type of fatal error that has<br> been made, as defined by the enumeration WDF_REQUEST_FATAL_ERROR.<br>Arg2: 0000000000000003, The driver attempted to send a framework request that has<br> already been sent to an I/O target.<br>Arg3: 0000057ffc4279d8, The WDF request handle value.<br>Arg4: fffffa8003bc3840, Reserved.<br><br>Debugging Details:<br>------------------<br>BUGCHECK_STR: 0x10D_6<br>DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT<br>PROCESS_NAME: devpathexer.ex<br>CURRENT_IRQL: 2<br><br>LAST_CONTROL_TRANSFER: from fffff800029c26d2 to fffff800028c4f60<br><br>STACK_TEXT:<br>fffff88001e84cb8 fffff800029c26d2 : 0000000000000006 fffffa8004704b60 0000000000000065 fffff8000290b314 : nt!DbgBreakPointWithStatus<br>fffff88001e84cc0 fffff800029c34be : 0000057f00000003 0000000000000000 fffff80002907ee0 000000000000010d : nt!KiBugCheckDebugBreak+0x12<br>fffff88001e84d20 fffff800028cd004 : fffff88000f20016 fffff88001e85458 0000000000000008 0000000000000000 : nt!KeBugCheck2+0x71e<br>fffff88001e853f0 fffff88000efe589 : 000000000000010d 0000000000000006 0000000000000003 0000057ffc4279d8 : nt!KeBugCheckEx+0x104<br>fffff88001e85430 fffff88000efee2b : 0000000000000000 fffff88000f1b100 0000000000000000 fffffa8003bd0650 : Wdf01000!FxIoTarget::SubmitLocked+0xd5<br>fffff88001e854f0 fffff88000f14767 : 0000000000000000 0000000000000000 0000057ffc42f9a8 fffffa8003bd87b0 : Wdf01000!FxIoTarget::Submit+0x63<br>fffff88001e85530 fffff88004262bc0 : fffffa8003bc3990 fffffa8003bd8620 fffffa8003bd0650 fffffa8003bcb370 : Wdf01000!imp_WdfRequestSend+0x413<br>fffff88001e85580 fffff88004262f10 : 0000057ffbe4edd8 fffffa8003bcb370 0000000000000040 fffffa80047f8f30 : MyUSBPP!StartWriteUrb+0x1a8 [c:\devpatheexrissue1apr11\win7-My-Yx-par\write.c @ 707]<br>fffff88001e85620 fffff880042632fe : fffffa80047f8da0 fffffa8003bcc468 fffffa8003bcb370 0000000000000000 : MyUSBPP!TransmitData+0x2dc [c:\devpatheexrissue1apr11\win7-My-Yx-par\write.c @ 940]<br>fffff88001e85650 fffff8800425feff : fffffa80047f8da0 fffffa80047f8f30 fffffa8003bcc468 0000057ffb807258 : MyUSBPP!UsbStartWrite+0x22e [c:\devpatheexrissue1apr11\win7-My-Yx-par\write.c @ 1288]<br>fffff88001e856f0 fffff88004263091 : fffffa8003bcb370 0000000000000376 fffffa80047f8f30 0000000000000376 : MyUSBPP!UsbStartOrQueue+0xc3 [c:\devpatheexrissue1apr11\win7-My-Yx-par\ioctl.c @ 862]<br>fffff88001e85760 fffff88000f39ed9 : fffffa80047f8da0 0000057ffc431b48 fffffa8003bc3840 0000000000000376 : MyUSBPP!UsbEvtIoWrite+0x14d [c:\devpatheexrissue1apr11\win7-My-Yx-par\write.c @ 1111]<br>fffff88001e857d0 fffff88000f3999f : fffffa80047f8d00 fffffa80047f8da0 fffffa8003bce4b0 fffffa8003bce4b0 : Wdf01000!FxIoQueue::DispatchRequestToDriver+0x401<br>fffff88001e85850 fffff88000f38f98 : 0000000000000000 0000000000000000 0000000000000000 fffffa80047f8ef2 : Wdf01000!FxIoQueue::DispatchEvents+0x4df<br>fffff88001e858c0 fffff88000f3e558 : fffff9800ac0cf00 fffffa80047f8da0 fffff9800ac0cd30 fffffa80047f8da0 : Wdf01000!FxIoQueue::QueueRequest+0x2bc<br>fffff88001e85930 fffff88000f28245 : fffffa80047f8da0 fffff9800ac0cd30 0000000000000002 fffffa8003bc6c70 : Wdf01000!FxPkgIo::Dispatch+0x37c<br>fffff88001e859b0 fffff80002d72c16 : fffff9800ac0cd30 0000000000000002 0000000000000376 0000000000000028 : Wdf01000!FxDevice::Dispatch+0xa9<br>fffff88001e859e0 fffff80002be0929 : 0000000000000001 fffffa8003585860 0000000000000000 fffffa8004645980 : nt!IovCallDriver+0x566<br>fffff88001e85a40 fffff80002be16c3 : fffff9800ac0cff8 fffffa80035858b0 fffffa8003585860 0000000000000000 : nt!IopSynchronousServiceTail+0xf9<br>fffff88001e85ab0 fffff800028cc153 : fffffa8004704f01 0000000000000000 0000000000000000 0000000000000000 : nt!NtWriteFile+0x7e2<br>fffff88001e85bb0 00000000772cff3a : 00000000ffd789a3 0000000000000377 000000000033da00 00000000ffd689e0 : nt!KiSystemServiceCopyEnd+0x13<br>00000000021ff328 00000000ffd789a3 : 0000000000000377 000000000033da00 00000000ffd689e0 000000000033da00 : ntdll!NtWriteFile+0xa<br>00000000021ff330 000000007707f56d : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : devpathexer+0x189a3<br>00000000021ffc50 00000000772b3281 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : kernel32!BaseThreadInitThunk+0xd<br>00000000021ffc80 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : ntdll!RtlUserThreadStart+0x1d<br><br>STACK_COMMAND: kb<br><br>FOLLOWUP_IP:<br>MyUSBPP!StartWriteUrb+1a8 [c:\devpatheexrissue1apr11\win7-My-Yx-par\write.c @ 707]<br>fffff88004262bc0 0fb6d8 movzx ebx,al

FAULTING_SOURCE_CODE:
705:
706: reqContext->Length = Extension->WriteSize;
> 707: if (!(status = WdfRequestSend(Request, WdfUsbTargetPipeGetIoTarget(pipe), WDF_NO_SEND_OPTIONS))) {
708: status = WdfRequestGetStatus(Request);
709: ASSERT(!NT_SUCCESS(status));
710: }
711:
712: //WdfWaitLockRelease(Extension->DeviceLock); //06apr11

SYMBOL_STACK_INDEX: 7
SYMBOL_NAME: MyUSBPP!StartWriteUrb+1a8
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: MyUSBPP
IMAGE_NAME: MyUSBPP.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4d9cbbe8
FAILURE_BUCKET_ID: X64_0x10D_6_VRF_MyUSBPP!StartWriteUrb+1a8
BUCKET_ID: X64_0x10D_6_VRF_MyUSBPP!StartWriteUrb+1a8
Followup: MachineOwner
---------

—
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

6

xxxxx@gmail.com wrote:

Again its occurring.

This time on the device which was working previously perfect.

I have added the WdfRequestReuse in write completion routine “OnWriteInterrupt” as:
…
However, still 10D_6_3 bug check is coming below is the dump.

>From the dump logs, this time, the completion routine is not called (OnWriteInterrupt), hence there is no WdfRequestReuse.
The request has originated from EvtIOWrite: MEANS I NEED TO MAKE THE REQUEST as RESUSE here itself, i.e. before completion routine?

No, don’t start adding random code to your driver. You need to do some
debugging to figure out how this is happening. The WDF in-flight
recorder logs will show you a trace of the progress of all requests in
your driver. That would be a good first step. After that, you can add
your own debugging output every time you submit a request to the next
driver down.

You haven’t shown us any of your code. Is it possible you are using
WdfIoQueueFindRequest improperly, so that you are submitting a request
that still belongs to a queue.

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