Break instruction exception 80000003 - when verifier on

Hi All,

I am getting this exception in my USB-SERIAL KMDF driver, when I tried to read from certain "Vendor commands" and when VERIFIER is on.

Strange, this issue is not coming if verifier is disabled.


WARNING: This break is not a step/trace completion.
The last command has been cleared to prevent
accidental continuation of this unrelated event.
Check the event, location and thread before resuming.
Break instruction exception - code 80000003 (first chance)
nt!DbgBreakPoint:

It is occurring @ WdfUsbTargetDeviceSendControlTransferSynchronously
Initially I thought, it because of "pData" being passed directly to "WDF_MEMORY_DESCRIPTOR_INIT_BUFFER".
I am now using memoryHandle instead. Still this keeps occurring.

Any additional processing required to overcome this?

Below is code part which is causing the exception:

STSTATUS
Usb_GetVendor(
IN PDEVICE_EXTENSION deviceExtension,
IN UCHAR request,
IN USHORT value,
OUT PULONG length,
OUT PVOID pData
)
{
NTSTATUS ntStatus = STATUS_SUCCESS;
PURB urb;
ULONG siz = 0;
UCHAR ChannelNumber;
WDFMEMORY wdfUrbHandle;
ULONG nbytes;
WDF_USB_CONTROL_SETUP_PACKET controlSetupPacket;
WDF_MEMORY_DESCRIPTOR memoryDesc;
WDF_OBJECT_ATTRIBUTES objectAttribs;
WDF_REQUEST_SEND_OPTIONS sendOptions;
WDFMEMORY memoryHandle = NULL;

WDF_OBJECT_ATTRIBUTES_INIT(&objectAttribs);
objectAttribs.ParentObject = deviceExtension->UsbDevice;

WDF_REQUEST_SEND_OPTIONS_INIT(&sendOptions,
WDF_REQUEST_SEND_OPTION_TIMEOUT
);

WDF_REQUEST_SEND_OPTIONS_SET_TIMEOUT(&sendOptions,
(5 * -1 * WDF_TIMEOUT_TO_SEC)
);

switch(request) {
case IOCTL_SER_GET_BAUDRATE: siz = sizeof(SERIAL_BAUD_RATE);
break;
case IOCTL_SER_GET_MDMSTS: siz = 1; //sizeof(ULONG);
break;
case IOCTL_SER_GET_LINE_CTL: siz = 2; //sizeof(SERIAL_LINE_CONTROL);
break;
case IOCTL_SER_GET_CHARS: siz = sizeof(SERIAL_CHARS);
break;
case IOCTL_SER_GET_FLOW: siz = sizeof(SERIAL_HANDFLOW); //0x10
break;
default:
ntStatus = STATUS_INVALID_PARAMETER;
return ntStatus;

}

ntStatus = WdfMemoryCreate(NULL,
NonPagedPool,
POOL_TAG,
siz,
&memoryHandle,
NULL);
if (!NT_SUCCESS(ntStatus)) {
return ntStatus;
}

WDF_USB_CONTROL_SETUP_PACKET_INIT_VENDOR(
&controlSetupPacket,
BmRequestDeviceToHost,
BmRequestToDevice,
request,
value,
0
);

//WDF_MEMORY_DESCRIPTOR_INIT_BUFFER(
WDF_MEMORY_DESCRIPTOR_INIT_HANDLE(
&memoryDesc,
memoryHandle,
NULL
);

ntStatus = WdfUsbTargetDeviceSendControlTransferSynchronously(deviceExtension->UsbDevice,
WDF_NO_HANDLE,//NULL,
&sendOptions,
&controlSetupPacket,
&memoryDesc,
&nbytes
);
if (!NT_SUCCESS(ntStatus)) {
DbgPrint("WdfIoTargetSendInternalIoctlSynchronously Request=0x%x Value=0x%x Status=0x%x \n", request, value, ntStatus);
WdfObjectDelete(memoryHandle);
return ntStatus;
}

if(siz && nbytes)
RtlCopyMemory(pData, memoryHandle, siz);

WdfObjectDelete(memoryHandle);
DbgPrint("exit Usb_GetVendor Request=0x%x Value=0x%x Status=0x%x \n", request, value, ntStatus);
return ntStatus;
}

here is logdump

kd> !wdflogdump VUSBPP.sys
Trace searchpath is:

Trace format prefix is: %7!u!: %!FUNC! -
TMF file used for formatting log is: d:\WinDDK\7600.16385.1\tools\tracing\i386\wdf01009.tmf
Log at 81e7c000
Gather log: Please wait, this may take a moment (reading 4032 bytes).
% read so far … 10, 20, 30, 100
There are 35 log entries
— start of log —
1: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a lock order defined in fx\inc\FxVerifierLock.hpp
2: FxVerifierLock::InitializeLockOrder - Object Type 0x1036 does not have a lock order defined in fx\inc\FxVerifierLock.hpp
3: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7DF07FE0 !devobj 0x820392A0 entering PnP State WdfDevStatePnpInit from WdfDevStatePnpObjectCreated
4: FxPkgPnp::Dispatch - WDFDEVICE 0x7DF07FE0 !devobj 0x820392A0, IRP_MJ_PNP, 0x00000000(IRP_MN_START_DEVICE) IRP 0x829F0E90
5: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7DF07FE0 !devobj 0x820392A0 entering PnP State WdfDevStatePnpInitStarting from WdfDevStatePnpInit
6: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7DF07FE0 !devobj 0x820392A0 entering PnP State WdfDevStatePnpHardwareAvailable from WdfDevStatePnpInitStarting
7: FxVerifierLock::InitializeLockOrder - Object Type 0x1204 does not have a lock order defined in fx\inc\FxVerifierLock.hpp
8: FxIoTarget::SubmitLocked - ignoring WDFIOTARGET 7E21E568 state, sending WDFREQUEST F88F6608, state WdfIoTargetStarted
9: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7DF07FE0 !devobj 0x820392A0 entering power policy state WdfDevStatePwrPolStarting from WdfDevStatePwrPolObjectCreated
10: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7DF07FE0 !devobj 0x820392A0 entering power idle state FxIdleStarted from FxIdleStopped
11: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7DF07FE0 !devobj 0x820392A0 entering Power State WdfDevStatePowerStartingCheckDeviceType from WdfDevStatePowerObjectCreated
12: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7DF07FE0 !devobj 0x820392A0 entering Power State WdfDevStatePowerD0Starting from WdfDevStatePowerStartingCheckDeviceType
13: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7DF07FE0 !devobj 0x820392A0 entering Power State WdfDevStatePowerD0StartingConnectInterrupt from WdfDevStatePowerD0Starting
14: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7DF07FE0 !devobj 0x820392A0 entering Power State WdfDevStatePowerD0StartingDmaEnable from WdfDevStatePowerD0StartingConnectInterrupt
15: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7DF07FE0 !devobj 0x820392A0 entering Power State WdfDevStatePowerD0StartingStartSelfManagedIo from WdfDevStatePowerD0StartingDmaEnable
16: FxPkgIo::ResumeProcessingForPower - Power resume all queues of WDFDEVICE 0x7DF07FE0
17: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7DF07FE0 !devobj 0x820392A0 entering power idle state FxIdleStartedPowerUp from FxIdleStarted
18: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7DF07FE0 !devobj 0x820392A0 entering power idle state FxIdleDisabled from FxIdleStartedPowerUp
19: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7DF07FE0 !devobj 0x820392A0 entering Power State WdfDevStatePowerDecideD0State from WdfDevStatePowerD0StartingStartSelfManagedIo
20: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7DF07FE0 !devobj 0x820392A0 entering Power State WdfDevStatePowerD0 from WdfDevStatePowerDecideD0State
21: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7DF07FE0 !devobj 0x820392A0 entering power policy state WdfDevStatePwrPolStartingSucceeded from WdfDevStatePwrPolStarting
22: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7DF07FE0 !devobj 0x820392A0 entering power policy state WdfDevStatePwrPolStartingDecideS0Wake from WdfDevStatePwrPolStartingSucceeded
23: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x7DF07FE0 !devobj 0x820392A0 entering power policy state WdfDevStatePwrPolStarted from WdfDevStatePwrPolStartingDecideS0Wake
24: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x7DF07FE0 !devobj 0x820392A0 entering power idle state FxIdleDisabled from FxIdleDisabled
25: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7DF07FE0 !devobj 0x820392A0 entering PnP State WdfDevStatePnpEnableInterfaces from WdfDevStatePnpHardwareAvailable
26: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x7DF07FE0 !devobj 0x820392A0 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpEnableInterfaces
27: FxPkgPnp::Dispatch - WDFDEVICE 0x7DF07FE0 !devobj 0x820392A0, IRP_MJ_PNP, 0x00000014(IRP_MN_QUERY_PNP_DEVICE_STATE) IRP 0x82CCEE90
28: FxPkgFdo::HandleQueryPnpDeviceStateCompletion - WDFDEVICE 0x7DF07FE0 !devobj 0x820392A0 returning PNP_DEVICE_STATE 0x0 IRP 0x82CCEE90
29: FxPkgPnp::Dispatch - WDFDEVICE 0x7DF07FE0 !devobj 0x820392A0, IRP_MJ_PNP, 0x00000007(IRP_MN_QUERY_DEVICE_RELATIONS) type 0xFFFFFFFF IRP 0x829C6E90
30: FxPkgPnp::Dispatch - WDFDEVICE 0x7DF07FE0 !devobj 0x820392A0, IRP_MJ_PNP, 0x00000007(IRP_MN_QUERY_DEVICE_RELATIONS) type 0xFFFFFFFF IRP 0x82542E90
31: FxPkgPnp::Dispatch - WDFDEVICE 0x7DF07FE0 !devobj 0x820392A0, IRP_MJ_PNP, 0x00000007(IRP_MN_QUERY_DEVICE_RELATIONS) type TargetDeviceRelation IRP 0x82D06E90
32: FxPkgPnp::Dispatch - WDFDEVICE 0x7DF07FE0 !devobj 0x820392A0, IRP_MJ_PNP, 0x00000007(IRP_MN_QUERY_DEVICE_RELATIONS) type BusRelations IRP 0x8308AE90
33: imp_WdfDmaEnablerCreate - Called at wrong IRQL; at level 2, should be at level 0
34: imp_WdfDmaEnablerCreate - Called at wrong IRQL; at level 2, should be at level 0
35: imp_WdfDmaEnablerCreate - Called at wrong IRQL; at level 2, should be at level 0
---- end of log ----

