WinUSB Blue Screen

Hi All,

I have a custom USB device which got the USB miniport host (usbhci or
something else) to bug-check D1 (invalid access to memory)

This started with an implementation of DDK 6.0 BulkUsb sample. Now I have
the same results with WinUSB.

Using .Net helps but it also happenes with native C++. My guess is
performance.
If I read more than 128 bytes (the descriptor says 128 bytes buffer) I get
the crash after the 2'nd to 4'th read.

It is also possible that the device is mis-behaving. Old code that I did not
clean yet. Still a stupid device is no reason for a blue-screen.

Any idea?

TIA,
Asaf
http://Asaf.Shelly.co.il

Too soon to speak. After a couple of days it decided to crash on 128 bytes
also. What an unreliable bug...


Asaf
http://AsyncOp.com

Adding USBPort to the list with 0x8E
"USBPORT!USBPORT_AsyncTransfer+e"


Asaf

send the output of !analyze -v from the crash

d

--

This posting is provided "AS IS" with no warranties, and confers no rights.


"Asaf Shelly" <> wrote in message
news:210DAA9A-CCB3-4A51-AB65-...
> Adding USBPort to the list with 0x8E
> "USBPORT!USBPORT_AsyncTransfer+e"
>
>
> Asaf
>

Hi Doron,

Sorry for the delayed response (weekend and all..)

The problem was that the device was defined as a USB 2.0 device (usbbcd) but
was internally configured as USB 1.1. A while ago someone found a problem
with USB 2.0 speed so he reconfigured the device to work as a USB 1.1 device
(but didn't understand USB well enough to look for this in the descriptors).

Can the USB stack detect the speed as reported by the hub when the device is
connected. Clearly this is a mulfunction in the device but would it justify a
bad memory access bug-check?

Here is the dump:
1: kd> !analyze -v
************************************************** *****************************
*
*
* Bugcheck Analysis
*
*
*
************************************************** *****************************

KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)
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: b8b0332e, The address that the exception occurred at
Arg3: 9b8f87f4, Trap Frame
Arg4: 00000000

Debugging Details:
------------------

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

************************************************** ******
.............. some more of that ...............
************************************************** ******

ADDITIONAL_DEBUG_TEXT:
Use '!findthebuild' command to search for the target build information.
If the build information is available, run '!findthebuild -s ; .reload' to
set symbol path and load symbols.

MODULE_NAME: WinUSB

FAULTING_MODULE: 804d7000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc86f

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

FAULTING_IP:
USBPORT!USBPORT_AsyncTransfer+e
b8b0332e 83b91c01000001 cmp dword ptr [ecx+11Ch],1

TRAP_FRAME: 9b8f87f4 -- (.trap 0xffffffff9b8f87f4)
ErrCode = 00000000
eax=891cf7ac ebx=8aa54ed8 ecx=ffffffff edx=899cb0ec esi=891cf7ac edi=80546acc
eip=b8b0332e esp=9b8f8868 ebp=9b8f8868 iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
USBPORT!USBPORT_AsyncTransfer+0xe:
b8b0332e 83b91c01000001 cmp dword ptr [ecx+11Ch],1
ds:0023:0000011b=????????
Resetting default scope

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x8E

MANAGED_STACK: !dumpstack -EE
OS Thread Id: 0x0 (1)
TEB information is not available so a stack size of 0xFFFF is assumed
Current frame:
ChildEBP RetAddr Caller,Callee

