Hi All,
For a USB device firmware testing, I am using an
existing windows driver. The Windows XP driver is used
for demo/testing the firmware.
The driver occasionally generates bug check
ATTEMPTED_SWITCH_FROM_DPC and the flow is as follows
1)From an IRP completion routine (Invoked for both
Completion/Cancel/OnError ), I am sending a USB Vendor
Request in synchronous manner.
2)The USB vendor request waits for completion using
KeWaitForSingleObject().
At random intervals, I am getting the above BOSD at
this wait location. From the crash dump, I could see
that the lower layer has called IoCancelIRP(). Also, I
think there is no bug check when the IRP is completed
successfully.
As per documentation, IO completion routines are
called on IRQL<=DISPATCH_LEVEL and the
KeWaitForSingleObject() has a restriction that if the
IRQL= DISPATCH_LEVEL, the last parameter “Timeout”
should be zero. My timeout is NULL which means
infinite wait. I think this is the root cause for my
problem.
So my question is, is there a temp fix for this
problem. How I can implement a wait at this condition
for the URB completion. I don’t want to rewrite the
driver logic as this is not a production one.
Thanks in advance for your support !!!
Thanks
Suja.
____________________________________________________________________________________Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase.
http://farechase.yahoo.com/
You cannot wait at IRQL DISPATCH_LEVEL this has been discussed too many
times to count. You are correct that the wait with a NULL is your problem.
You need to redesign you approach so that you are not waiting in a
Completion routine, this is bad practice in almost any circumstance. You
will need to not complete the IRP by returning
STATUS_MORE_PROCESSING_REQUIRED, then invoke a worker thread to do the USB
Vendor request and finally complete the IRP.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
“SUJA JAMES” wrote in message news:xxxxx@ntdev…
>
> Hi All,
>
> For a USB device firmware testing, I am using an
> existing windows driver. The Windows XP driver is used
> for demo/testing the firmware.
>
> The driver occasionally generates bug check
> ATTEMPTED_SWITCH_FROM_DPC and the flow is as follows
>
> 1)From an IRP completion routine (Invoked for both
> Completion/Cancel/OnError ), I am sending a USB Vendor
> Request in synchronous manner.
> 2)The USB vendor request waits for completion using
> KeWaitForSingleObject().
>
> At random intervals, I am getting the above BOSD at
> this wait location. From the crash dump, I could see
> that the lower layer has called IoCancelIRP(). Also, I
> think there is no bug check when the IRP is completed
> successfully.
>
> As per documentation, IO completion routines are
> called on IRQL<=DISPATCH_LEVEL and the
> KeWaitForSingleObject() has a restriction that if the
> IRQL= DISPATCH_LEVEL, the last parameter “Timeout”
> should be zero. My timeout is NULL which means
> infinite wait. I think this is the root cause for my
> problem.
>
> So my question is, is there a temp fix for this
> problem. How I can implement a wait at this condition
> for the URB completion. I don’t want to rewrite the
> driver logic as this is not a production one.
>
> Thanks in advance for your support !!!
>
> Thanks
> Suja.
>
>
>
>
> ____________________________________________________________________________________ Looking
> for a deal? Find great prices on flights and hotels with Yahoo!
> FareChase.
> http://farechase.yahoo.com/
>
> So my question is, is there a temp fix for this problem. How I can implement a wait
at this condition for the URB completion.
You cannot wait at DISPATCH_LEVEL - as simple as that. Therefore, you have to redesign your problem. For example, you can queue a work item, which will be executed at PASSIVE_LEVEL, so that you have more flexibility. Just keep in mind that work item runs in context of a system thread, so that you cannot wait for too long in it either…
Anton Bassov
> 1)From an IRP completion routine (Invoked for both
Completion/Cancel/OnError ), I am sending a USB Vendor
Request in synchronous manner.
This is a bug.
IRP completion routines are often called on DISPATCH_LEVEL, and doing any
synchronous (wait-for-completion) IO is a crash on DISPATCH_LEVEL.
Get rid of this synchronous IO. Instead, register a completion routine for it
and send it down in an async way. Then this completion routine will do the rest
of the job.
Another way is to use IoQueueWorkItem to send the synchronous IO.
As per documentation, IO completion routines are
called on IRQL<=DISPATCH_LEVEL and the
KeWaitForSingleObject() has a restriction that if the
IRQL= DISPATCH_LEVEL, the last parameter “Timeout”
should be zero. My timeout is NULL which means
infinite wait. I think this is the root cause for my
problem.
Yes.
So my question is, is there a temp fix for this
problem. How I can implement a wait at this condition
for the URB completion.
You cannot.
Either do not use waits, use the completion routine. Or offload the sending of
this URB to a work item.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> Another way is to use IoQueueWorkItem to send the synchronous IO.
Actually, work items have their own limitations as well - once work item routine runs in context of a system thread, you should not wait for too long in it …
Another issue lies with unloading drivers - if your driver is unloadable, you have to make sure that there are no outstanding work items left by the time your DrvUnload() is invoked
Anton Bassov
Use workitems. Check DDK samples, you can see the check for the current IRQL
and queue workItem if needed.
~Sisimon
On 6/3/07, xxxxx@hotmail.com wrote:
>
> > Another way is to use IoQueueWorkItem to send the synchronous IO.
>
> Actually, work items have their own limitations as well - once work item
> routine runs in context of a system thread, you should not wait for too long
> in it …
>
> Another issue lies with unloading drivers - if your driver is unloadable,
> you have to make sure that there are no outstanding work items left by the
> time your DrvUnload() is invoked
>
> Anton Bassov
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
GCS d+ s: a- c++++ U> B+ L++>$ w++++$ W++(+++) PGP+N+ t PS+PE++ tv+(++) b+++
G+++ e++>(++++) h-- r
Don’t know this? See http://www.geekcode.com/geek.html
> Use workitems. Check DDK samples, you can see the check for the current IRQL
and queue workItem if needed.
Or, alternatively, just redesign the problem in such way that waits are just not needed, i.e do everything asynchronously. Although not every problem can be redesigned this way, there are quite a few problems that can be redesigned…
Anton Bassov