Also kb result:

kb
ChildEBP RetAddr Args to Child
f71db740 f709596a 821e4428 821e4514 f70dfd3c nt!DbgBreakPoint
f71db8dc f70fcc89 8206d8a0 7e21e568 00000000 wdf01000!imp_WdfUsbTargetDeviceSendControlTransferSynchronously+0x174
f71db900 f70fca76 7e21e568 00000000 f71db95c vUSBPP!WdfUsbTargetDeviceSendControlTransferSynchronously+0x29 [d:\winddk\7600.16385.1\inc\wdf\kmdf\1.9\wdfusb.h @ 1273]
f71db98c f70fe7c6 820f81e0 0000001d 00000000 vUSBPP!Usb_GetVendor+0x126 [d:\jj\16mar11\slb\win7-v-nrtslb\ioctl.c @ 143]
f71dbad0 f70b6072 7de1bbd0 7de9a828 00000004 vUSBPP!Usb_ProcessIOCTL+0x1e6 [d:\jj\16mar11\slb\win7-v-nrtslb\ioctl.c @ 2025]
f71dbaf4 f70b73d0 7de1bbd0 7de9a828 00000004 wdf01000!FxIoQueueIoInternalDeviceControl::Invoke+0x30
f71dbb24 f70b99ac 7de9a828 821657d0 821e4428 wdf01000!FxIoQueue::DispatchRequestToDriver+0x31d
f71dbb40 f70baa36 821e4400 00000000 81e03048 wdf01000!FxIoQueue::DispatchEvents+0x3be
f71dbb60 f70bc824 821657d0 8242ce90 00000038 wdf01000!FxIoQueue::QueueRequest+0x1ec
f71dbb84 f70aba3f 8242ce90 f71dbbac ba42365e wdf01000!FxPkgIo::Dispatch+0x27d
f71dbb90 ba42365e 820392a0 8242ce90 820392a0 wdf01000!FxDevice::Dispatch+0x7f
WARNING: Stack unwind information not available. Following frames may be wrong.
f71dbbac 804ee129 820392a0 81e65158 806d32e8 USBlyzer+0x165e
f71dbbbc 8064e328 8242cfd0 8242cff4 81ff5e78 nt!IopfCallDriver+0x31
f71dbbe0 80658d56 8242ce90 00000038 81ff5dc0 nt!IovCallDriver+0xa0
f71dbbf4 ba42365e 81ff5dc0 8242ce90 81ff5dc0 nt!ViDriverDispatchGeneric+0x2a
f71dbc10 804ee129 81ff5dc0 82221280 806d32e8 USBlyzer+0x165e
f71dbc20 8064e328 81e97380 806d32d0 8242ce90 nt!IopfCallDriver+0x31
f71dbc44 80574e56 8242cfd8 81e97380 8242ce90 nt!IovCallDriver+0xa0
f71dbc58 80575d11 81ff5dc0 8242ce90 81e97380 nt!IopSynchronousServiceTail+0x70
f71dbd00 8056e57c 0000019c 000001a0 00000000 nt!IopXxxControlFile+0x5e7
f71dbd34 8053d6d8 0000019c 000001a0 00000000 nt!NtDeviceIoControlFile+0x2a
f71dbd34 7c90e514 0000019c 000001a0 00000000 nt!KiFastCallEntry+0xf8
04b4fc4c 7c90d28a 7c866bf1 0000019c 000001a0 ntdll!KiFastSystemCallRet
04b4fc50 7c866bf1 0000019c 000001a0 00000000 ntdll!ZwDeviceIoControlFile+0xc
04b4fcb8 01812de4 0000019c 001a8ad0 001a5770 kernel32!GetCommState+0x5a
04b4fe44 018c192e 00000002 00000003 00000000 CDRVDL32!ser_rs232_setup+0x364
00000000 00000000 00000000 00000000 00000000 RS232!RS232_IsExist+0x4a

