TechTalkz.com Logo Ask the Experts!

Go Back   TechTalkz.com Technology & Computer Troubleshooting Forums > Tech Support Archives > Microsoft > Microsoft Device Drivers

WORKER_THREAD_RETURNED_AT_BAD_IRQL

Microsoft Device Drivers

 
 
Thread Tools Display Modes
Unread 29-11-2007, 11:03 PM   #1
Peter
Guest
 
Posts: n/a
WORKER_THREAD_RETURNED_AT_BAD_IRQL

I have this blue screen.
When I type "ln address". (where address is first displayed argument in this
bug)
then result is:
"(808e359e) nt!IopProcessWorkItem | (808e35c2) nt!NtCancelIoFile"

In my driver is used only one Work Item Routine - queued with
IoQueueWorkItem(),
why I cannot see it's address ?
Or can be reason of such bug something other than my work item routine ?

Peter


 
Unread 29-11-2007, 11:04 PM   #2
Eliyas Yakub [MSFT]
Guest
 
Posts: n/a
Re: WORKER_THREAD_RETURNED_AT_BAD_IRQL

You have to dump the workitem object to see your callback address. The
problem is that either you acquired a lock (that raise IRQL above passive)
such as spinlock/fastmutex and didn't release the lock or raised the IRQL
using KeRaiseIrql explicitly and didn't lower the IRQL before returning from
the workitem callback.

-Eliyas


"Peter" <Peter@discussions.microsoft.com> wrote in message
news:3ACB1743-39F9-4EF0-A3FC-DD5780F11F99@microsoft.com...
>I have this blue screen.
> When I type "ln address". (where address is first displayed argument in
> this
> bug)
> then result is:
> "(808e359e) nt!IopProcessWorkItem | (808e35c2) nt!NtCancelIoFile"
>
> In my driver is used only one Work Item Routine - queued with
> IoQueueWorkItem(),
> why I cannot see it's address ?
> Or can be reason of such bug something other than my work item routine ?
>
> Peter
>
>



 
Unread 29-11-2007, 11:04 PM   #3
Eliyas Yakub [MSFT]
Guest
 
Posts: n/a
Re: WORKER_THREAD_RETURNED_AT_BAD_IRQL

You have to dump the workitem object to see your callback address. The
problem is that either you acquired a lock (that raise IRQL above passive)
such as spinlock/fastmutex and didn't release the lock or raised the IRQL
using KeRaiseIrql explicitly and didn't lower the IRQL before returning from
the workitem callback.

-Eliyas


"Peter" <Peter@discussions.microsoft.com> wrote in message
news:3ACB1743-39F9-4EF0-A3FC-DD5780F11F99@microsoft.com...
>I have this blue screen.
> When I type "ln address". (where address is first displayed argument in
> this
> bug)
> then result is:
> "(808e359e) nt!IopProcessWorkItem | (808e35c2) nt!NtCancelIoFile"
>
> In my driver is used only one Work Item Routine - queued with
> IoQueueWorkItem(),
> why I cannot see it's address ?
> Or can be reason of such bug something other than my work item routine ?
>
> Peter
>
>



 
Unread 29-11-2007, 11:04 PM   #4
Eliyas Yakub [MSFT]
Guest
 
Posts: n/a
Re: WORKER_THREAD_RETURNED_AT_BAD_IRQL

You have to dump the workitem object to see your callback address. The
problem is that either you acquired a lock (that raise IRQL above passive)
such as spinlock/fastmutex and didn't release the lock or raised the IRQL
using KeRaiseIrql explicitly and didn't lower the IRQL before returning from
the workitem callback.

-Eliyas


"Peter" <Peter@discussions.microsoft.com> wrote in message
news:3ACB1743-39F9-4EF0-A3FC-DD5780F11F99@microsoft.com...
>I have this blue screen.
> When I type "ln address". (where address is first displayed argument in
> this
> bug)
> then result is:
> "(808e359e) nt!IopProcessWorkItem | (808e35c2) nt!NtCancelIoFile"
>
> In my driver is used only one Work Item Routine - queued with
> IoQueueWorkItem(),
> why I cannot see it's address ?
> Or can be reason of such bug something other than my work item routine ?
>
> Peter
>
>



 
Unread 30-11-2007, 12:40 AM   #5
Peter
Guest
 
Posts: n/a
Re: WORKER_THREAD_RETURNED_AT_BAD_IRQL

Dumping workitem is probably not possible with windbg, probably this
structure is not documented. By I found some article where is described
members of this structure and there is really on 16 bytes offset address of
my work item routine.

Thanks for the tip, it helps me.
Peter

"Eliyas Yakub [MSFT]" wrote:

> You have to dump the workitem object to see your callback address. The
> problem is that either you acquired a lock (that raise IRQL above passive)
> such as spinlock/fastmutex and didn't release the lock or raised the IRQL
> using KeRaiseIrql explicitly and didn't lower the IRQL before returning from
> the workitem callback.
>
> -Eliyas
>
>
> "Peter" <Peter@discussions.microsoft.com> wrote in message
> news:3ACB1743-39F9-4EF0-A3FC-DD5780F11F99@microsoft.com...
> >I have this blue screen.
> > When I type "ln address". (where address is first displayed argument in
> > this
> > bug)
> > then result is:
> > "(808e359e) nt!IopProcessWorkItem | (808e35c2) nt!NtCancelIoFile"
> >
> > In my driver is used only one Work Item Routine - queued with
> > IoQueueWorkItem(),
> > why I cannot see it's address ?
> > Or can be reason of such bug something other than my work item routine ?
> >
> > Peter
> >
> >

>
>
>

 
Unread 30-11-2007, 12:40 AM   #6
Peter
Guest
 
Posts: n/a
Re: WORKER_THREAD_RETURNED_AT_BAD_IRQL

Dumping workitem is probably not possible with windbg, probably this
structure is not documented. By I found some article where is described
members of this structure and there is really on 16 bytes offset address of
my work item routine.

Thanks for the tip, it helps me.
Peter

"Eliyas Yakub [MSFT]" wrote:

> You have to dump the workitem object to see your callback address. The
> problem is that either you acquired a lock (that raise IRQL above passive)
> such as spinlock/fastmutex and didn't release the lock or raised the IRQL
> using KeRaiseIrql explicitly and didn't lower the IRQL before returning from
> the workitem callback.
>
> -Eliyas
>
>
> "Peter" <Peter@discussions.microsoft.com> wrote in message
> news:3ACB1743-39F9-4EF0-A3FC-DD5780F11F99@microsoft.com...
> >I have this blue screen.
> > When I type "ln address". (where address is first displayed argument in
> > this
> > bug)
> > then result is:
> > "(808e359e) nt!IopProcessWorkItem | (808e35c2) nt!NtCancelIoFile"
> >
> > In my driver is used only one Work Item Routine - queued with
> > IoQueueWorkItem(),
> > why I cannot see it's address ?
> > Or can be reason of such bug something other than my work item routine ?
> >
> > Peter
> >
> >

>
>
>

 
Unread 30-11-2007, 12:40 AM   #7
Peter
Guest
 
Posts: n/a
Re: WORKER_THREAD_RETURNED_AT_BAD_IRQL

Dumping workitem is probably not possible with windbg, probably this
structure is not documented. By I found some article where is described
members of this structure and there is really on 16 bytes offset address of
my work item routine.

Thanks for the tip, it helps me.
Peter

"Eliyas Yakub [MSFT]" wrote:

> You have to dump the workitem object to see your callback address. The
> problem is that either you acquired a lock (that raise IRQL above passive)
> such as spinlock/fastmutex and didn't release the lock or raised the IRQL
> using KeRaiseIrql explicitly and didn't lower the IRQL before returning from
> the workitem callback.
>
> -Eliyas
>
>
> "Peter" <Peter@discussions.microsoft.com> wrote in message
> news:3ACB1743-39F9-4EF0-A3FC-DD5780F11F99@microsoft.com...
> >I have this blue screen.
> > When I type "ln address". (where address is first displayed argument in
> > this
> > bug)
> > then result is:
> > "(808e359e) nt!IopProcessWorkItem | (808e35c2) nt!NtCancelIoFile"
> >
> > In my driver is used only one Work Item Routine - queued with
> > IoQueueWorkItem(),
> > why I cannot see it's address ?
> > Or can be reason of such bug something other than my work item routine ?
> >
> > Peter
> >
> >

>
>
>

 
Unread 30-11-2007, 12:43 AM   #8
Eliyas Yakub [MSFT]
Guest
 
Posts: n/a
Re: WORKER_THREAD_RETURNED_AT_BAD_IRQL

I will file a bug to either fix the bugcheck parameters to dump the callback
pointer instead of the workitem object or make the _IO_WORKITEM structure
public.

-Eliyas

"Peter" <Peter@discussions.microsoft.com> wrote in message
news:7F06E247-0427-4A45-A928-92B326DC5873@microsoft.com...
> Dumping workitem is probably not possible with windbg, probably this
> structure is not documented. By I found some article where is described
> members of this structure and there is really on 16 bytes offset address
> of
> my work item routine.
>
> Thanks for the tip, it helps me.
> Peter
>
> "Eliyas Yakub [MSFT]" wrote:
>
>> You have to dump the workitem object to see your callback address. The
>> problem is that either you acquired a lock (that raise IRQL above
>> passive)
>> such as spinlock/fastmutex and didn't release the lock or raised the IRQL
>> using KeRaiseIrql explicitly and didn't lower the IRQL before returning
>> from
>> the workitem callback.
>>
>> -Eliyas
>>
>>
>> "Peter" <Peter@discussions.microsoft.com> wrote in message
>> news:3ACB1743-39F9-4EF0-A3FC-DD5780F11F99@microsoft.com...
>> >I have this blue screen.
>> > When I type "ln address". (where address is first displayed argument in
>> > this
>> > bug)
>> > then result is:
>> > "(808e359e) nt!IopProcessWorkItem | (808e35c2)
>> > nt!NtCancelIoFile"
>> >
>> > In my driver is used only one Work Item Routine - queued with
>> > IoQueueWorkItem(),
>> > why I cannot see it's address ?
>> > Or can be reason of such bug something other than my work item routine
>> > ?
>> >
>> > Peter
>> >
>> >

