BulkInPipe Read Request -> 0xc0000001

Hello,

I have a USB device which (should theoretically) send 200 bytes of data via a bulk-in transfer after initiation by some control- commands. However I have a problem to receive that 200 bytes.
To receive those bytes I use an IO queue read request which is triggered from user mode by a ReadFile call. This works so far because the callback is executed. This callback passes the UsbBulkInPipe and the Request from the IO queue to a WdfUsbTargetPipeFormatRequestForRead ? function which is then executed without error. Then a completion routine is passed to WdfRequestSetCompletionRoutine and finally the WdfSendRequest is executed without error.
However after the completion routine is called, the Params->IoStatus.Status contains the Message 0xc0000001 (status_unsuccessful). Using an USB monitor I didn?t observed any bulk-in transfer.
I doubt, that something in my code is wrong because I would expect to see at least a “zero” bulkin transfer after execution of WdfSendRequest. However it could also be, that my USB device is just not sending the expected 200 bytes- I have no idea.

I would be very happy if someone could suggest some tests which I could do to find the problem.

Best regards,
Matthias

xxxxx@alumni.tu-berlin.de wrote:

However after the completion routine is called, the Params->IoStatus.Status contains the Message 0xc0000001 (status_unsuccessful). Using an USB monitor I didn?t observed any bulk-in transfer.
I doubt, that something in my code is wrong because I would expect to see at least a “zero” bulkin transfer after execution of WdfSendRequest. However it could also be, that my USB device is just not sending the expected 200 bytes- I have no idea.

Why don’t you go ahead and show us your code? There are a number of
steps that have to be executed in the right order to make this happen.
You also might include your configuration descriptor, so we can see what
the endpoints look like.


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

What is the USBD_STATUS returned in the URB?

Hello Philip,

the USBD_STATUS says 0x00000000.

@Tim Roberts

I tried to summarize some (hopefully) relevant fragments from my code (some components are copied from Bruno van Dooren’s tutorial on WDF_USB driver):

//EvtDeviceD0Entry callback

status = WdfIoTargetStart(WdfUsbTargetPipeGetIoTarget(
devCtx->UsbBulkInPipe));
if(!NT_SUCCESS(status))
{
KdPrint((__DRIVER_NAME
“WdfIoTargetStart failed with status 0x%08x\n”, status));
return status;
}

// configurating a serialdispatch-IO-queue with a callback to receive read requests

WDF_IO_QUEUE_CONFIG_INIT(&ioQConfig,
WdfIoQueueDispatchSequential);
ioQConfig.EvtIoRead = EvtDeviceIoRead;
status = WdfIoQueueCreate(Device,
&ioQConfig,
WDF_NO_OBJECT_ATTRIBUTES,
&Context->IoReadQueue);
if(!NT_SUCCESS(status))
{
KdPrint((__DRIVER_NAME
“WdfIoQueueCreate failed with status 0x%08x\n”, status));
return status;
}

// finding the pipes to storage its type inside a DeviceContext struct:

pipe = WdfUsbInterfaceGetConfiguredPipe(DeviceContext->UsbInterface,
index,
&pipeConfig);

