How to avoid blue screen when disconnecting USB device

NTDEV
1

Hi all,

I am developing a USB driver with WDF 1.9 for Win7 32/64. The driver gets an I/O request to read a rather big amount of data, which will be placed in the users output buffer.
I split the originated request into a couple of sub-request, which have the originated request as parent and use the user’s output buffer as the target with offsets.

This works fine for the normal operation of the driver. Now I discovered that when I terminate the application that is using the driver when in the middle of an I/O request I get a bug-check 0x10d saying that there are still references to the output buffer:

Arg1: 00000003, Windows Driver Framework Verifier has encountered a fatal error.
In particular, an I/O request has been completed, but a framework
request object cannot be deleted because there are outstanding
references to the input buffer or the output buffer, or both. The
driver’s IFR will include details on the outstanding references.
Arg2: 793795d0, WDFREQUEST handle
Arg3: 00000013, The number of outstanding references remaining on both buffers.
Arg4: 86b26a60, Reserved.

To correct that issue I have registered a cleanup-callback routine for the sub-request, that will release the handle to the output buffer by calling WdfRequestReuse(). Now an abort of the application in the middle of an I/O request works without a problem.

Now I have the issue that when I pull the USB plug of my device I get another bug-check 0x0A: IRQL_NOT_LESS_OR_EQUAL even when there is no I/O request in place. Pulling the plug at any time was not a problem, when I had the previous version of my driver without the cleanup callback registered.
I also use a context for the sub-request to track if a WdfRequestReuse() has to be done or not, but this does not help to fix the issue.

Does someone have an idea what could be the problem in my case?
Is there another way to release the handles to the output buffer for my sub-requests?
What could be the reason for the IRQ level issue?

Thanks for your support and best regards

Andreas

2

You’re not giving us much to go on! At least give us the !analyze -v output from the crash you’re asking us about.

Peter
OSR

3

Hi Peter,

sorry, I am quite new to this and thought this would be too much to post in this forum.
Here is the corresponding !analyze -v output for the bug check.
It seems that my WinDbg is not fully configured, as there are modules not loadable. Hope that does not disturb to read the log.

regards, Andreas

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

IRQL_NOT_LESS_OR_EQUAL (a)
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 a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 000000e8, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 806e8a16, address which referenced memory

Debugging Details:

The call to LoadLibrary(kdexts) failed, Win32 error 0n2
“Das System kann die angegebene Datei nicht finden.”
Please check your debugger configuration and/or network access.
The call to LoadLibrary(kdexts) failed, Win32 error 0n2
“Das System kann die angegebene Datei nicht finden.”
Please check your debugger configuration and/or network access.
The call to LoadLibrary(kdexts) failed, Win32 error 0n2
“Das System kann die angegebene Datei nicht finden.”
Please check your debugger configuration and/or network access.
The call to LoadLibrary(kdexts) failed, Win32 error 0n2
“Das System kann die angegebene Datei nicht finden.”
Please check your debugger configuration and/or network access.

WRITE_ADDRESS: The call to LoadLibrary(kdexts) failed, Win32 error 0n2
“Das System kann die angegebene Datei nicht finden.”
Please check your debugger configuration and/or network access.
000000e8

CURRENT_IRQL: 2

FAULTING_IP:
hal!KeAcquireInStackQueuedSpinLock+26
806e8a16 8711 xchg edx,dword ptr [ecx]

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: Idle

TRAP_FRAME: 8055120c – (.trap 0xffffffff8055120c)
ErrCode = 00000002
eax=80551294 ebx=00000000 ecx=000000e8 edx=80551294 esi=00000000 edi=87c4d5e8
eip=806e8a16 esp=80551280 ebp=805512a0 iopl=0 nv up ei pl nz ac po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010212
hal!KeAcquireInStackQueuedSpinLock+0x26:
806e8a16 8711 xchg edx,dword ptr [ecx] ds:0023:000000e8=???
Resetting default scope

LAST_CONTROL_TRANSFER: from 806e8a16 to 80544768

