WinUSB bugchecks

Hi,

we are developing an USBTMC Device. The firmware runs on a Windows CE
platform. The communication to the device is done through NI-Visa from
National Instruments. Their USBTMC driver is based on WinUSB.

In our CE device we have some debug assertions. In case of such a debug
assertion on the device we get a blue screen at the PC (Vista only)

20.361 684 104 USBTMC Query – the Firmware runs into a Debug Assertion – all
threads (incl. USBTMC Driver) are stopped.
20.361 702 125 NI Visa waits for answer (IN Transaction)
22.335 016 917 Timeout after 2s – INITIATE_ABORT_BULK_IN on Control Endpoint
USBTMC specs says: After receiving INITIATE_ABORT_BULK_IN request, the
device must return a control endpoint response… but the device is still in
Debug Assertion Break –no answer from device – NI Visa crashes with blue
screen


A crash dump analysis shows us where the winusb driver bugchecks:

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be
wrong.
8b9b8974 8063770c 0000010d 00000005 00000000 nt!KeBugCheckEx+0x1e
8b9b8990 8062df0f 855d2b40 00000005 00000000 Wdf01000!FxVerifierBugCheck+0x24
8b9b89bc 8061d0ae 855d2b40 00000000 00001203
Wdf01000!FxObjectHandleGetPtr+0x71
8b9b8b00 a41d6df5 855d2bf8 00000000 00000000
Wdf01000!imp_WdfUsbTargetPipeAbortSynchronously+0x 2be
8b9b8b34 a41d7618 852f8f40 7881adf8 7a99aae0 WinUSB!WinUSB_AbortPipe+0xb1
8b9b8b6c 8064c514 7881adf8 7a99aae0 00000000 WinUSB!WinUSB_DeviceControl+0x308
8b9b8b90 8064d924 7881adf8 7a99aae0 00000000
Wdf01000!FxIoQueueIoDeviceControl::Invoke+0x30
8b9b8bc0 8064ffb8 7a99aae0 85665518 877e5200
Wdf01000!FxIoQueue:ispatchRequestToDriver+0x445
8b9b8be0 80651722 877e5200 80677188 877e5200
Wdf01000!FxIoQueue:ispatchEvents+0x4e9
8b9b8bfc 8065285d 00000000 8549fcd8 85444030
Wdf01000!FxIoQueue::QueueRequest+0x237
8b9b8c20 80641665 85504a60 8b9b8c44 81cd0fd3 Wdf01000!FxPkgIo:ispatch+0x377
8b9b8c2c 81cd0fd3 85444030 85504a60 85504a60 Wdf01000!FxDevice:ispatch+0x7f
8b9b8c44 81e61615 8549fcd8 85504a60 85504b60 nt!IofCallDriver+0x64
8b9b8c64 81e61dba 85444030 8549fcd8 00000000
nt!NtQueryInformationProcess+0x1c63
8b9b8d00 81e4ba8d 85444030 85504a60 00000000
nt!NtQueryInformationProcess+0x2408
8b9b8d34 81c6ca1a 000006f0 00000739 00000000 nt!NtDeviceIoControlFile+0x2a
8b9b8d64 77429a94 badb0d00 05cadb84 00000000 nt!ZwQueryLicenseValue+0xbd2
8b9b8d68 badb0d00 05cadb84 00000000 00000000 0x77429a94
8b9b8d6c 05cadb84 00000000 00000000 00000000 0xbadb0d00
8b9b8d70 00000000 00000000 00000000 00000000 0x5cadb84

I could also provide a detailed Log of the USB communication.
Is there any body out there (at microsoft) who can help us to fix this
problem.


Thanks in Advance.

Regards, Claudio

Hi Claudio,

You can not call WinUsb_AbortPipe on control pipe. You can possibly cancel
the control transfer using CancelIoEx using the overlapped passed to
WinUsb_ControlTransfer. As such control transfer would time out in 5
seconds.

HTH,
Praveen

--

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

Claudio <> wrote:
>
>we are developing an USBTMC Device. The firmware runs on a Windows CE
>platform. The communication to the device is done through NI-Visa from
>National Instruments. Their USBTMC driver is based on WinUSB.
>
>In our CE device we have some debug assertions. In case of such a debug
>assertion on the device we get a blue screen at the PC (Vista only)
>...
>I could also provide a detailed Log of the USB communication.
>Is there any body out there (at microsoft) who can help us to fix this
>problem.