LAST_CONTROL_TRANSFER: from 804fe827 to 804f9f43

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be
wrong.
9b8f83bc 804fe827 0000008e c0000005 b8b0332e nt!KeBugCheckEx+0x1b
9b8f8784 80542095 9b8f87a0 00000000 9b8f87f4 nt!KeRaiseUserException+0xc29
9b8f8868 b8b02f14 899cb028 8aa54ed8 891cf7ac nt!Kei386EoiHelper+0x1d9
9b8f8894 b8b08088 89a94030 899cb028 00000090 USBPORT!USBPORT_ProcessURB+0x3f4
9b8f88b4 b8af13d2 89a94030 8aa54ed8 89a94030
USBPORT!USBPORT_PdoInternalDeviceControlIrp+0x7e
9b8f88d8 804ef19f 8aa54fb4 89a94188 806e6428 USBPORT!USBPORT_Dispatch+0x148
9b8f890c afa7659c 9b8f8934 afa7a82d 8aa54ed8 nt!IoBuildPartialMdl+0xed
9b8f8914 afa7a82d 8aa54ed8 89a94030 8aa54ed8 usbhub!USBH_PassIrp+0x18
9b8f8934 afa7b0ae 899930e8 8aa54ed8 88fa0de8 usbhub!USBH_PdoUrbFilter+0xbd
9b8f8950 afa785e4 891cf7ac 8aa54ed8 9b8f8994 usbhub!USBH_PdoDispatch+0x202
9b8f8960 804ef19f 88fa0de8 8aa54ed8 806e6428 usbhub!USBH_HubDispatch+0x48
9b8f8994 9a9cc164 9b8f89e0 89225fd8 7708c8a8 nt!IoBuildPartialMdl+0xed
9b8f89ac 9b6aa777 00000005 89225f00 88f73750 wdf01000+0x16164
9b8f8a08 9a9e5072 030d5910 76dda0f8 0000000f WinUSB+0x5777
9b8f8a2c 9a9e63d0 770d5910 76dda0f8 0000000f wdf01000+0x2f072
9b8f8a5c 9a9e89ac 76dda0f8 89225f00 88f2a6e8 wdf01000+0x303d0
9b8f8a78 9a9e9b7f 88f2a600 00000000 89225f00 wdf01000+0x329ac
9b8f8a98 9a9ea29b 89225f00 88f64e00 89029888 wdf01000+0x33b7f
9b8f8ac0 9a9ea70f 89225f00 88f2a6e8 76dda0f8 wdf01000+0x3429b
9b8f8ae0 9a9caedd 88f2a6e8 89225f00 89225fd8 wdf01000+0x3470f
9b8f8b00 9b6aa51b 00000000 76dda0f8 88f2a6e8 wdf01000+0x14edd
9b8f8b24 9b6a7cdb 899629f8 7709b1f8 76dda0f8 WinUSB+0x551b
9b8f8b5c 9a9e5072 7709b1f8 76dda0f8 0000000f WinUSB+0x2cdb
9b8f8b80 9a9e63d0 7709b1f8 76dda0f8 0000000f wdf01000+0x2f072
9b8f8bb0 9a9e89ac 76dda0f8 89225f00 88f64e00 wdf01000+0x303d0
9b8f8bcc 9a9e9a36 88f64e00 00000000 89a426f0 wdf01000+0x329ac
9b8f8bec 9a9eb824 89225f00 88fb09d0 88fc4840 wdf01000+0x33a36
9b8f8c10 9a9daa3f 8aa54ed8 9b8f8c50 804ef19f wdf01000+0x35824
9b8f8c1c 804ef19f 88fb09d0 8aa54ed8 806e6428 wdf01000+0x24a3f
9b8f8c50 8057f982 8aa54fd8 892530e8 8aa54ed8 nt!IoBuildPartialMdl+0xed
9b8f8c64 805807f7 88fb09d0 8aa54ed8 892530e8 nt!NtWriteFile+0x2a90
9b8f8d00 80579274 00000574 00000595 00000000 nt!NtWriteFile+0x3905
9b8f8d34 8054162c 00000574 00000595 00000000 nt!NtDeviceIoControlFile+0x2a
9b8f8d70 9c17454a 00000000 00000000 00000000
nt!KeReleaseInStackQueuedSpinLockFromDpcLevel+0xb7 4
9b8f8ddc 805460ee 9c17e93d 9c17dfc0 00000000
rdbss!RxpWorkerThreadDispatcher+0x18a
9b8f8e0c 7c910222 00000022 00000ce8 00000000 nt!KiDispatchInterrupt+0x72e
9b8f8e20 7c910222 00000002 00000000 00150000 ntdll!RtlAllocateHeap+0x15e
9b8f8e4c 7c910222 7c91019b 000001db 00000000 ntdll!RtlAllocateHeap+0x15e
00000000 00000000 00000000 00000000 00000000 ntdll!RtlAllocateHeap+0x15e


STACK_COMMAND: kb

FOLLOWUP_IP:
WinUSB+5777
9b6aa777 84c0 test al,al

SYMBOL_STACK_INDEX: d

SYMBOL_NAME: WinUSB+5777

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: WinUSB.sys

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner
---------

OK... so we can take the USB version out of the list..
Below is another one.
It is harder to reproduce with smaller endpoint buffers (32,64) and easier
with 256.

Asaf

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: 00000000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: ba3eafd3, address which referenced memory

Debugging Details:
------------------
************************************************** *******************

ADDITIONAL_DEBUG_TEXT:
Use '!findthebuild' command to search for the target build information.
If the build information is available, run '!findthebuild -s ; .reload' to
set symbol path and load symbols.

MODULE_NAME: usbuhci

FAULTING_MODULE: 804d7000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 480254ce

WRITE_ADDRESS: unable to get nt!MmSpecialPoolStart
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPoolCodeStart
unable to get nt!MmPoolCodeEnd
00000000

CURRENT_IRQL: 2