80000003 is a breakpoint.

My guess is that you are calling
WdfUsbTargetDeviceSendControlTransferSynchronously at the wrong IRQL.

It would help to run windbg !analyze -v and include that output in its
entirety when asking about crash events.

Mark Roddy

On Thu, Apr 21, 2011 at 7:47 AM, wrote:

> Also kb result:
>
> kb
> ChildEBP RetAddr Args to Child
> f71db740 f709596a 821e4428 821e4514 f70dfd3c nt!DbgBreakPoint
> f71db8dc f70fcc89 8206d8a0 7e21e568 00000000
> wdf01000!imp_WdfUsbTargetDeviceSendControlTransferSynchronously+0x174
> f71db900 f70fca76 7e21e568 00000000 f71db95c
> vUSBPP!WdfUsbTargetDeviceSendControlTransferSynchronously+0x29
> [d:\winddk\7600.16385.1\inc\wdf\kmdf\1.9\wdfusb.h @ 1273]
> f71db98c f70fe7c6 820f81e0 0000001d 00000000 vUSBPP!Usb_GetVendor+0x126
> [d:\jj\16mar11\slb\win7-v-nrtslb\ioctl.c @ 143]
> f71dbad0 f70b6072 7de1bbd0 7de9a828 00000004 vUSBPP!Usb_ProcessIOCTL+0x1e6
> [d:\jj\16mar11\slb\win7-v-nrtslb\ioctl.c @ 2025]
> f71dbaf4 f70b73d0 7de1bbd0 7de9a828 00000004
> wdf01000!FxIoQueueIoInternalDeviceControl::Invoke+0x30
> f71dbb24 f70b99ac 7de9a828 821657d0 821e4428
> wdf01000!FxIoQueue::DispatchRequestToDriver+0x31d
> f71dbb40 f70baa36 821e4400 00000000 81e03048
> wdf01000!FxIoQueue::DispatchEvents+0x3be
> f71dbb60 f70bc824 821657d0 8242ce90 00000038
> wdf01000!FxIoQueue::QueueRequest+0x1ec
> f71dbb84 f70aba3f 8242ce90 f71dbbac ba42365e
> wdf01000!FxPkgIo::Dispatch+0x27d
> f71dbb90 ba42365e 820392a0 8242ce90 820392a0
> wdf01000!FxDevice::Dispatch+0x7f
> WARNING: Stack unwind information not available. Following frames may be
> wrong.
> f71dbbac 804ee129 820392a0 81e65158 806d32e8 USBlyzer+0x165e
> f71dbbbc 8064e328 8242cfd0 8242cff4 81ff5e78 nt!IopfCallDriver+0x31
> f71dbbe0 80658d56 8242ce90 00000038 81ff5dc0 nt!IovCallDriver+0xa0
> f71dbbf4 ba42365e 81ff5dc0 8242ce90 81ff5dc0
> nt!ViDriverDispatchGeneric+0x2a
> f71dbc10 804ee129 81ff5dc0 82221280 806d32e8 USBlyzer+0x165e
> f71dbc20 8064e328 81e97380 806d32d0 8242ce90 nt!IopfCallDriver+0x31
> f71dbc44 80574e56 8242cfd8 81e97380 8242ce90 nt!IovCallDriver+0xa0
> f71dbc58 80575d11 81ff5dc0 8242ce90 81e97380
> nt!IopSynchronousServiceTail+0x70
> f71dbd00 8056e57c 0000019c 000001a0 00000000 nt!IopXxxControlFile+0x5e7
> f71dbd34 8053d6d8 0000019c 000001a0 00000000 nt!NtDeviceIoControlFile+0x2a
> f71dbd34 7c90e514 0000019c 000001a0 00000000 nt!KiFastCallEntry+0xf8
> 04b4fc4c 7c90d28a 7c866bf1 0000019c 000001a0 ntdll!KiFastSystemCallRet
> 04b4fc50 7c866bf1 0000019c 000001a0 00000000
> ntdll!ZwDeviceIoControlFile+0xc
> 04b4fcb8 01812de4 0000019c 001a8ad0 001a5770 kernel32!GetCommState+0x5a
> 04b4fe44 018c192e 00000002 00000003 00000000 CDRVDL32!ser_rs232_setup+0x364
> 00000000 00000000 00000000 00000000 00000000 RS232!RS232_IsExist+0x4a
>
>
> —
> 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
>

