Invalid URB ? Bugcheck 0x7e

Hi all,

I am currently writing a usb bus driver and I am encountering the following bugcheck when i connect with a USB device.

YSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
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.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 804dab98, The address that the exception occurred at
Arg3: f78d69e4, Exception Record Address
Arg4: f78d66e0, Context Record Address

STACK_TEXT:
f78d6ab4 b958d029 8a76cffe 0012f4b7 00000001 nt!memcpy+0x160
f78d6af4 b958c0ec 89e8eff0 8a4eefc0 893f0a88 myusbb!HandleControlTransferCommon+0x229
f78d6ba8 b958ab71 89e8eff0 8a4eefc0 893f0a88 myusbb!HandleControlVendorOrClassRequest+0x4ec
f78d6be8 b958aa0b 89e8eff0 77017618 893f0a88 myusbb!HandleSingleUrb+0x111
f78d6c48 b9589561 89e8eff0 77017618 76c11578 myusbb!HandleSubmitUrb+0x14b
f78d6c68 b957bc31 89fd6ff0 89e8eff0 77017618 myusbb!HandleUsbIoctl+0x81
f78d6c98 b953b514 77054c40 76c11578 893f0a88 myusbb!Bus_EvtIoInternalDeviceControl+0x51
f78d6cbc b953c924 77054c40 76c11578 893f0a88 wdf01000!FxIoQueueIoDeviceControl::Invoke+0x30
f78d6cec b953efb8 76c11578 b9565f38 88fab3b8 wdf01000!FxIoQueue::DispatchRequestToDriver+0x445
f78d6d0c b953b93c 88fab300 895da298 88fab300 wdf01000!FxIoQueue::DispatchEvents+0x4e9
f78d6d20 b953ba1c b953b9c4 891ffb48 00000000 wdf01000!FxIoQueue::DeferredDispatchRequestsFromWorkerThread+0x23
f78d6d34 b95624a9 88fab3b8 893ac158 891ffb48 wdf01000!FxIoQueue::_DeferredDispatchThreadThunk+0x58
f78d6d54 b9562507 88fa9d88 f78d6d74 80565610 wdf01000!FxSystemWorkItem::WorkItemHandler+0x53
f78d6d60 80565610 88fa9d88 891ffb48 805632fc wdf01000!FxSystemWorkItem::WorkItemThunk+0x10
f78d6d74 804e526b 893ac158 00000000 898a53c8 nt!IopProcessWorkItem+0x13
f78d6dac 8057beff 893ac158 00000000 00000000 nt!ExpWorkerThread+0x100
f78d6ddc 804f98ea 804e5196 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

From the stack its pretty clear that while copying i encountered an incorrect source address.

kd> dd 0012f4b7
0012f4b7 ??? ??? ??? ???
0012f4c7 ??? ??? ??? ???
0012f4d7 ??? ??? ??? ???
0012f4e7 ??? ??? ??? ???
0012f4f7 ??? ??? ??? ???
0012f507 ??? ??? ??? ???
0012f517 ??? ??? ??? ???
0012f527 ??? ??? ??? ???

kd> !wdfrequest 0x76c11578
!IRP 0x89eeef20

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

kd> !WDFQUEUE 0x77054c40

Dumping WDFQUEUE 0x77054c40

Parallel, Default, Not power-managed, PowerOn, Passive Only, Can accept, Can dispatch, Dispatching, ExecutionLevelPassive, SynchronizationScopeNone
Number of driver owned requests: 2
!WDFREQUEST 0x76c36b00 !IRP 0x8a6b6f20
!WDFREQUEST 0x76c11578 !IRP 0x89eeef20
Number of waiting requests: 0

Number of driver owned cancelable requests: 1
!WDFREQUEST 0x76c36b00 !IRP 0x8a6b6f20

EvtIoDeviceControl: (0xb957bc40) myusbb!Bus_EvtIoDeviceControl
EvtIoInternalDeviceControl: (0xb957bbe0) myusbb!Bus_EvtIoInternalDeviceControl

kd> !IRP 0x89eeef20
Irp is active with 3 stacks 2 is current (= 0x89eeefb4)
No Mdl: No System Buffer: Thread 00000000: Irp stack trace.
cmd flg cl Device File Completion-Context
[0, 0] 0 10 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[f, 0] 0 e1 88fa9d88 00000000 b765232c-b7653002 Success Error Cancel pending
\Driver\myusbb*** ERROR: Module load completed but symbols could not be loaded for gp800up.sys
gp800up
Args: 893f0a88 00000000 00220003 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 893f0a88 b764fba2 88fb0ca8 89d50f20

kd> dt _URB_CONTROL_VENDOR_OR_CLASS_REQUEST 893f0a88
wdf01000!_URB_CONTROL_VENDOR_OR_CLASS_REQUEST
+0x000 Hdr : _URB_HEADER
+0x010 Reserved : 0x000ce414
+0x014 TransferFlags : 0
+0x018 TransferBufferLength : 1
+0x01c TransferBuffer : 0x0012f4b7
+0x020 TransferBufferMDL : (null)
+0x024 UrbLink : (null)
+0x028 hca : _URB_HCD_AREA
+0x048 RequestTypeReservedBits : 0x4 ‘’
+0x049 Request : 0x6 ‘’
+0x04a Value : 0
+0x04c Index : 0
+0x04e Reserved1 : 0

Till now it seems like i tried to copy 1 byte from 0x0012f4b7 but since its not accessible it threw a bugcheck. The driver is using buffered IO.
At this point i am not sure how to proceed further. Every time the system throws the same bugcheck and i see the same address. Can anyone provide some pointers as to what might be going wrong ?

This is access violation in memcpy() which is called from myusbb!HandleControlTransferCommon(). Inspect your own code, local variables, etc.

xxxxx@yahoo.com wrote:

I am currently writing a usb bus driver and I am encountering the following bugcheck when i connect with a USB device.

From the stack its pretty clear that while copying i encountered an incorrect source address.

kd> dd 0012f4b7
Till now it seems like i tried to copy 1 byte from 0x0012f4b7 but since its not accessible it threw a bugcheck. The driver is using buffered IO.

Yes, but I’ll wager real dollars that your buffer includes a pointer.
0x12f4b7 is a user-mode address, and by the time you get to this crash,
you are no longer in the original user-mode process, so that address is
not valid.

At this point i am not sure how to proceed further. Every time the system throws the same bugcheck and i see the same address. Can anyone provide some pointers as to what might be going wrong ?

Never pass pointers from user-mode. Always let the ioctl do the job.
If you need to copy from a user-mode buffer, use a METHOD_OUT_DIRECT
ioctl. Put the metadata (like the pipe number, maybe) in the input
buffer. Make your data buffer the “output” buffer. The I/O manager
will lock the pages down and hand you a kernel mode address, free of charge.


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

Thanks Alex and Tim for replying. I actually know that this is a user mode address and that using that is unsafe. The issue is that I am not the one that is putting this address in the URB. The only component i have in the entire operation is the bus driver. I am suspecting that the URB is containing user mode address when it reaches my driver. Now by functionality of my driver it collects the requests in Workitems an schedules them. Now since the workitems are processed in System context in which the address is not valid the bugcheck occurs. Is the working of the driver correct to send me User mode address in TransferBuffer. If it is what should be done in this case ? If not how can i confirm the same ?