STACK_TEXT:
8055120c 806e8a16 badb0d00 80551294 8a25b9dc nt!KiTrap0E+0x238
80551280 804fc4c6 87c4d5e8 87c4d5a8 00000000 hal!KeAcquireInStackQueuedSpinLock+0x26
805512a0 804f1810 87c4d5e8 00000000 00000000 nt!KeInsertQueueApc+0x20
805512d4 b8f480d5 87c4d5a8 877fe590 8a25b028 nt!IopfCompleteRequest+0x1d8
8055133c b8f48d47 8a1e2cfc c0000011 8a25b7d8 USBPORT!USBPORT_CompleteTransfer+0x373
8055136c b8f49944 026e6f44 8a25b0e0 8a25b0e0 USBPORT!USBPORT_DoneTransfer+0x137
805513a4 b8f4b13a 8a25b028 80546b4c 8a25b230 USBPORT!USBPORT_FlushDoneTransferList+0x16c
805513d0 b8f5924b 8a25b028 80546b4c 8a25b028 USBPORT!USBPORT_DpcWorker+0x224
8055140c b8f593c2 8a25b028 00000001 8055c0c0 USBPORT!USBPORT_IsrDpcWorker+0x38f
80551428 80545eff 8a25b64c 6b755044 00000000 USBPORT!USBPORT_IsrDpc+0x166
80551450 80545de4 00000000 0000000e 00000000 nt!KiRetireDpcList+0x61
80551454 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x28

STACK_COMMAND: kb

FOLLOWUP_IP:
USBPORT!USBPORT_CompleteTransfer+373
b8f480d5 8a4dd7 mov cl,byte ptr [ebp-29h]

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: USBPORT!USBPORT_CompleteTransfer+373

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: USBPORT

IMAGE_NAME: USBPORT.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 480254ce

FAILURE_BUCKET_ID: 0xA_USBPORT!USBPORT_CompleteTransfer+373

BUCKET_ID: 0xA_USBPORT!USBPORT_CompleteTransfer+373

Followup: MachineOwner

4

You sent an irp (most likely urb) to the usb stack without either a completion routine or with a completion routine with returned !STATUS_MORE_PROCESSING_REQUIRED which allowed the irp to flow back to the io manager as a threaded irp.

d

debt from my phone

From: xxxxx@gmx.net
Sent: 10/3/2012 1:53 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to avoid blue screen when disconnecting USB device

Hi Peter,

sorry, I am quite new to this and thought this would be too much to post in this forum.
Here is the corresponding !analyze -v output for the bug check.
It seems that my WinDbg is not fully configured, as there are modules not loadable. Hope that does not disturb to read the log.

regards, Andreas

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

IRQL_NOT_LESS_OR_EQUAL (a)
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 a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 000000e8, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 806e8a16, address which referenced memory

Debugging Details:

The call to LoadLibrary(kdexts) failed, Win32 error 0n2
“Das System kann die angegebene Datei nicht finden.”
Please check your debugger configuration and/or network access.
The call to LoadLibrary(kdexts) failed, Win32 error 0n2
“Das System kann die angegebene Datei nicht finden.”
Please check your debugger configuration and/or network access.
The call to LoadLibrary(kdexts) failed, Win32 error 0n2
“Das System kann die angegebene Datei nicht finden.”
Please check your debugger configuration and/or network access.
The call to LoadLibrary(kdexts) failed, Win32 error 0n2
“Das System kann die angegebene Datei nicht finden.”
Please check your debugger configuration and/or network access.

WRITE_ADDRESS: The call to LoadLibrary(kdexts) failed, Win32 error 0n2
“Das System kann die angegebene Datei nicht finden.”
Please check your debugger configuration and/or network access.
000000e8

CURRENT_IRQL: 2

FAULTING_IP:
hal!KeAcquireInStackQueuedSpinLock+26
806e8a16 8711 xchg edx,dword ptr [ecx]

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: Idle

TRAP_FRAME: 8055120c – (.trap 0xffffffff8055120c)
ErrCode = 00000002
eax=80551294 ebx=00000000 ecx=000000e8 edx=80551294 esi=00000000 edi=87c4d5e8
eip=806e8a16 esp=80551280 ebp=805512a0 iopl=0 nv up ei pl nz ac po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010212
hal!KeAcquireInStackQueuedSpinLock+0x26:
806e8a16 8711 xchg edx,dword ptr [ecx] ds:0023:000000e8=???
Resetting default scope

LAST_CONTROL_TRANSFER: from 806e8a16 to 80544768