Well, it seems to me that the way to fix your problem is to eliminate the
debug assertions. USB is a real-time bus; if you block its activities,
things will go to hell in a handbasket.
--
Tim Roberts,
Providenza & Boekelheide, Inc.

Hi Praveen,

thank you for your reply. Can you tell me how you figured out, that the
WinUsb_AbortPipe call is related to the control endpoint? From my log of the
transfered packes on the usb bus I only know, that the last request the
Driver sends is a USB_TMC 0x03 request (INITIATE_ABORT_BULK_IN) - which makes
sense. As there is no reaction to this request - since the CE device is
stalled - (hopefully during the development cycle only :-) ) NI-Visa seems to
call WinUsb_AbortPipe (which pipe I can't figure out...)

You wrote "You can not call WinUsb_AbortPipe on control pipe." - is there
anywhere a documentation for this behaviour. In the MSDN documentation of the
API (http://msdn.microsoft.com/en-us/library/aa476442.aspx) I can not find
any information about this.

It would be very interesting for me to forward this detailed information to
National Instruments - since I'm not the USB driver developer (on the PC
side).

Tx and greetings from Austria,
Claudio



"Praveen Rao" wrote:

> Hi Claudio,
>
> You can not call WinUsb_AbortPipe on control pipe. You can possibly cancel
> the control transfer using CancelIoEx using the overlapped passed to
> WinUsb_ControlTransfer. As such control transfer would time out in 5
> seconds.
>
> HTH,
> Praveen
>
> --
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>

Tim Roberts wrote:
> Claudio <> wrote:
>>
>> we are developing an USBTMC Device. The firmware runs on a Windows CE
>> platform. The communication to the device is done through NI-Visa
>> from National Instruments. Their USBTMC driver is based on WinUSB.
>>
>> In our CE device we have some debug assertions. In case of such a
>> debug assertion on the device we get a blue screen at the PC (Vista
>> only) ...
>> I could also provide a detailed Log of the USB communication.
>> Is there any body out there (at microsoft) who can help us to fix
>> this problem.
>
> Well, it seems to me that the way to fix your problem is to eliminate
> the debug assertions. USB is a real-time bus; if you block its
> activities, things will go to hell in a handbasket.

And the host controller or its driver should log errors and kick the device
off the bus, not crash the OS.

"Ben Voigt [C++ MVP]" <> wrote:
>Tim Roberts wrote:
>> Claudio <> wrote:
>>>
>>> In our CE device we have some debug assertions. In case of such a
>>> debug assertion on the device we get a blue screen at the PC (Vista
>>> only) ...
>>> I could also provide a detailed Log of the USB communication.
>>> Is there any body out there (at microsoft) who can help us to fix
>>> this problem.
>>
>> Well, it seems to me that the way to fix your problem is to eliminate
>> the debug assertions. USB is a real-time bus; if you block its
>> activities, things will go to hell in a handbasket.
>
>And the host controller or its driver should log errors and kick the device
>off the bus, not crash the OS.

Neither the host controller nor its driver did so. It was a KMDF Verifier
violation.
--
Tim Roberts,
Providenza & Boekelheide, Inc.

Hi Claudio,

Based on your log

22.335 016 917 Timeout after 2s – INITIATE_ABORT_BULK_IN on Control Endpoint
USBTMC specs says: After receiving INITIATE_ABORT_BULK_IN request, the
device must return a control endpoint response… but the device is still in
Debug Assertion Break –no answer from device – NI Visa crashes with blue
screen

I suspected that Control Endpoint didn't respond and app tried to abort
that. Moreover this is a known issue in WinUsb with abort on control pipe
and the crash stack suggested that the handle passed to
WdfUsbTargetPipeAbortSynchronously was NULL. You can verify this using KMDF
tracelog (instructions on how to look at the log are at
http://searchvote.com/default.aspx?m...g&vertical=Web)

You can break into the application process and see which pipe it tried to
abort on to confirm that it is control pipe.

We need to document the issue with WinUsb control pipe abort.

Praveen

--

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

Actually the KMDF verifier violation in this case likely means a crash with
or without verifier.

This is likely an issue with abort invoked on control pipe in WinUsb as I
indicated in the parallel thread.

Praveen

--

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

Sorry the link to KMDF tracelog instructions is

http://www.microsoft.com/whdc/Driver...DF_IfrLog.mspx

Please ignore the earlier link.

Thanks,
Praveen

--

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