FAULTING_IP:
usbuhci!UhciProcessDoneAsyncTd+dd
ba3eafd3 f3a5 rep movs dword ptr es:[edi],dword ptr [esi]

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from ba3eafd3 to 805446f0

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be
wrong.
ba4d3b98 ba3eafd3 badb0d00 620b45ff 50726261 nt!Kei386EoiHelper+0x2834
ba4d3c28 ba3eb520 899ca9dc 88fe31a0 88ff8df0
usbuhci!UhciProcessDoneAsyncTd+0xdd
ba4d3c48 ba3e8ded 899ca9dc 88fe3000 ba4d3c78
usbuhci!UhciPollAsyncEndpoint+0x450
ba4d3c58 b8af74aa 899ca9dc 88ff8df0 80546acc usbuhci!UhciPollEndpoint+0x1f
ba4d3c78 b8af8768 026c6f50 899ca0e0 88ff8c78 USBPORT!USBPORT_PollEndpoint+0xe8
ba4d3ca0 b8afc0a0 899ca028 50457270 80546acc
USBPORT!USBPORT_CoreEndpointWorker+0x2be
ba4d3cd0 b8b0a24b 899ca028 80546acc 899ca028 USBPORT!USBPORT_DpcWorker+0x18a
ba4d3d0c b8b0a3c2 899ca028 00000001 8055c0c0
USBPORT!USBPORT_IsrDpcWorker+0x38f
ba4d3d28 80545e7f 899ca64c 6b755044 00000000 USBPORT!USBPORT_IsrDpc+0x166
ba4d3d50 80545d64 00000000 0000000e 00000000 nt!KiDispatchInterrupt+0x4bf
ba4d3d54 00000000 0000000e 00000000 00000000 nt!KiDispatchInterrupt+0x3a4


STACK_COMMAND: kb

FOLLOWUP_IP:
usbuhci!UhciProcessDoneAsyncTd+dd
ba3eafd3 f3a5 rep movs dword ptr es:[edi],dword ptr [esi]

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: usbuhci!UhciProcessDoneAsyncTd+dd

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: usbuhci.sys

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner
---------

Asaf Shelly <> wrote:
>
>OK... so we can take the USB version out of the list..
>Below is another one.
>It is harder to reproduce with smaller endpoint buffers (32,64) and easier
>with 256.

Well, hold on. What kind of pipes are you using? In a full-speed device,
bulk pipes can have 8, 16, 32, or 64-byte packets. In a high-speed device,
bulk pipes can only use 512-byte packets. Those are the ONLY choices. A
bulk pipe can NEVER have 256-byte packets.
--
Tim Roberts,
Providenza & Boekelheide, Inc.

How about that....
It has been 10 years since I last read chapter 9. Didn't even remember there
was a limit.
Thanks for the answer it was really helpful.
Now can someone please tell me why my USB1.1 hardware enjoys 2X time
improvement when I am using 128 bytes per buffer.

* Also this is no reason for a blue-screen. The host can detect that the
device is doing something wrong and ignore it. I know that devices are not
expected to make such mistakes but this is load-time tests so there is no
impact on performance. Having a device that can make the kernel read invalid
buffers is also a potential security risk.

Thanks again for the help.
Asaf

Never mind about the 128 buffers. Probably a device internal problem.

TIA,
Asaf

Asaf Shelly <> wrote:
>
>How about that....
>It has been 10 years since I last read chapter 9. Didn't even remember there
>was a limit.
>Thanks for the answer it was really helpful.
>Now can someone please tell me why my USB1.1 hardware enjoys 2X time
>improvement when I am using 128 bytes per buffer.

Absolutely. Remember USB is a scheduled bus; the entire frame is scheduled
in advance; the hardware then executes the transfers on its own while the
HCD driver schedules the next frame. Let's say you send 64 bytes and wait,
then send 64 bytes and wait. In that case, you are going to send exactly
one packet per frame, so no more than 64 bytes per millisecond.

But when you send 128 bytes and wait, the HCD driver can schedule that as 2
64-bit packets in a single frame. That doubles your throughput. If you
send 1024-byte buffers, you'll do even better.

Howver, the device's endpoint packet size is limited to 64 bytes (for full
speed).

>* Also this is no reason for a blue-screen. The host can detect that the
>device is doing something wrong and ignore it. I know that devices are not
>expected to make such mistakes but this is load-time tests so there is no
>impact on performance. Having a device that can make the kernel read invalid
>buffers is also a potential security risk.

Well, USB is a protocol bus, and devices are expected to obey the
protocols. There are tests for protocol compliance that must be passed
before your driver can be WHQL-approved, but the system cannot be expected
to protect against every protocol violation.

Yes, you are right, and I am just making lame excuses.
--
Tim Roberts,
Providenza & Boekelheide, Inc.