STACK_TEXT:
8055120c 806e8a16 badb0d00 80551294 8a25b9dc nt!KiTrap0E+0x238
80551280 804fc4c6 87c4d5e8 87c4d5a8 00000000 hal!KeAcquireInStackQueuedSpinLock+0x26
805512a0 804f1810 87c4d5e8 00000000 00000000 nt!KeInsertQueueApc+0x20
805512d4 b8f480d5 87c4d5a8 877fe590 8a25b028 nt!IopfCompleteRequest+0x1d8
8055133c b8f48d47 8a1e2cfc c0000011 8a25b7d8 USBPORT!USBPORT_CompleteTransfer+0x373
8055136c b8f49944 026e6f44 8a25b0e0 8a25b0e0 USBPORT!USBPORT_DoneTransfer+0x137
805513a4 b8f4b13a 8a25b028 80546b4c 8a25b230 USBPORT!USBPORT_FlushDoneTransferList+0x16c
805513d0 b8f5924b 8a25b028 80546b4c 8a25b028 USBPORT!USBPORT_DpcWorker+0x224
8055140c b8f593c2 8a25b028 00000001 8055c0c0 USBPORT!USBPORT_IsrDpcWorker+0x38f
80551428 80545eff 8a25b64c 6b755044 00000000 USBPORT!USBPORT_IsrDpc+0x166
80551450 80545de4 00000000 0000000e 00000000 nt!KiRetireDpcList+0x61
80551454 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x28

STACK_COMMAND: kb

FOLLOWUP_IP:
USBPORT!USBPORT_CompleteTransfer+373
b8f480d5 8a4dd7 mov cl,byte ptr [ebp-29h]

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: USBPORT!USBPORT_CompleteTransfer+373

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: USBPORT

IMAGE_NAME: USBPORT.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 480254ce

FAILURE_BUCKET_ID: 0xA_USBPORT!USBPORT_CompleteTransfer+373

BUCKET_ID: 0xA_USBPORT!USBPORT_CompleteTransfer+373

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

5

Hi Doron,

thanks for the reply.

all of my WdfRequest have a completion routine registered, so I assume that could not be the issue

I never set that type of status in my completion routines, so where could it come from?
Actually the problem appered after I added a cleanup callback to the sub-request, which performs a WDFRequestReuse to get rid of the user buffer references. It also seems that I get the bug check when pulling the plug an no more requests are in use. It seems that there is somthing still hanging somewhere in the framework that I don’t know of.

Is there a code example of how to cope with splitting requests using the user’s buffer and getting rid of them when the application terminates uncoordinated or the USB is disconnected inbetween a transaction?

Thanks and regards

Andreas

6

The IRPs you send from your driver must either be allocated by IoAllocateIrp or IoBuildAsynchronousFsdRequest. You should NOT use IoBuildDeviceIoControlRequest or IoBuildSynchronousFsdRequest. You should also have a top-level completion routine which returns STATUS_MORE_PROCESSING_REQUIRED to stop the IO manager from further holding to the IRP.

7

Hi Doron and Alex,

I am using the WDF to write my USB driver. Actually I can not link your answers to my code, because I do not know the routines mentioned by Alex and do not set the status in my completion routine explicitly, it comes from the completion parameters comming with the request.

Again, I try to briefly describe my scenario. Maybe you can find out what I am doing wrong, as I said my experience with WDF is small and I am possibly on the wrong track.

  1. I get an I/O request comming from the application requesting a big amount of data from my device
  2. I create own subrequest to split the request to my device in chunks, these use the user output buffer with appropriate offset values. I register a cleanup routine for the subrequests. The subrequest has the original I/O request as the parent.
  3. I send all sub-requests to the device for asynchronous communication, and register a callback for completion.
  4. The remaining data not handled by any subrequest will be requested from the device using the original I/O request comming from the application. Again asynchronously with a completion callback installed.
  5. In the subrequest completion routine I delete the subrequest object, which triggers the cleanup routine, which calls WdfRequestReuse to remove any reference to the original data output buffer.
  6. In the original I/O request completion routine I terminate the original request calling WdfRequestCompleteWithInformation and passing the status that I retrieved from the completion parameters.

This scenario all works fine for me in normal operation and when aborting the application in the middle of an I/O request. But in the end when pulling the USB plug, even if no further transaction is in place I get the bug check as posted above.
By the way the device in configured to allow surprise removal, which I took from an example code.

Any idea, what I am doing wrong?

Thanks for your patience and advice

best regards,

Andreas

8

Show how you’re creating your subrequests.

9

Hi Alex,