>>
>>
>>



 
Unread 30-11-2007, 12:43 AM   #9
Eliyas Yakub [MSFT]
Guest
 
Posts: n/a
Re: WORKER_THREAD_RETURNED_AT_BAD_IRQL

I will file a bug to either fix the bugcheck parameters to dump the callback
pointer instead of the workitem object or make the _IO_WORKITEM structure
public.

-Eliyas

"Peter" <Peter@discussions.microsoft.com> wrote in message
news:7F06E247-0427-4A45-A928-92B326DC5873@microsoft.com...
> Dumping workitem is probably not possible with windbg, probably this
> structure is not documented. By I found some article where is described
> members of this structure and there is really on 16 bytes offset address
> of
> my work item routine.
>
> Thanks for the tip, it helps me.
> Peter
>
> "Eliyas Yakub [MSFT]" wrote:
>
>> You have to dump the workitem object to see your callback address. The
>> problem is that either you acquired a lock (that raise IRQL above
>> passive)
>> such as spinlock/fastmutex and didn't release the lock or raised the IRQL
>> using KeRaiseIrql explicitly and didn't lower the IRQL before returning
>> from
>> the workitem callback.
>>
>> -Eliyas
>>
>>
>> "Peter" <Peter@discussions.microsoft.com> wrote in message
>> news:3ACB1743-39F9-4EF0-A3FC-DD5780F11F99@microsoft.com...
>> >I have this blue screen.
>> > When I type "ln address". (where address is first displayed argument in
>> > this
>> > bug)
>> > then result is:
>> > "(808e359e) nt!IopProcessWorkItem | (808e35c2)
>> > nt!NtCancelIoFile"
>> >
>> > In my driver is used only one Work Item Routine - queued with
>> > IoQueueWorkItem(),
>> > why I cannot see it's address ?
>> > Or can be reason of such bug something other than my work item routine
>> > ?
>> >
>> > Peter
>> >
>> >

>>
>>
>>



 
Unread 30-11-2007, 12:43 AM   #10
Eliyas Yakub [MSFT]
Guest
 
Posts: n/a
Re: WORKER_THREAD_RETURNED_AT_BAD_IRQL

I will file a bug to either fix the bugcheck parameters to dump the callback
pointer instead of the workitem object or make the _IO_WORKITEM structure
public.

-Eliyas

"Peter" <Peter@discussions.microsoft.com> wrote in message
news:7F06E247-0427-4A45-A928-92B326DC5873@microsoft.com...
> Dumping workitem is probably not possible with windbg, probably this
> structure is not documented. By I found some article where is described
> members of this structure and there is really on 16 bytes offset address
> of
> my work item routine.
>
> Thanks for the tip, it helps me.
> Peter
>
> "Eliyas Yakub [MSFT]" wrote:
>
>> You have to dump the workitem object to see your callback address. The
>> problem is that either you acquired a lock (that raise IRQL above
>> passive)
>> such as spinlock/fastmutex and didn't release the lock or raised the IRQL
>> using KeRaiseIrql explicitly and didn't lower the IRQL before returning
>> from
>> the workitem callback.
>>
>> -Eliyas
>>
>>
>> "Peter" <Peter@discussions.microsoft.com> wrote in message
>> news:3ACB1743-39F9-4EF0-A3FC-DD5780F11F99@microsoft.com...
>> >I have this blue screen.
>> > When I type "ln address". (where address is first displayed argument in
>> > this
>> > bug)
>> > then result is:
>> > "(808e359e) nt!IopProcessWorkItem | (808e35c2)
>> > nt!NtCancelIoFile"
>> >
>> > In my driver is used only one Work Item Routine - queued with
>> > IoQueueWorkItem(),
>> > why I cannot see it's address ?
>> > Or can be reason of such bug something other than my work item routine
>> > ?
>> >
>> > Peter
>> >
>> >

>>
>>
>>



 
 

Thread Tools
Display Modes



< Home - Windows Help - MS Office Help - Hardware Support >


New To Site? Need Help?

All times are GMT. The time now is 06:18 AM.


vBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO
Copyright © 2005-2013, TechTalkz.com. All Rights Reserved - Privacy Policy
Valid XHTML 1.0 Transitional