WORKER_THREAD_RETURNED_AT_BAD_IRQL

Peter

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

Eliyas Yakub [MSFT]

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
>
>

Eliyas Yakub [MSFT]

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
>
>

Eliyas Yakub [MSFT]

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
>
>

Peter

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
> >
> >
>
>
>

Peter

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
> >
> >
>
>
>

Peter

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
> >
> >
>
>
>

Eliyas Yakub [MSFT]

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
>> >
>> >
>>
>>
>>

Eliyas Yakub [MSFT]

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
>> >
>> >
>>
>>
>>

Eliyas Yakub [MSFT]

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
>> >
>> >
>>
>>
>>