this is the routine I call to create and send the subrequests. The WDFMemory object is derived from the orginal request’s output buffer. The routine is called in a loop for the number of required requests.

Thanks, Andreas

NTSTATUS
sendSubFrameRequest(
IN WDFREQUEST Request,
IN WDFMEMORY reqMemory,
IN WDFMEMORY_OFFSET reqMemoryOffset,
IN WDFUSBPIPE TargetPipe,
IN PDEVICE_CONTEXT pDeviceContext
)
{
NTSTATUS status = STATUS_SUCCESS;
WDF_OBJECT_ATTRIBUTES attributes;
WDFREQUEST newRequest;
PSFR_CONTEXT pSFRContext;
BOOLEAN ret;

KdPrint((“Entering sendSubFrameRequest\n”));

//format for sub frame request
WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&attributes, SFR_CONTEXT);
attributes.ParentObject = Request;
attributes.EvtCleanupCallback = subFrameCleanupCallback;

status = WdfRequestCreate(&attributes,
NULL,
&newRequest);

if (!NT_SUCCESS(status)) {
KdPrint((“WdfRequestCreate failed with status 0x%08x\n”, status));
return status;
}

//set sub frame request context
pSFRContext = GetSubFrameRequestContext(newRequest);
pSFRContext->bufferHandleReleased = FALSE;

//format request
status = WdfUsbTargetPipeFormatRequestForRead(TargetPipe,
newRequest,
reqMemory,
&reqMemoryOffset);
if (!NT_SUCCESS(status)) {
KdPrint((“WdfUsbTargetPipeFormatRequestForRead failed with status 0x%08x\n”, status));
return status;
}

//register corresponding completion routine
WdfRequestSetCompletionRoutine(newRequest,
EvtRequestSubFrameReadCompletionRoutine,
TargetPipe);

//send request
ret = WdfRequestSend(newRequest,
WdfUsbTargetPipeGetIoTarget(TargetPipe),
WDF_NO_SEND_OPTIONS);

if (ret == FALSE) {
return WdfRequestGetStatus(newRequest);
}

return status;
}

10

Rather than having a complex scenario like this, have you considered the
possibility of simply sending the original IRP downward with a new
operation specified in its stack? It seems that is what you are doing
using a more complex solution.
joe

Hi Alex,

this is the routine I call to create and send the subrequests. The
WDFMemory object is derived from the orginal request’s output buffer. The
routine is called in a loop for the number of required requests.

Thanks, Andreas

NTSTATUS
sendSubFrameRequest(
IN WDFREQUEST Request,
IN WDFMEMORY reqMemory,
IN WDFMEMORY_OFFSET reqMemoryOffset,
IN WDFUSBPIPE TargetPipe,
IN PDEVICE_CONTEXT pDeviceContext
)
{
NTSTATUS status = STATUS_SUCCESS;
WDF_OBJECT_ATTRIBUTES attributes;
WDFREQUEST newRequest;
PSFR_CONTEXT pSFRContext;
BOOLEAN ret;

KdPrint((“Entering sendSubFrameRequest\n”));

//format for sub frame request
WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&attributes, SFR_CONTEXT);
attributes.ParentObject = Request;
attributes.EvtCleanupCallback = subFrameCleanupCallback;

status = WdfRequestCreate(&attributes,
NULL,
&newRequest);

if (!NT_SUCCESS(status)) {
KdPrint((“WdfRequestCreate failed with status 0x%08x\n”, status));
return status;
}

//set sub frame request context
pSFRContext = GetSubFrameRequestContext(newRequest);
pSFRContext->bufferHandleReleased = FALSE;

//format request
status = WdfUsbTargetPipeFormatRequestForRead(TargetPipe,
newRequest,
reqMemory,
&reqMemoryOffset);
if (!NT_SUCCESS(status)) {
KdPrint((“WdfUsbTargetPipeFormatRequestForRead failed with status
0x%08x\n”, status));
return status;
}

//register corresponding completion routine
WdfRequestSetCompletionRoutine(newRequest,
EvtRequestSubFrameReadCompletionRoutine,
TargetPipe);

//send request
ret = WdfRequestSend(newRequest,
WdfUsbTargetPipeGetIoTarget(TargetPipe),
WDF_NO_SEND_OPTIONS);

if (ret == FALSE) {
return WdfRequestGetStatus(newRequest);
}

return status;
}

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

11

The e8 is very suspicious; it suggests an attempt to derference a NULL
pointer.