if(WdfUsbPipeTypeInterrupt == pipeConfig.PipeType)
{
DeviceContext->UsbInterruptPipe = pipe;
KdPrint((__DRIVER_NAME “WdfUsbPipeTypeInterrupt found.\n”));
}
else if(WdfUsbPipeTypeBulk == pipeConfig.PipeType)
{
KdPrint((__DRIVER_NAME “WdfUsbPipeTypeBulk found.\n”));
if(TRUE == WdfUsbTargetPipeIsInEndpoint(pipe))
{
DeviceContext->UsbBulkInPipe = pipe;
KdPrint((__DRIVER_NAME “WdfUsbPipeTypeBulk-> In Endpoint found.\n”));

// EvtDeviceIoRead callback

VOID
EvtDeviceIoRead(
IN WDFQUEUE Queue,
IN WDFREQUEST Request,
IN size_t Length
)
{
NTSTATUS status = STATUS_SUCCESS;

PDEVICE_CONTEXT devCtx = NULL;
WDFMEMORY requestMem;

BYTE *inChar;
size_t length_in = 0;
WDF_MEMORY_DESCRIPTOR memDescriptor;
WDF_USB_CONTROL_SETUP_PACKET controlPacket;

devCtx = GetDeviceContext(WdfIoQueueGetDevice(Queue));
KdPrint((__DRIVER_NAME “Received a read request of %d bytes\n”, Length));

KdPrint((__DRIVER_NAME “Generate ControlTransfer to trigger bulkIn\n”));
status = WdfMemoryCreatePreallocated(WDF_NO_OBJECT_ATTRIBUTES,
&devCtx->USERcommand,
sizeof(devCtx->USERcommand),
&devCtx->WdfUserCommandMemory);
if(!NT_SUCCESS(status))
{
KdPrint((__DRIVER_NAME
“WdfMemoryCreatePreallocated failed with status 0x%08x\n”, status));
}

inChar = WdfMemoryGetBuffer(devCtx->WdfUserCommandMemory, &length_in);

//set ControlByte
*inChar = 0x00;

WDF_MEMORY_DESCRIPTOR_INIT_HANDLE(&memDescriptor,devCtx->WdfUserCommandMemory, NULL);
//set ControlPaket
KdPrint((__DRIVER_NAME “Generate ControlPaket \n”));//
controlPacket.Generic.Bytes[0] = 0x00;
controlPacket.Generic.Bytes[1] = 0x42;
controlPacket.Generic.Bytes[2] = 0x00;
controlPacket.Generic.Bytes[3] = 0x00;
controlPacket.Generic.Bytes[4] = 0x00;
controlPacket.Generic.Bytes[5] = 0x00;
controlPacket.Generic.Bytes[6] = 0x01;
controlPacket.Generic.Bytes[7] = 0x00;

status = WdfRequestRetrieveOutputMemory(Request, &requestMem);
if(!NT_SUCCESS(status))
{
KdPrint((__DRIVER_NAME
“WdfRequestRetrieveOutputMemory failed with status 0x%08x\n”, status));
WdfRequestComplete(Request, status);
return;
}

status = WdfUsbTargetPipeFormatRequestForRead(
devCtx->UsbBulkInPipe,
Request,
requestMem,
NULL);
if(!NT_SUCCESS(status))
{
KdPrint((__DRIVER_NAME
“WdfUsbTargetPipeFormatRequestForRead failed with status 0x%08x\n”, status));
WdfRequestComplete(Request, status);
return;
} else KdPrint((__DRIVER_NAME “WdfUsbTargetPipeFormatRequestForRead succeeded\n”));
WdfRequestSetCompletionRoutine(Request,
EvtIoReadComplete,
devCtx->UsbBulkInPipe);

if(FALSE == WdfRequestSend(Request,
WdfUsbTargetPipeGetIoTarget(devCtx->UsbBulkInPipe),
NULL))
{
KdPrint((__DRIVER_NAME “WdfRequestSend failed with status 0x%08x\n”, status));
status = WdfRequestGetStatus(Request);
}
else {
KdPrint((__DRIVER_NAME “WdfRequestSend succeeded \n”));

KdPrint((__DRIVER_NAME “Send control code\n”));
status = WdfUsbTargetDeviceSendControlTransferSynchronously(
devCtx->UsbDevice,
NULL,
NULL,
&controlPacket,
&memDescriptor,
NULL);

if(!NT_SUCCESS(status))
{
KdPrint((__DRIVER_NAME
“WdfUsbTargetDeviceSendControlTransferSynchronouslyfailed with status 0x%08x\n”,
status));
}
return;
}
WdfRequestComplete(Request, status);
}

//completion routine

VOID
EvtIoReadComplete(
IN WDFREQUEST Request,
IN WDFIOTARGET Target,
IN PWDF_REQUEST_COMPLETION_PARAMS Params,
IN WDFCONTEXT Context)
{

UNREFERENCED_PARAMETER(Context);
UNREFERENCED_PARAMETER(Target);

PWDF_USB_REQUEST_COMPLETION_PARAMS usbCompletionParams;

KdPrint((__DRIVER_NAME “Entering Completion routine\n”));

usbCompletionParams = Params->Parameters.Usb.Completion;
KdPrint((__DRIVER_NAME “USBD_STATUS: 0x%08x\n”,
usbCompletionParams->UsbdStatus));

if(NT_SUCCESS(Params->IoStatus.Status))
{
KdPrint((__DRIVER_NAME “Completed the read request with %d bytes\n”,
usbCompletionParams->Parameters.PipeRead.Length));
}
else
{
KdPrint((__DRIVER_NAME “Failed the read request with status 0x%08x\n”,
Params->IoStatus.Status));
}
WdfRequestCompleteWithInformation(Request,
Params->IoStatus.Status,
usbCompletionParams->Parameters.PipeRead.Length);
}

I hope someone can find the problem.

Best Regards,
Matthias

xxxxx@alumni.tu-berlin.de wrote:

//EvtDeviceD0Entry callback

status = WdfIoTargetStart(WdfUsbTargetPipeGetIoTarget(
devCtx->UsbBulkInPipe));
if(!NT_SUCCESS(status))
{
KdPrint((__DRIVER_NAME
“WdfIoTargetStart failed with status 0x%08x\n”, status));
return status;
}

This shows the danger of cutting and pasting pieces instead of whole
routines. Is the order of the code exactly as you have it here?
Because here, you are fetching UsbBulkInPipe from the device context,
but you don’t create that handle until later on.

// finding the pipes to storage its type inside a DeviceContext struct:

pipe = WdfUsbInterfaceGetConfiguredPipe(DeviceContext->UsbInterface,
index,
&pipeConfig);

You’re sure the index you’re passing is the pipe you want?

WDF_MEMORY_DESCRIPTOR_INIT_HANDLE(&memDescriptor,devCtx->WdfUserCommandMemory, NULL);
//set ControlPaket
KdPrint((__DRIVER_NAME “Generate ControlPaket \n”));//
controlPacket.Generic.Bytes[0] = 0x00;
controlPacket.Generic.Bytes[1] = 0x42;
controlPacket.Generic.Bytes[2] = 0x00;
controlPacket.Generic.Bytes[3] = 0x00;
controlPacket.Generic.Bytes[4] = 0x00;
controlPacket.Generic.Bytes[5] = 0x00;
controlPacket.Generic.Bytes[6] = 0x01;
controlPacket.Generic.Bytes[7] = 0x00;

This is not correct. You’re setting bmRequestType to 00, which means it
is a standard device request, but 0x42 is not a valid standard request.
I suspect you were trying to send a vendor endpoint request, but for
that you need byte 0 to be 0x42, not byte 1. This is why you should use
symbolic names that have meaning:

RtlZeroMemory( &controlPacket, sizeof(controlPacket) );
controlPacket.Packet.bm.Byte = 0x42;
controlPacket.Packet.bRequest = 0;
controlPacket.Packet.wLength = 1;

Are you sure this is the request that the hardware wants? It would be
unusual to have a control request with a one-byte data buffer. After
all, there are 4 bytes of available space in the control packet itself
(wIndex and wValue) that can be used for short requests, like register
writes.


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

Hello Tim,

thank you very much for analyzing my code-fragments. Actually I made a mistake with the control packet ? the first byte should be 0xC0 instead of 0x00. However it is still not working.

Regarding your question about the EvtDeviceD0Entry callback:
The EvtDeviceD0Entry callback I just copied for informational purpose into my message ? it is off course called after the pipes were identified and the queues have been assigned with callbacks.

Regarding your question about the identification of pipes:
According to the manufacture definition there is just one pipe of bulkin- type. I hope that I found the right pipe.

Because I still not got an idea whether either my code is faulty or the USB device is just not sending the expected bytes I would be very happy if you or someone else would tell me, what I could expect to see with my USB monitor (software) if I send a bulkin read request and my device is just not responding with data.
Would I see something like a ?zero bulk transfer? or will simply nothing happen ?

Best Regards,
Matthias

xxxxx@alumni.tu-berlin.de wrote:

thank you very much for analyzing my code-fragments. Actually I made a mistake with the control packet ? the first byte should be 0xC0 instead of 0x00. However it is still not working.

OK, 0xC0 is a vendor-defined request to the device, but that’s a READ
request, not a WRITE request. Again, are you sure?

Regarding your question about the EvtDeviceD0Entry callback:
The EvtDeviceD0Entry callback I just copied for informational purpose into my message ? it is off course called after the pipes were identified and the queues have been assigned with callbacks.

That certainly wasn’t obvious from what you posted. It’s awfully hard
to review your code when you just give us selected snippets and they are
out of order. You’re asking us to use a crystal ball to debug for you.

Regarding your question about the identification of pipes:
According to the manufacture definition there is just one pipe of bulkin- type. I hope that I found the right pipe.

You can use usbview or uvcview to review the actual configuration
descriptor to find out for sure which pipe is first.

Because I still not got an idea whether either my code is faulty or the USB device is just not sending the expected bytes I would be very happy if you or someone else would tell me, what I could expect to see with my USB monitor (software) if I send a bulkin read request and my device is just not responding with data.
Would I see something like a ?zero bulk transfer? or will simply nothing happen ?

With a bulk pipe, the request will be retried forever until either the
device responds or your driver cancels it because of a timeout. If the
device responds with zero bytes of data (which is valid), you’ll get a
normal completion but with zero bytes.

If you’re still seeing STATUS_UNSUCCESSFUL with 0 in the URB status
field, the implication is that it’s failing before it gets to the
device. That’s why I’m suspicious of the ordering.


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

Hi Tim,
I now configured a continuous reader to read the bulkin- pipe. Since this is also not working I manually added an EvtUsbTargetPipeReaderFailed- callback. Interestingly this callback answers only if I send the control packet to initiate bulk transfer (the control code is correct). However the response is not very meaningful (NTSTATUS 0xc0000001 USBD Status 0x00).
This means that the USB device tries to send something to host. However I don?t understand why the completion callback is not called. Here again some code:
NTSTATUS EvtDevicePrepareHardware(
IN WDFDEVICE Device,
IN WDFCMRESLIST ResourceList,
IN WDFCMRESLIST ResourceListTranslated
)
{
/
*
*
*
*
/
WDF_USB_CONTINUOUS_READER_CONFIG BulkinConfig;

WDF_USB_CONTINUOUS_READER_CONFIG_INIT(&BulkinConfig,
UsbPipeReadComplete,
devCtx,
200*sizeof(BYTE));

BulkinConfig.EvtUsbTargetPipeReadersFailed = (PFN_WDF_USB_READERS_FAILED) UsbPipeReadFailed;

status = WdfUsbTargetPipeConfigContinuousReader(
devCtx->UsbBulkInPipe,
&BulkinConfig);
if(!NT_SUCCESS(status))
{
KdPrint((__DRIVER_NAME
“WdfUsbTargetPipeConfigContinuousReader failed with status 0x%08x\n”, status));
return status;
} else KdPrint((__DRIVER_NAME
“WdfUsbTargetPipeConfigContinuousReader configurated\n”));

return status;
}
/* Bulkin Read failed */
VOID
UsbPipeReadFailed(
IN WDFUSBPIPE Pipe,
IN NTSTATUS Status,
IN USBD_STATUS UsbdStatus
)
{
UNREFERENCED_PARAMETER(Pipe);
KdPrint((__DRIVER_NAME “UsbPipeReadFailed NTSTAUS 0x%08x and USBD Status 0x%08x \n”, Status, UsbdStatus));

};
/*…*/
/* Bulkin Contireader completion */
/*…*/
VOID
UsbPipeReadComplete(
IN WDFUSBPIPE Pipe,
IN WDFMEMORY Buffer,
IN size_t NumBytesTransfered,
IN WDFCONTEXT Context
)
{
NTSTATUS status = STATUS_SUCCESS;
WDFREQUEST Request = NULL;
UNREFERENCED_PARAMETER(Pipe);
UNREFERENCED_PARAMETER(Buffer);
UNREFERENCED_PARAMETER(Context);
KdPrint((__DRIVER_NAME “UsbPipeReadComplete called %d \n”, NumBytesTransfered));
WdfRequestComplete(Request, status);
};

I would be very happy, if you or someone else could give a hint or an explanation, why the completion routine is not called.

Best Regards,
Matthias

Hello all,

according to OSR NTDEV Thread: ?Problem in Continuous reader.? I changed the initialization of the continues reader according to the following code:

WdfUsbTargetPipeSetNoMaximumPacketSizeCheck(devCtx->UsbBulkInPipe);

WDF_USB_CONTINUOUS_READER_CONFIG_INIT(&BulkinConfig,
UsbPipeReadComplete,
devCtx,
1024*sizeof(BYTE));

BulkinConfig.EvtUsbTargetPipeReadersFailed = (PFN_WDF_USB_READERS_FAILED) UsbPipeReadFailed;

//BulkinConfig.HeaderLength = 200*sizeof(BYTE);
//BulkinConfig.TrailerLength = 200*sizeof(BYTE);
BulkinConfig.NumPendingReads = 2;
//Readout
KdPrint((__DRIVER_NAME “WDF_USB_CONTINUOUS_READER_CONFIG Params \n”));
KdPrint((__DRIVER_NAME “Size: %d, \n”, BulkinConfig.Size));
KdPrint((__DRIVER_NAME “TransferLength: %d, \n”, BulkinConfig.TransferLength));
KdPrint((__DRIVER_NAME “HeaderLength: %d, \n”, BulkinConfig.HeaderLength));
KdPrint((__DRIVER_NAME “TrailerLength: %d, \n”, BulkinConfig.TrailerLength));
KdPrint((__DRIVER_NAME “NumPendingReads: %d, \n”, BulkinConfig.NumPendingReads));

status = WdfUsbTargetPipeConfigContinuousReader(
devCtx->UsbBulkInPipe,
&BulkinConfig);
if(!NT_SUCCESS(status))
{
KdPrint((__DRIVER_NAME
“WdfUsbTargetPipeConfigContinuousReader failed with status 0x%08x\n”, status));
return status;
} else KdPrint((__DRIVER_NAME
“WdfUsbTargetPipeConfigContinuousReader configurated\n”));

If I now send all control packets to initialize bulk transfer from my USB device I get a BSOD.
(I am pretty sure that my control packets are not causing the bsod)
!analyze ?v report

WDF_VIOLATION (10d)
The Kernel-Mode Driver Framework was notified that Windows detected an error
in a framework-based driver. In general, the dump file will yield additional
information about the driver that caused this bug check.
Arguments:
Arg1: 00000005, A framework object handle of the incorrect type was passed to
a framework object method.
Arg2: 00000000, The handle value passed in.
Arg3: 00001008, Reserved.
Arg4: 81f41f10, Reserved.

Debugging Details:

SYMSRV: d:\DebugSymbols\Wdf01000.sys\438E21BE76000\Wdf01000.sys not found
SYMSRV: http://msdl.microsoft.com/download/symbols/Wdf01000.sys/438E21BE76000/Wdf01000.sys not found

BUGCHECK_STR: 0x10D_5

CUSTOMER_CRASH_COUNT: 5

DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT

PROCESS_NAME: Idle

LAST_CONTROL_TRANSFER: from f7e6c806 to 80533806

STACK_TEXT:
80550c68 f7e6c806 0000010d 00000005 00000000 nt!KeBugCheckEx+0x1b
WARNING: Stack unwind information not available. Following frames may be wrong.
80550c84 f7e63205 81f41f10 00000005 00000000 Wdf01000+0x27806
80550cb0 f7e5ba87 81f41f10 00000000 00000000 Wdf01000+0x1e205
80550cd8 f893e5aa 81f41fd0 00000000 c000000d Wdf01000+0x16a87
80550cec f893fd9b 00000000 c000000d c000000d wdf_usb+0x5aa
80550d04 f7e56a5e 7de38640 7e0d68b8 00000400 wdf_usb+0x1d9b
80550d34 f7e77196 7e8d69d8 7de38640 821c945c Wdf01000+0x11a5e
80550d5c f7e4f956 81ec52b3 821c79b8 00000000 Wdf01000+0x32196
80550d7c f7e4fa10 7e8d69d8 82168e78 80550da8 Wdf01000+0xa956
80550d8c 8050bf61 00000000 81ec51f8 81729620 Wdf01000+0xaa10
80550da8 804e3d38 00000000 81ec51f8 82168e78 nt!IopUnloadSafeCompletion+0x1d
80550dd8 f80f30d5 81ec51f8 8219e008 8227c028 nt!IopfCompleteRequest+0xa2
80550e40 f80f3d47 821c94a4 00000000 8227c7d8 USBPORT!USBPORT_CompleteTransfer+0x373
80550e70 f80f4944 026e6f44 8227c0e0 8227c0e0 USBPORT!USBPORT_DoneTransfer+0x137
80550ea8 f80f613a 8227c028 804e2eb4 8227c230 USBPORT!USBPORT_FlushDoneTransferList+0x16c
80550ed4 f810424b 8227c028 804e2eb4 8227c028 USBPORT!USBPORT_DpcWorker+0x224
80550f10 f81043c2 8227c028 00000001 80559c20 USBPORT!USBPORT_IsrDpcWorker+0x38f
80550f2c 804dbbd4 8227c64c 6b755044 00000000 USBPORT!USBPORT_IsrDpc+0x166
80550f40 805599c0 ffdffc50 00000000 00000000 nt!KiRetireDpcList+0x46
80550f50 804dbb4d 00000000 0000000e 00000000 nt!KiIdleThread0
80550f54 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x26

STACK_COMMAND: kb

FOLLOWUP_IP:
wdf_usb+5aa
f893e5aa ?? ???

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: wdf_usb+5aa

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: wdf_usb

IMAGE_NAME: wdf_usb.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 50eb11c3

FAILURE_BUCKET_ID: 0x10D_5_wdf_usb+5aa

BUCKET_ID: 0x10D_5_wdf_usb+5aa

Followup: MachineOwner

1 fix your os symbols
2 read the output, it CLEARLY shows you what is wrong

Arg2: 00000000, The handle value passed in.

Null is not a valid handle value

d

Bent from my phone


From: xxxxx@alumni.tu-berlin.demailto:xxxxx
Sent: ?4/?27/?2013 1:35 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] BulkInPipe Read Request -> 0xc0000001

Hello all,

according to OSR NTDEV Thread: ?Problem in Continuous reader.? I changed the initialization of the continues reader according to the following code:

WdfUsbTargetPipeSetNoMaximumPacketSizeCheck(devCtx->UsbBulkInPipe);

WDF_USB_CONTINUOUS_READER_CONFIG_INIT(&BulkinConfig,
UsbPipeReadComplete,
devCtx,
1024sizeof(BYTE));

BulkinConfig.EvtUsbTargetPipeReadersFailed = (PFN_WDF_USB_READERS_FAILED) UsbPipeReadFailed;

//BulkinConfig.HeaderLength = 200
sizeof(BYTE);
//BulkinConfig.TrailerLength = 200*sizeof(BYTE);
BulkinConfig.NumPendingReads = 2;
//Readout
KdPrint((__DRIVER_NAME “WDF_USB_CONTINUOUS_READER_CONFIG Params \n”));
KdPrint((__DRIVER_NAME “Size: %d, \n”, BulkinConfig.Size));
KdPrint((__DRIVER_NAME “TransferLength: %d, \n”, BulkinConfig.TransferLength));
KdPrint((__DRIVER_NAME “HeaderLength: %d, \n”, BulkinConfig.HeaderLength));
KdPrint((__DRIVER_NAME “TrailerLength: %d, \n”, BulkinConfig.TrailerLength));
KdPrint((__DRIVER_NAME “NumPendingReads: %d, \n”, BulkinConfig.NumPendingReads));

status = WdfUsbTargetPipeConfigContinuousReader(
devCtx->UsbBulkInPipe,
&BulkinConfig);
if(!NT_SUCCESS(status))
{
KdPrint((__DRIVER_NAME
“WdfUsbTargetPipeConfigContinuousReader failed with status 0x%08x\n”, status));
return status;
} else KdPrint((__DRIVER_NAME
“WdfUsbTargetPipeConfigContinuousReader configurated\n”));

If I now send all control packets to initialize bulk transfer from my USB device I get a BSOD.
(I am pretty sure that my control packets are not causing the bsod)
!analyze ?v report

WDF_VIOLATION (10d)
The Kernel-Mode Driver Framework was notified that Windows detected an error
in a framework-based driver. In general, the dump file will yield additional
information about the driver that caused this bug check.
Arguments:
Arg1: 00000005, A framework object handle of the incorrect type was passed to
a framework object method.
Arg2: 00000000, The handle value passed in.
Arg3: 00001008, Reserved.
Arg4: 81f41f10, Reserved.

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

SYMSRV: d:\DebugSymbols\Wdf01000.sys\438E21BE76000\Wdf01000.sys not found
SYMSRV: http://msdl.microsoft.com/download/symbols/Wdf01000.sys/438E21BE76000/Wdf01000.sys not found

BUGCHECK_STR: 0x10D_5

CUSTOMER_CRASH_COUNT: 5

DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT

PROCESS_NAME: Idle

LAST_CONTROL_TRANSFER: from f7e6c806 to 80533806

STACK_TEXT:
80550c68 f7e6c806 0000010d 00000005 00000000 nt!KeBugCheckEx+0x1b
WARNING: Stack unwind information not available. Following frames may be wrong.
80550c84 f7e63205 81f41f10 00000005 00000000 Wdf01000+0x27806
80550cb0 f7e5ba87 81f41f10 00000000 00000000 Wdf01000+0x1e205
80550cd8 f893e5aa 81f41fd0 00000000 c000000d Wdf01000+0x16a87
80550cec f893fd9b 00000000 c000000d c000000d wdf_usb+0x5aa
80550d04 f7e56a5e 7de38640 7e0d68b8 00000400 wdf_usb+0x1d9b
80550d34 f7e77196 7e8d69d8 7de38640 821c945c Wdf01000+0x11a5e
80550d5c f7e4f956 81ec52b3 821c79b8 00000000 Wdf01000+0x32196
80550d7c f7e4fa10 7e8d69d8 82168e78 80550da8 Wdf01000+0xa956
80550d8c 8050bf61 00000000 81ec51f8 81729620 Wdf01000+0xaa10
80550da8 804e3d38 00000000 81ec51f8 82168e78 nt!IopUnloadSafeCompletion+0x1d
80550dd8 f80f30d5 81ec51f8 8219e008 8227c028 nt!IopfCompleteRequest+0xa2
80550e40 f80f3d47 821c94a4 00000000 8227c7d8 USBPORT!USBPORT_CompleteTransfer+0x373
80550e70 f80f4944 026e6f44 8227c0e0 8227c0e0 USBPORT!USBPORT_DoneTransfer+0x137
80550ea8 f80f613a 8227c028 804e2eb4 8227c230 USBPORT!USBPORT_FlushDoneTransferList+0x16c
80550ed4 f810424b 8227c028 804e2eb4 8227c028 USBPORT!USBPORT_DpcWorker+0x224
80550f10 f81043c2 8227c028 00000001 80559c20 USBPORT!USBPORT_IsrDpcWorker+0x38f
80550f2c 804dbbd4 8227c64c 6b755044 00000000 USBPORT!USBPORT_IsrDpc+0x166
80550f40 805599c0 ffdffc50 00000000 00000000 nt!KiRetireDpcList+0x46
80550f50 804dbb4d 00000000 0000000e 00000000 nt!KiIdleThread0
80550f54 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x26

STACK_COMMAND: kb

FOLLOWUP_IP:
wdf_usb+5aa
f893e5aa ?? ???

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: wdf_usb+5aa

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: wdf_usb

IMAGE_NAME: wdf_usb.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 50eb11c3

FAILURE_BUCKET_ID: 0x10D_5_wdf_usb+5aa

BUCKET_ID: 0x10D_5_wdf_usb+5aa

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


NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

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</mailto:xxxxx></mailto:xxxxx>

Hi Doron
Thank you - I gas it would help to know which framework object handle of the incorrect type was passed to which framework object method.

Can you give a hint how to fix “os ? symbols” ? I already checked this (http://forums.whirlpool.net.au/archive/1859765) but !symfix does not change my readout.

Best Regards,
Matthias

Try .symfix. then .symnoisy to see why symbols are not matching in case you are not getting matches

I gas it would help to know which framework object handle of the incorrect type was passed to which framework object method.

You passed a NULL handle, so it is not as if you passed the wrong type of value. You passed no handle at all. As for which DDI you called, no idea until you fix your symbols.

As always (once you fix your symbols)

!wdfkd.wdflogump wdf_usb

Will tell you what went wrong

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@alumni.tu-berlin.de
Sent: Saturday, April 27, 2013 3:42 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] BulkInPipe Read Request -> 0xc0000001

Hi Doron
Thank you - I gas it would help to know which framework object handle of the incorrect type was passed to which framework object method.

Can you give a hint how to fix “os ? symbols” ? I already checked this (http://forums.whirlpool.net.au/archive/1859765) but !symfix does not change my readout.

Best Regards,
Matthias


NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

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

Hi Doron,

I got some of the os-symbols fixed ? looks like that a WdfRequestComplete call has caused the bsod.

Best Regards,
Matthias

DF_VIOLATION (10d)
The Kernel-Mode Driver Framework was notified that Windows detected an error
in a framework-based driver. In general, the dump file will yield additional
information about the driver that caused this bug check.
Arguments:
Arg1: 00000005, A framework object handle of the incorrect type was passed to
a framework object method.
Arg2: 00000000, The handle value passed in.
Arg3: 00001008, Reserved.
Arg4: 81f41f10, Reserved.

Debugging Details:

BUGCHECK_STR: 0x10D_5

CUSTOMER_CRASH_COUNT: 5

DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT

PROCESS_NAME: Idle

LAST_CONTROL_TRANSFER: from f7e6c806 to 80533806

STACK_TEXT:
80550c68 f7e6c806 0000010d 00000005 00000000 nt!KeBugCheckEx+0x1b
80550c84 f7e63205 81f41f10 00000005 00000000 Wdf01000!FxVerifierBugCheck+0x24
80550cb0 f7e5ba87 81f41f10 00000000 00000000 Wdf01000!FxObjectHandleGetPtr+0x7d
80550cd8 f893e5aa 81f41fd0 00000000 c000000d Wdf01000!imp_WdfRequestComplete+0x25
WARNING: Stack unwind information not available. Following frames may be wrong.
80550cec f893fd9b 00000000 c000000d c000000d wdf_usb+0x5aa
80550d04 f7e56a5e 7de38640 7e0d68b8 00000400 wdf_usb+0x1d9b
80550d34 f7e77196 7e8d69d8 7de38640 821c945c Wdf01000!FxUsbPipeContinuousReader::_FxUsbPipeRequestComplete+0x3e
80550d5c f7e4f956 81ec52b3 821c79b8 00000000 Wdf01000!FxRequestBase::CompleteSubmitted+0x89
80550d7c f7e4fa10 7e8d69d8 82168e78 80550da8 Wdf01000!FxIoTarget::RequestCompletionRoutine+0x1bd
80550d8c 8050bf61 00000000 81ec51f8 81729620 Wdf01000!FxIoTarget::_RequestCompletionRoutine+0x35
80550da8 804e3d38 00000000 81ec51f8 82168e78 nt!IopUnloadSafeCompletion+0x1d
80550dd8 f80f30d5 81ec51f8 8219e008 8227c028 nt!IopfCompleteRequest+0xa2
80550e40 f80f3d47 821c94a4 00000000 8227c7d8 USBPORT!USBPORT_CompleteTransfer+0x373
80550e70 f80f4944 026e6f44 8227c0e0 8227c0e0 USBPORT!USBPORT_DoneTransfer+0x137
80550ea8 f80f613a 8227c028 804e2eb4 8227c230 USBPORT!USBPORT_FlushDoneTransferList+0x16c
80550ed4 f810424b 8227c028 804e2eb4 8227c028 USBPORT!USBPORT_DpcWorker+0x224
80550f10 f81043c2 8227c028 00000001 80559c20 USBPORT!USBPORT_IsrDpcWorker+0x38f
80550f2c 804dbbd4 8227c64c 6b755044 00000000 USBPORT!USBPORT_IsrDpc+0x166
80550f40 805599c0 ffdffc50 00000000 00000000 nt!KiRetireDpcList+0x46
80550f50 804dbb4d 00000000 0000000e 00000000 nt!KiIdleThread0
80550f54 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x26

STACK_COMMAND: kb

FOLLOWUP_IP:
wdf_usb+5aa
f893e5aa ?? ???

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: wdf_usb+5aa

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: wdf_usb

IMAGE_NAME: wdf_usb.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 50eb11c3

FAILURE_BUCKET_ID: 0x10D_5_wdf_usb+5aa

BUCKET_ID: 0x10D_5_wdf_usb+5aa

Followup: MachineOwner

To repeat

Arg2: 00000000, The handle value passed in.

You are passing null, it is a bug in your code. Figure out why you are passing null

d

Bent from my phone


From: xxxxx@alumni.tu-berlin.demailto:xxxxx
Sent: ?4/?28/?2013 8:03 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] BulkInPipe Read Request -> 0xc0000001

Hi Doron,

I got some of the os-symbols fixed ? looks like that a WdfRequestComplete call has caused the bsod.

Best Regards,
Matthias

DF_VIOLATION (10d)
The Kernel-Mode Driver Framework was notified that Windows detected an error
in a framework-based driver. In general, the dump file will yield additional
information about the driver that caused this bug check.
Arguments:
Arg1: 00000005, A framework object handle of the incorrect type was passed to
a framework object method.
Arg2: 00000000, The handle value passed in.
Arg3: 00001008, Reserved.
Arg4: 81f41f10, Reserved.

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

BUGCHECK_STR: 0x10D_5

CUSTOMER_CRASH_COUNT: 5

DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT

PROCESS_NAME: Idle

LAST_CONTROL_TRANSFER: from f7e6c806 to 80533806

STACK_TEXT:
80550c68 f7e6c806 0000010d 00000005 00000000 nt!KeBugCheckEx+0x1b
80550c84 f7e63205 81f41f10 00000005 00000000 Wdf01000!FxVerifierBugCheck+0x24
80550cb0 f7e5ba87 81f41f10 00000000 00000000 Wdf01000!FxObjectHandleGetPtr+0x7d
80550cd8 f893e5aa 81f41fd0 00000000 c000000d Wdf01000!imp_WdfRequestComplete+0x25
WARNING: Stack unwind information not available. Following frames may be wrong.
80550cec f893fd9b 00000000 c000000d c000000d wdf_usb+0x5aa
80550d04 f7e56a5e 7de38640 7e0d68b8 00000400 wdf_usb+0x1d9b
80550d34 f7e77196 7e8d69d8 7de38640 821c945c Wdf01000!FxUsbPipeContinuousReader::_FxUsbPipeRequestComplete+0x3e
80550d5c f7e4f956 81ec52b3 821c79b8 00000000 Wdf01000!FxRequestBase::CompleteSubmitted+0x89
80550d7c f7e4fa10 7e8d69d8 82168e78 80550da8 Wdf01000!FxIoTarget::RequestCompletionRoutine+0x1bd
80550d8c 8050bf61 00000000 81ec51f8 81729620 Wdf01000!FxIoTarget::_RequestCompletionRoutine+0x35
80550da8 804e3d38 00000000 81ec51f8 82168e78 nt!IopUnloadSafeCompletion+0x1d
80550dd8 f80f30d5 81ec51f8 8219e008 8227c028 nt!IopfCompleteRequest+0xa2
80550e40 f80f3d47 821c94a4 00000000 8227c7d8 USBPORT!USBPORT_CompleteTransfer+0x373
80550e70 f80f4944 026e6f44 8227c0e0 8227c0e0 USBPORT!USBPORT_DoneTransfer+0x137
80550ea8 f80f613a 8227c028 804e2eb4 8227c230 USBPORT!USBPORT_FlushDoneTransferList+0x16c
80550ed4 f810424b 8227c028 804e2eb4 8227c028 USBPORT!USBPORT_DpcWorker+0x224
80550f10 f81043c2 8227c028 00000001 80559c20 USBPORT!USBPORT_IsrDpcWorker+0x38f
80550f2c 804dbbd4 8227c64c 6b755044 00000000 USBPORT!USBPORT_IsrDpc+0x166
80550f40 805599c0 ffdffc50 00000000 00000000 nt!KiRetireDpcList+0x46
80550f50 804dbb4d 00000000 0000000e 00000000 nt!KiIdleThread0
80550f54 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x26

STACK_COMMAND: kb

FOLLOWUP_IP:
wdf_usb+5aa
f893e5aa ?? ???

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: wdf_usb+5aa

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: wdf_usb

IMAGE_NAME: wdf_usb.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 50eb11c3

FAILURE_BUCKET_ID: 0x10D_5_wdf_usb+5aa

BUCKET_ID: 0x10D_5_wdf_usb+5aa

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


NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

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</mailto:xxxxx></mailto:xxxxx>

xxxxx@alumni.tu-berlin.de wrote:

I got some of the os-symbols fixed ? looks like that a WdfRequestComplete call has caused the bsod.

You’re wasting a lot of time here asking questions that no one here can
answer, because we don’t have access to your source code. You have
shown us a few bits and pieces, but nothing in a big enough chunks to
learn whether your overall approach is correct.

Please be assured that the APIs work. YOU are doing something wrong.

I believe I offered to look over your source code if you send me a link
to it by private email.


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

xxxxx@alumni.tu-berlin.de wrote:

/*…*/
/* Bulkin Contireader completion */
/*…*/
VOID
UsbPipeReadComplete(
IN WDFUSBPIPE Pipe,
IN WDFMEMORY Buffer,
IN size_t NumBytesTransfered,
IN WDFCONTEXT Context
)
{
NTSTATUS status = STATUS_SUCCESS;
WDFREQUEST Request = NULL;
UNREFERENCED_PARAMETER(Pipe);
UNREFERENCED_PARAMETER(Buffer);
UNREFERENCED_PARAMETER(Context);
KdPrint((__DRIVER_NAME “UsbPipeReadComplete called %d \n”, NumBytesTransfered));
WdfRequestComplete(Request, status);
};

I would be very happy, if you or someone else could give a hint or an explanation, why the completion routine is not called.

Is it possible that you really do not see the problem in this code? Let
me ask you this. What value are you passing to WdfRequestComplete here?


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

Ok WdfRequestComlete gets a zero handle and is causing the problem ? I deleted it and now I can receive the expected data (I can see them with my USB monitor) - just for the case that someone wants to see the relevant positions and what exactly I have deleted:

/*…*/
/* Bulkin Contireader completion */
/*…*/
VOID
UsbPipeReadComplete(
IN WDFUSBPIPE Pipe,
IN WDFMEMORY Buffer,
IN size_t NumBytesTransfered,
IN WDFCONTEXT Context
)
{

NTSTATUS status = STATUS_SUCCESS;
WDFREQUEST Request = NULL; //<–here the handle get’s charged with 0x00000000

UNREFERENCED_PARAMETER(Pipe);
UNREFERENCED_PARAMETER(Buffer);
UNREFERENCED_PARAMETER(Context);
KdPrint((__DRIVER_NAME “UsbPipeReadComplete called %d \n”,
NumBytesTransfered));
WdfRequestComplete(Request, status); //<----- …and here the function wdfcompletion gets the
// handle passed which then causes the bsod -

};

@Tim
Sorry my code is full of experimental routines which are mostly useless (and senseless) ? I want not bother the forum with 30 pages of mostly senseless code. So I tried to extract the relevant pieces ? however since I am beginner it could be that I forget some relevant stuff. Next time I will have a more professional looking code which I can post here.

Do you know a nice code example which shows how to get data from bulkin-reader-completion-routine into user mode ?

Thank you very much,
Best Regards,
Matthias

@Tim I didn?t saw your message before I posted my message.
I saw it after analyzing the bsod ? however I agree that was much too late.

Best Regards,
Matthias

xxxxx@alumni.tu-berlin.de wrote:

Next time I will have a more professional looking code which I can post here.

I was going to say that we don’t assign letter grades to the code that
gets posted, but realistically, I guess we kind of do that.

Do you know a nice code example which shows how to get data from bulkin-reader-completion-routine into user mode ?

There’s not much to it. Your user-mode application would already have
submitted a request that you’re holding in a manual queue. In your
completion routine, you go pull the next request from that queue, copy
the data, and complete the request.

However, if that’s all you want to do, then why would you write a driver
at all? If you just need control requests and bulk requests, throw out
your driver and use WinUSB. There is NO REASON to write a kernel-mode
USB driver any more unless you need isochronous pipes, or unless you
need to expose a standard device class.


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

Hi,
just for the case that someone is interested in code examples on how to get data from a continuous reader into the user space ? here are the relevant routines (attached). From my point of view my original question on the NTSTATUS 0xc0000001 message in case of a read request can be answered that if the microcontroller of the usb device sends continuously data into the bulkin pipe then the host has to offer a continues reader because otherwise it would generate the error message 0xc0000001.
Best Regards,
Matthias

//WDFQUEUE BulkinReadRequestsQueue;//must be included into the device context structure
// WDFUSBPIPE UsbInterruptPipe; //must be included into the device context structure

//EvtDevicePrepareHardware
WdfUsbTargetPipeSetNoMaximumPacketSizeCheck(devCtx->UsbBulkInPipe);
WDF_USB_CONTINUOUS_READER_CONFIG_INIT(&BulkinConfig,
&UsbPipeReadComplete,
devCtx,
1024*sizeof(BYTE)); // <- this has to be multiple times larger than the expected packet size ? I expected 200 bytes and got only in the case of 1024 bytes a call of the BulkInContireader completion routine

BulkinConfig.EvtUsbTargetPipeReadersFailed = (PFN_WDF_USB_READERS_FAILED) UsbPipeReadFailed;
BulkinConfig.NumPendingReads = 2; // this is by default = 0;
status = WdfUsbTargetPipeConfigContinuousReader(
devCtx->UsbBulkInPipe,
&BulkinConfig);
if(!NT_SUCCESS(status))
{
KdPrint((__DRIVER_NAME
“WdfUsbTargetPipeConfigContinuousReader failed with status 0x%08x\n”, status));
return status;
} else KdPrint((__DRIVER_NAME
“WdfUsbTargetPipeConfigContinuousReader ready \n”));

//CreateQueue
WDF_IO_QUEUE_CONFIG_INIT(&ioQConfig,
WdfIoQueueDispatchManual); // this is the ?manual queue? Tim was speaking about

status = WdfIoQueueCreate(Device,
&ioQConfig,
WDF_NO_OBJECT_ATTRIBUTES,
&Context->BulkinReadRequestsQueue);
if(!NT_SUCCESS(status))
{
KdPrint((__DRIVER_NAME
“WdfIoQueueCreate for manual queue failed with status 0x%08x\n”, status));
return status;
}

//IOCTL routine which is called from user space via DeviceIoControl
VOID
IoCtlGetUSBBulkinData(
IN WDFQUEUE Queue,
IN WDFREQUEST Request,
IN size_t OutputBufferLength,
IN size_t InputBufferLength
)

{

NTSTATUS status = STATUS_SUCCESS;
PDEVICE_CONTEXT devCtx = NULL;
UNREFERENCED_PARAMETER(InputBufferLength);
UNREFERENCED_PARAMETER(OutputBufferLength);

devCtx = GetDeviceContext(WdfIoQueueGetDevice(Queue));
status = WdfRequestForwardToIoQueue(Request,
devCtx->BulkinReadRequestsQueue); //this pushes a IO request into the quese that contains appropriate buffer space that were set DeviceIoControl inside the user space

if(!NT_SUCCESS(status))
{
KdPrint((__DRIVER_NAME
“WdfRequestForwardToIoQueue failed with code 0x%08x.\n”, status));
WdfRequestComplete(Request, status);
}
Else KdPrint((__DRIVER_NAME
“Request fired.\n”));

};

// BulkInContireader completion
VOID
UsbPipeReadComplete(
IN WDFUSBPIPE Pipe,
IN WDFMEMORY Buffer,
IN size_t NumBytesTransfered,
IN WDFCONTEXT Context
)
{
NTSTATUS status = STATUS_SUCCESS;
WDFMEMORY outputMemory = NULL;
BYTE *inBuffer = NULL;
size_t in_size = 0;

PDEVICE_CONTEXT devCtx = Context;
WDFREQUEST Request = NULL;
UNREFERENCED_PARAMETER(Pipe);

// get eventually a request from BulkinReadRequestsQueue ? which would be there if the user mode has previously called IoCtlGetUSBBulkinData via a DeviceIoControl call.

status = WdfIoQueueRetrieveNextRequest(devCtx->BulkinReadRequestsQueue, &Request);
if(NT_SUCCESS(status))
{
KdPrint((__DRIVER_NAME
“Got a Request\n”));
//get the user mode memory
status = WdfRequestRetrieveOutputMemory(Request, &outputMemory);
if(!NT_SUCCESS(status))
{
KdPrint((__DRIVER_NAME
“WdfRequestRetrieveOutputMemory failed with status 0x%08x\n”, status));

} //if
else {

//get the inBuffer pointer for the data packet which was recently send via bulkin

inBuffer = WdfMemoryGetBuffer(Buffer, &in_size);

//check whether the user mode has selected the right buffer size

if(in_size == NumBytesTransfered) {
// copy and paste the data packet from bulkin into the user mode memory
status = WdfMemoryCopyFromBuffer(outputMemory, 0, inBuffer, NumBytesTransfered);
if(!NT_SUCCESS(status))
{
KdPrint((__DRIVER_NAME
“WdfMemoryCopyFromBuffer failed with status 0x%08x\n”, status));

} //if
}// if
else KdPrint((__DRIVER_NAME “in_size != NumBytesTransfered\n”, status));

KdPrint((__DRIVER_NAME “Bytes Copied %d \n”, in_size));

WdfRequestCompleteWithInformation(Request, status, in_size*sizeof(BYTE));
} //else

} //if

return;

// Bulkin Read failed
BOOLEAN
UsbPipeReadFailed(
IN WDFUSBPIPE Pipe,
IN NTSTATUS Status,
IN USBD_STATUS UsbdStatus
)
{
UNREFERENCED_PARAMETER(Pipe);
//send a kd message
KdPrint((__DRIVER_NAME “UsbPipeReadFailed NTSTAUS 0x%08x and USBD Status 0x%08x \n”, Status, UsbdStatus));
return TRUE;
};