USB WDM drriver crash issue (0X8E)

NTDEV
1

Hi,
I am working on a USB WDM driver. The driver crashes when subjected to heavy writes.

The BSOD crash code is 0X8E(c0000005,…)
WinDBG on alalyzing the crash dump points to a memory access issue.

Consider the following code snippet
if(pIrp!=NULL)
{

pIrp->IoStatus.Status = ntStatus;
pIrp->IoStatus.Information = kWriteMaxDevDataSize;
IoCompleteRequest(pIrp, IO_NO_INCREMENT); // the crash is here
return ntStatus;
}

What could be the cause of the issue. I am already checking for validity of pIrp.
Looking Forward to your inputs.

Regards,
Venkateswaran.C.G

2

You didn’t really give enough information here to diagnose the problem.
Lacking a stack display or even the address at which the error occurred
makes any analysis difficult.

How do you mean “checking the validity of pIrp”? Checking that it is
non-NULL is not really checking the validity; all that says is you have a
pointer to space which might or might not be an IRP at the point where you
are using it, but at one point in the life of your driver *was* an IRP.

Lacking any significant information, it is hard to do a diagnosis.
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@honeywell.com
Sent: Wednesday, December 03, 2008 8:00 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] USB WDM drriver crash issue (0X8E)

Hi,
I am working on a USB WDM driver. The driver crashes when subjected to heavy
writes.

The BSOD crash code is 0X8E(c0000005,…)
WinDBG on alalyzing the crash dump points to a memory access issue.

Consider the following code snippet
if(pIrp!=NULL)
{

pIrp->IoStatus.Status = ntStatus;
pIrp->IoStatus.Information = kWriteMaxDevDataSize;
IoCompleteRequest(pIrp, IO_NO_INCREMENT); // the crash is here
return ntStatus;
}

What could be the cause of the issue. I am already checking for validity of
pIrp.
Looking Forward to your inputs.

Regards,
Venkateswaran.C.G

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

–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

3

Thanks for your reply.

Please consider the bugcheck analysis details given below:
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1000008E, {c0000005, 804f161a, b36a5bd0, 0}

Probably caused by : oepdriver.sys ( oepdriver!OEP_DispatchWrite+5b )

Followup: MachineOwner

2: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but …
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 804f161a, The address that the exception occurred at
Arg3: b36a5bd0, Trap Frame
Arg4: 00000000

Debugging Details:

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx” referenced memory at “0x%08lx”. The memory could not be “%s”.

FAULTING_IP:
nt!IopfCompleteRequest+c
804f161a 8a4e23 mov cl,byte ptr [esi+23h]

TRAP_FRAME: b36a5bd0 – (.trap 0xffffffffb36a5bd0)
Unable to read trap frame at b36a5bd0

CUSTOMER_CRASH_COUNT: 5

DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT

BUGCHECK_STR: 0x8E

LAST_CONTROL_TRANSFER: from b38afcbd to 804f161a

STACK_TEXT:
b36a5c5c b38afcbd 84e56480 85794d88 00000001 nt!IopfCompleteRequest+0xc
b36a5c70 804ef18f 84d8fea0 85d04e48 806e6410 oepdriver!OEP_DispatchWrite+0x5b [u:\gus_emulators\emulators\oepdriver\io.c @ 251]
b36a5c80 8057f982 85d04f24 00000000 85d04e48 nt!IopfCallDriver+0x31
b36a5c94 8057d4c9 84d8fea0 85d04e48 84e56480 nt!IopSynchronousServiceTail+0x70
b36a5d38 8054161c 000007a8 000007b4 00000000 nt!NtWriteFile+0x5d7
b36a5d38 7c90e4f4 000007a8 000007b4 00000000 nt!KiFastCallEntry+0xfc
WARNING: Frame IP not in any known module. Following frames may be wrong.
0012fe18 00000000 00000000 00000000 00000000 0x7c90e4f4

STACK_COMMAND: kb

FOLLOWUP_IP:
oepdriver!OEP_DispatchWrite+5b [u:\gus_emulators\emulators\oepdriver\io.c @ 251]
b38afcbd ?? ???