What are you submitting to the work queue? You have to be careful about
passing pointers; the thing they point to has to be valid into the
indefinite future, when they are used by the thread.
joe

Hi Peter,

sorry, I am quite new to this and thought this would be too much to post
in this forum.
Here is the corresponding !analyze -v output for the bug check.
It seems that my WinDbg is not fully configured, as there are modules not
loadable. Hope that does not disturb to read the log.

regards, Andreas

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

IRQL_NOT_LESS_OR_EQUAL (a)
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 a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 000000e8, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only
on chips which support this level of status)
Arg4: 806e8a16, address which referenced memory

Debugging Details:

The call to LoadLibrary(kdexts) failed, Win32 error 0n2
“Das System kann die angegebene Datei nicht finden.”
Please check your debugger configuration and/or network access.
The call to LoadLibrary(kdexts) failed, Win32 error 0n2
“Das System kann die angegebene Datei nicht finden.”
Please check your debugger configuration and/or network access.
The call to LoadLibrary(kdexts) failed, Win32 error 0n2
“Das System kann die angegebene Datei nicht finden.”
Please check your debugger configuration and/or network access.
The call to LoadLibrary(kdexts) failed, Win32 error 0n2
“Das System kann die angegebene Datei nicht finden.”
Please check your debugger configuration and/or network access.

WRITE_ADDRESS: The call to LoadLibrary(kdexts) failed, Win32 error 0n2
“Das System kann die angegebene Datei nicht finden.”
Please check your debugger configuration and/or network access.
000000e8

CURRENT_IRQL: 2

FAULTING_IP:
hal!KeAcquireInStackQueuedSpinLock+26
806e8a16 8711 xchg edx,dword ptr [ecx]

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: Idle

TRAP_FRAME: 8055120c – (.trap 0xffffffff8055120c)
ErrCode = 00000002
eax=80551294 ebx=00000000 ecx=000000e8 edx=80551294 esi=00000000
edi=87c4d5e8
eip=806e8a16 esp=80551280 ebp=805512a0 iopl=0 nv up ei pl nz ac po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010212
hal!KeAcquireInStackQueuedSpinLock+0x26:
806e8a16 8711 xchg edx,dword ptr [ecx]
ds:0023:000000e8=???
Resetting default scope

LAST_CONTROL_TRANSFER: from 806e8a16 to 80544768

STACK_TEXT:
8055120c 806e8a16 badb0d00 80551294 8a25b9dc nt!KiTrap0E+0x238
80551280 804fc4c6 87c4d5e8 87c4d5a8 00000000
hal!KeAcquireInStackQueuedSpinLock+0x26
805512a0 804f1810 87c4d5e8 00000000 00000000 nt!KeInsertQueueApc+0x20
805512d4 b8f480d5 87c4d5a8 877fe590 8a25b028 nt!IopfCompleteRequest+0x1d8
8055133c b8f48d47 8a1e2cfc c0000011 8a25b7d8
USBPORT!USBPORT_CompleteTransfer+0x373
8055136c b8f49944 026e6f44 8a25b0e0 8a25b0e0
USBPORT!USBPORT_DoneTransfer+0x137
805513a4 b8f4b13a 8a25b028 80546b4c 8a25b230
USBPORT!USBPORT_FlushDoneTransferList+0x16c
805513d0 b8f5924b 8a25b028 80546b4c 8a25b028
USBPORT!USBPORT_DpcWorker+0x224
8055140c b8f593c2 8a25b028 00000001 8055c0c0
USBPORT!USBPORT_IsrDpcWorker+0x38f
80551428 80545eff 8a25b64c 6b755044 00000000 USBPORT!USBPORT_IsrDpc+0x166
80551450 80545de4 00000000 0000000e 00000000 nt!KiRetireDpcList+0x61
80551454 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x28

STACK_COMMAND: kb

FOLLOWUP_IP:
USBPORT!USBPORT_CompleteTransfer+373
b8f480d5 8a4dd7 mov cl,byte ptr [ebp-29h]

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: USBPORT!USBPORT_CompleteTransfer+373

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: USBPORT

IMAGE_NAME: USBPORT.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 480254ce

FAILURE_BUCKET_ID: 0xA_USBPORT!USBPORT_CompleteTransfer+373

BUCKET_ID: 0xA_USBPORT!USBPORT_CompleteTransfer+373

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