You need to return from the breakpoint (via a single step) and THEN look at the log, as described in the article (10 Things You Need To Know About KMDF): http://www.osronline.com/article.cfm?article=496

QUOTE:

This is one that makes me nuts. Let’s say you’re running your driver with KMDF Verifier enabled. Things look like they’re going well, until you suddenly hit a breakpoint. No output is shown in WinDbg to indicate why the breakpoint occurred. You look at the stack trace, and discover that you’re stopped in the middle of some function in the KMDF library. What’s up, and what do you do next??

The first thing to do in this situation is check the KMDF trace log (using !WDFLOGDUMP). If there’s nothing in the last few log entries that seem likely to account for your problem, continue in the debugger until the Framework returns to your driver. Once back in your driver, look at the return status (if there is one) from the KMDF function that you called and dump the KMDF trace log again. Chances are an error message describing the problem will now appear in the trace log.

END QUOTE

Also… this is a driver for a USB device? But you have one or more DMA Enabler objects? By the way, you appear to be creating these objects in a very unusual place:

33: imp_WdfDmaEnablerCreate - Called at wrong IRQL; at level 2, should be at
level 0
34: imp_WdfDmaEnablerCreate - Called at wrong IRQL; at level 2, should be at
level 0
35: imp_WdfDmaEnablerCreate - Called at wrong IRQL; at level 2, should be at
level 0

Clearly not the cause of the problem you’re seeing now, but also clearly a problem…

Peter
OSR

>Clearly not the cause of the problem you’re seeing now, but also clearly a

problem…

I think it probably is the problem and that’s just a bug in the log output.
A check of the IRQL before the call to
WdfIoTargetSendInternalIoctlSynchronously would answer it quickly enough.

-scott


Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@ntdev…

You need to return from the breakpoint (via a single step) and THEN look at
the log, as described in the article (10 Things You Need To Know About
KMDF): http://www.osronline.com/article.cfm?article=496

QUOTE:

This is one that makes me nuts. Let’s say you’re running your driver with
KMDF Verifier enabled. Things look like they’re going well, until you
suddenly hit a breakpoint. No output is shown in WinDbg to indicate why the
breakpoint occurred. You look at the stack trace, and discover that you’re
stopped in the middle of some function in the KMDF library. What’s up, and
what do you do next??

The first thing to do in this situation is check the KMDF trace log (using
!WDFLOGDUMP). If there’s nothing in the last few log entries that seem
likely to account for your problem, continue in the debugger until the
Framework returns to your driver. Once back in your driver, look at the
return status (if there is one) from the KMDF function that you called and
dump the KMDF trace log again. Chances are an error message describing the
problem will now appear in the trace log.

END QUOTE

Also… this is a driver for a USB device? But you have one or more DMA
Enabler objects? By the way, you appear to be creating these objects in a
very unusual place:

33: imp_WdfDmaEnablerCreate - Called at wrong IRQL; at level 2, should be at
level 0
34: imp_WdfDmaEnablerCreate - Called at wrong IRQL; at level 2, should be at
level 0
35: imp_WdfDmaEnablerCreate - Called at wrong IRQL; at level 2, should be at
level 0

Clearly not the cause of the problem you’re seeing now, but also clearly a
problem…

Peter
OSR

Thanks all,

I will check the IRQL level before and after the WdfUsbTargetDeviceSendControlTransferSynchronously and update.

@Peter

this is a driver for a USB device?
Yes
But you have one or more DMA Enabler objects?
Strange, I am not creating any DMA Enabler objs

Well, THAT’s entirely possible certainly. Only the OP knows, of course.

From that SAME DOCUMENT "Ten Things You Need To Know About KMDF " (which I’m SURE the OP read before posting, cuz you know, it’s only 4 years old):

QUOTE

Once you successfully generate and examine the KMDF trace log output, you might discover another sticking point. Let’s say, for example, you call WdfWorkItemCreate and forget that specifying a WDF_OBJECT_ATTRIBUTES structure is required. You get back an error, but when you look in the IFR log for further information you see a message that says “imp_WdfDpcCreate - WDF_OBJECT_ATTRIBUTES required, status 0xc0200212” – We previously explained how to make sense out of the status, but what’s with the “WdfDpcCreate”?? Your driver might not even call WdfDpcCreate.

Well, yeah… that’s “just one of those things” that you’ll learn to love in KMDF. Basically, the function name shown in the IFR isn’t always correct - So, you should just ignore it. YES, we told the KMDF team about it. And, YES, they know why this problem occurs. They’re just not sure if it’s something that’ll be fixed any time soon.

END QUOTE

Peter
OSR

The preceding post (about the IFR having the wrong function name) would account for that problem, then…

I think we have a solution,

Peter
OSR

Thanks all, it was a case of IRQL level mismatch,
the IOCTL callbacks were called at dispatch level and subsequently I was using “WdfUsbTargetDeviceSendControlTransferSynchronously” which should be called at passive level.

Now, I am able to move ahead using work item and in the workitem call back, calling above synchronous call. Now there is no break point exception.

However, using work item I am facing side effects,

  1. the callback GetVendorCommand registered in the work item is not getting called immediately whenever I issue call the enqueue work item.
    Is there any additional steps I need to handle to wait and ensure the workitem callback is called?

  2. between the time “WdfUsbTargetDeviceSendControlTransferSynchronously” is called and before it returns reading vendor data (in this case my 1st IOCTL is GET_BAUD_RATE), several other IOCTLS are being received from the application like IOCTL_GET_CHARS, IOCTL_GET_LINE_COTROL, etc.

As I need to first process the request for the IOCTL_GET_BAUD and return back the received data from the sync call to the application and complete the current request before processing this ioctl.

Awaiting for inputs, thanks in adv.

You need to step back and rethink your design. For example, if you need to
serialize operations, use a serialized queue.

No you cannot wait for a workitem to start at dispatch level - that is why
you were queueing a work item to begin with - you cannot wait at dispatch
level.

WDF gives you a plethora of design options for dispatching and queuing
requests.

Mark Roddy

On Tue, Apr 26, 2011 at 12:16 AM, wrote:

> WdfUsbTargetDeviceSendControlTransferSynchronously
>

Thanks for the updates.

Below are my settings for default queue: WdfIoQueueDispatchParallel

and for the device:
WdfSynchronizationScopeDevice

No you cannot wait for a workitem to start at dispatch level
we have not set the execution level to passive for the device as we are using DPCs and timers

and the ioctl callback is registered for the default q: ioQueueConfig.EvtIoDeviceControl = Usb_ProcessIOCTL;

if you need to serialize operations, use a serialized queue.
If I make this queue as serial/manual, my device will not work with some of the GUI based applications which uses USB-serial driver ex: hyperterminal.

On the other hand, WdfUsbTargetDeviceSendControlTransferSynchronously should be executed at passive level :frowning: so I need to use workitem or is there equivalent call at dispatch level, using that I can send the vendor commands?

Ok, there is one API WdfUsbTargetDeviceFormatRequestForControlTransfer
which is similar to above sync call, but runs <=dispatch and asysnc

I am going to use this and update

but the question remains: it requires completeion routine and how to synchronize between the caller and completion routine?