FAULTING_SOURCE_CODE:
247:
248: pIrp->IoStatus.Status = ntStatus;
249: pIrp->IoStatus.Information = kWriteMaxDevDataSize;
250: IoCompleteRequest(pIrp, IO_NO_INCREMENT);

251: return ntStatus;
252: }
253: else
254: {
255: DbgPrint(“Hit dispach write problem condition”);
256: return ntStatus;

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: oepdriver!OEP_DispatchWrite+5b

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: oepdriver

IMAGE_NAME: oepdriver.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 0

FAILURE_BUCKET_ID: 0x8E_oepdriver!OEP_DispatchWrite+5b

BUCKET_ID: 0x8E_oepdriver!OEP_DispatchWrite+5b
Followup: MachineOwner

4

The irp you are passing in is bogus. How about posting all of the code for OEP_DispatchWrite? My guess is that you added the irp into some list that was serviced in another context by a dpc/timer/isr/work item and it completed the irp from underneath you before you completed it in the dispatch routine. Since this happens only under heavy io load I would further guess that you are not synchronizing some state variable properly. The lack of synchronization under a light load would not show the race conditions that would lead to a “split” state, but under heavy load there is enough context switching that the lack of synchronization rears its ugly head and you get to where you are at now

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@honeywell.com
Sent: Wednesday, December 03, 2008 9:27 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] USB WDM drriver crash issue (0X8E)

Thanks for your reply.

Please consider the bugcheck analysis details given below:
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1000008E, {c0000005, 804f161a, b36a5bd0, 0}

Probably caused by : oepdriver.sys ( oepdriver!OEP_DispatchWrite+5b )

Followup: MachineOwner

2: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but …
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 804f161a, The address that the exception occurred at
Arg3: b36a5bd0, Trap Frame
Arg4: 00000000

Debugging Details:

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx” referenced memory at “0x%08lx”. The memory could not be “%s”.

FAULTING_IP:
nt!IopfCompleteRequest+c
804f161a 8a4e23 mov cl,byte ptr [esi+23h]

TRAP_FRAME: b36a5bd0 – (.trap 0xffffffffb36a5bd0)
Unable to read trap frame at b36a5bd0

CUSTOMER_CRASH_COUNT: 5

DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT

BUGCHECK_STR: 0x8E

LAST_CONTROL_TRANSFER: from b38afcbd to 804f161a

STACK_TEXT:
b36a5c5c b38afcbd 84e56480 85794d88 00000001 nt!IopfCompleteRequest+0xc
b36a5c70 804ef18f 84d8fea0 85d04e48 806e6410 oepdriver!OEP_DispatchWrite+0x5b [u:\gus_emulators\emulators\oepdriver\io.c @ 251]
b36a5c80 8057f982 85d04f24 00000000 85d04e48 nt!IopfCallDriver+0x31
b36a5c94 8057d4c9 84d8fea0 85d04e48 84e56480 nt!IopSynchronousServiceTail+0x70
b36a5d38 8054161c 000007a8 000007b4 00000000 nt!NtWriteFile+0x5d7
b36a5d38 7c90e4f4 000007a8 000007b4 00000000 nt!KiFastCallEntry+0xfc
WARNING: Frame IP not in any known module. Following frames may be wrong.
0012fe18 00000000 00000000 00000000 00000000 0x7c90e4f4

STACK_COMMAND: kb

FOLLOWUP_IP:
oepdriver!OEP_DispatchWrite+5b [u:\gus_emulators\emulators\oepdriver\io.c @ 251]
b38afcbd ?? ???

FAULTING_SOURCE_CODE:
247:
248: pIrp->IoStatus.Status = ntStatus;
249: pIrp->IoStatus.Information = kWriteMaxDevDataSize;
250: IoCompleteRequest(pIrp, IO_NO_INCREMENT);

251: return ntStatus;
252: }
253: else
254: {
255: DbgPrint(“Hit dispach write problem condition”);
256: return ntStatus;

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: oepdriver!OEP_DispatchWrite+5b

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: oepdriver

IMAGE_NAME: oepdriver.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 0

FAILURE_BUCKET_ID: 0x8E_oepdriver!OEP_DispatchWrite+5b

BUCKET_ID: 0x8E_oepdriver!OEP_DispatchWrite+5b
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