Bugcheck from ExQueueWorkItem in passive mode

NTFSD
1

I am getting bugcheck 0xD5 (driver is attempting to access memory after it
has been freed) when using a workerthread in a read completion routine. But
it only happens if the I am currently in passive level. It works fine if I
am in dispatch level. Now I know it doesn’t make much sense to use a worker
thread when in passive level, but it shouldn’t blue screen, should it?

Thanks for any enlightenment.

Neil

2

What do you mean if you are ‘currently in passive level’? You mean that
if the completion routine fires at passive level as opposed to dispatch?
If so, do you crash in the completion routine itself, or in the worker
thread? Are you aborting completion processing correctly by returning
STATUS_MORE_PROCESSING_REQUIRED, then completing the IRP in the worker
thread after you’re done with it?

Neil Weicher wrote:

I am getting bugcheck 0xD5 (driver is attempting to access memory after it
has been freed) when using a workerthread in a read completion routine. But
it only happens if the I am currently in passive level. It works fine if I
am in dispatch level. Now I know it doesn’t make much sense to use a worker
thread when in passive level, but it shouldn’t blue screen, should it?

Thanks for any enlightenment.

Neil

3

Thanks for the reply. As I mentioned it is working fine at dispatch level,
so yes, I believe I am doing it the right way. After I kick off the worker
thread I issue the following:

IoMarkIrpPending(Irp);
return (STATUS_MORE_PROCESSING_REQUIRED);

Before the worker thread returns it completes the Irp:

ntStatus = ioContext->Irp->IoStatus.Status; // crash here
IoCompleteRequest( ioContext->Irp, IO_DISK_INCREMENT );
return (ntStatus);

However, I did determine where the crash is occurring (see comment). It
looks like the file is being closed between the time I kick off the worker
thread and the time I complete the Irp. So it looks like something else is
completing the Irp even though I retruned SMPR!

Neil

----- Original Message -----

What do you mean if you are ‘currently in passive level’? You mean that
if the completion routine fires at passive level as opposed to dispatch?
If so, do you crash in the completion routine itself, or in the worker
thread? Are you aborting completion processing correctly by returning
STATUS_MORE_PROCESSING_REQUIRED, then completing the IRP in the worker
thread after you’re done with it?

Neil Weicher wrote:

I am getting bugcheck 0xD5 (driver is attempting to access memory after it
has been freed) when using a workerthread in a read completion routine.
But
it only happens if the I am currently in passive level. It works fine if
I
am in dispatch level. Now I know it doesn’t make much sense to use a
worker
thread when in passive level, but it shouldn’t blue screen, should it?

Thanks for any enlightenment.

Neil

END OF DIGEST

You are currently subscribed to ntfsd as: xxxxx@netlib.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

Hi,

I think the problem is here: you should mark the irp pending *before* =
you kick off the worker thread! At dispatch level you were lucky, that =
IoMarkIrpPending got called before the worker thread started!

Right?

“Windows File Systems Devs Interest List” schrieb am 29.01.04 14:37:20:
>
> Thanks for the reply. As I mentioned it is working fine at dispatch level,
> so yes, I believe I am doing it the right way. After I kick off the worker
> thread I issue the following:
>
> IoMarkIrpPending(Irp);
> return (STATUS_MORE_PROCESSING_REQUIRED);
>
> Before the worker thread returns it completes the Irp:
>
> ntStatus = ioContext->Irp->IoStatus.Status; // crash here
> IoCompleteRequest( ioContext->Irp, IO_DISK_INCREMENT );
> return (ntStatus);
>
> However, I did determine where the crash is occurring (see comment). It
> looks like the file is being closed between the time I kick off the worker
> thread and the time I complete the Irp. So it looks like something else is
> completing the Irp even though I retruned SMPR!
>
> Neil
>
> ----- Original Message -----
>
> What do you mean if you are ‘currently in passive level’? You mean that
> if the completion routine fires at passive level as opposed to dispatch?
> If so, do you crash in the completion routine itself, or in the worker
> thread? Are you aborting completion processing correctly by returning
> STATUS_MORE_PROCESSING_REQUIRED, then completing the IRP in the worker
> thread after you’re done with it?
>
> Neil Weicher wrote:
> > I am getting bugcheck 0xD5 (driver is attempting to access memory after it
> > has been freed) when using a workerthread in a read completion routine.
> But
> > it only happens if the I am currently in passive level. It works fine if
> I
> > am in dispatch level. Now I know it doesn’t make much sense to use a
> worker
> > thread when in passive level, but it shouldn’t blue screen, should it?
> >
> > Thanks for any enlightenment.
> >
> > Neil
> >
> >
>
>
>
> —
>
> END OF DIGEST
>
> —
> You are currently subscribed to ntfsd as: xxxxx@netlib.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@clever.ms
> To unsubscribe send a blank email to xxxxx@lists.osr.com

5

You should be marking the IRP as pending before adding the request to a
queue. What is happening is the request is completing before your call to
IoMarkIrpPending.

Jamey Kirby, Windows DDK MVP
StorageCraft Inc.
xxxxx@storagecraft.com
http://www.storagecraft.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Neil Weicher
Sent: Thursday, January 29, 2004 5:37 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Bugcheck from ExQueueWorkItem in passive mode

Thanks for the reply. As I mentioned it is working fine at dispatch level,
so yes, I believe I am doing it the right way. After I kick off the worker
thread I issue the following:

IoMarkIrpPending(Irp);
return (STATUS_MORE_PROCESSING_REQUIRED);

Before the worker thread returns it completes the Irp:

ntStatus = ioContext->Irp->IoStatus.Status; // crash here
IoCompleteRequest( ioContext->Irp, IO_DISK_INCREMENT );
return (ntStatus);

However, I did determine where the crash is occurring (see comment). It
looks like the file is being closed between the time I kick off the worker
thread and the time I complete the Irp. So it looks like something else is
completing the Irp even though I retruned SMPR!

Neil

----- Original Message -----

What do you mean if you are ‘currently in passive level’? You mean that
if the completion routine fires at passive level as opposed to dispatch?
If so, do you crash in the completion routine itself, or in the worker
thread? Are you aborting completion processing correctly by returning
STATUS_MORE_PROCESSING_REQUIRED, then completing the IRP in the worker
thread after you’re done with it?

Neil Weicher wrote:

I am getting bugcheck 0xD5 (driver is attempting to access memory after it
has been freed) when using a workerthread in a read completion routine.
But
it only happens if the I am currently in passive level. It works fine if
I
am in dispatch level. Now I know it doesn’t make much sense to use a
worker
thread when in passive level, but it shouldn’t blue screen, should it?

Thanks for any enlightenment.

Neil

END OF DIGEST

You are currently subscribed to ntfsd as: xxxxx@netlib.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

6

Thanks for the tip, at first it seemed it was doing the trick - but under
closer examination it still seems like something is freeing the Irp before
the worker thread completes! I didn’t notice it at first because of the
“try”, but once I removed it … BOOM!

Thanks for any insights.

Neil

// inside completion routine:
IoMarkIrpPending(Irp);
ExInitializeWorkItem( &ioContext->WorkItem,ReadWork, ioContext );
ExQueueWorkItem( &ioContext->WorkItem, CriticalWorkQueue );
return (STATUS_MORE_PROCESSING_REQUIRED);

// inside worker thread
ntStatus = ioContext->Irp->IoStatus.Status; // BOOM!
IoCompleteRequest( ioContext->Irp, IO_DISK_INCREMENT );
ExFreeToNPagedLookasideList(&gLookasideList,ioContext);
return (ntStatus);

----- Original Message -----

Subject: RE: Bugcheck from ExQueueWorkItem in passive mode
From: “Jamey Kirby”
Date: Thu, 29 Jan 2004 11:09:19 -0800

You should be marking the IRP as pending before adding the request to a
queue. What is happening is the request is completing before your call to
IoMarkIrpPending.

Jamey Kirby, Windows DDK MVP
StorageCraft Inc.
xxxxx@storagecraft.com
http://www.storagecraft.com

-----Original Message-----
Sent: Thursday, January 29, 2004 5:37 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Bugcheck from ExQueueWorkItem in passive mode

Thanks for the reply. As I mentioned it is working fine at dispatch level,
so yes, I believe I am doing it the right way. After I kick off the worker
thread I issue the following:

IoMarkIrpPending(Irp);
return (STATUS_MORE_PROCESSING_REQUIRED);

Before the worker thread returns it completes the Irp:

ntStatus = ioContext->Irp->IoStatus.Status; // crash here
IoCompleteRequest( ioContext->Irp, IO_DISK_INCREMENT );
return (ntStatus);

However, I did determine where the crash is occurring (see comment). It
looks like the file is being closed between the time I kick off the worker
thread and the time I complete the Irp. So it looks like something else is
completing the Irp even though I retruned SMPR!

Neil

7

Do you check the status of completing Irp in your completion routine before
you proceed?
I also assume that you have already read the OSR and IFS Kit docs on HowTo
IoMarkPending.
WBR Primoz

-----Original Message-----
From: Neil Weicher [mailto:xxxxx@netlib.com]
Sent: Friday, January 30, 2004 3:29 PM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Bugcheck from ExQueueWorkItem in passive mode

Thanks for the tip, at first it seemed it was doing the trick - but under
closer examination it still seems like something is freeing the Irp before
the worker thread completes! I didn’t notice it at first because of the
“try”, but once I removed it … BOOM!

Thanks for any insights.

Neil

// inside completion routine:
IoMarkIrpPending(Irp);
ExInitializeWorkItem( &ioContext->WorkItem,ReadWork, ioContext );
ExQueueWorkItem( &ioContext->WorkItem, CriticalWorkQueue );
return (STATUS_MORE_PROCESSING_REQUIRED);

// inside worker thread
ntStatus = ioContext->Irp->IoStatus.Status; // BOOM!
IoCompleteRequest( ioContext->Irp, IO_DISK_INCREMENT );
ExFreeToNPagedLookasideList(&gLookasideList,ioContext);
return (ntStatus);

----- Original Message -----

Subject: RE: Bugcheck from ExQueueWorkItem in passive mode
From: “Jamey Kirby”
Date: Thu, 29 Jan 2004 11:09:19 -0800

You should be marking the IRP as pending before adding the request to a
queue. What is happening is the request is completing before your call to
IoMarkIrpPending.

Jamey Kirby, Windows DDK MVP
StorageCraft Inc.
xxxxx@storagecraft.com
http://www.storagecraft.com

-----Original Message-----
Sent: Thursday, January 29, 2004 5:37 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Bugcheck from ExQueueWorkItem in passive mode

Thanks for the reply. As I mentioned it is working fine at dispatch level,
so yes, I believe I am doing it the right way. After I kick off the worker
thread I issue the following:

IoMarkIrpPending(Irp);
return (STATUS_MORE_PROCESSING_REQUIRED);

Before the worker thread returns it completes the Irp:

ntStatus = ioContext->Irp->IoStatus.Status; // crash here
IoCompleteRequest( ioContext->Irp, IO_DISK_INCREMENT );
return (ntStatus);

However, I did determine where the crash is occurring (see comment). It
looks like the file is being closed between the time I kick off the worker
thread and the time I complete the Irp. So it looks like something else is
completing the Irp even though I retruned SMPR!

Neil

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@hermes.si
To unsubscribe send a blank email to xxxxx@lists.osr.com

8

How are you signaling the thread to start processing the request?

Jamey Kirby, Windows DDK MVP
StorageCraft Inc.
xxxxx@storagecraft.com
http://www.storagecraft.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Neil Weicher
Sent: Friday, January 30, 2004 6:29 AM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Bugcheck from ExQueueWorkItem in passive mode

Thanks for the tip, at first it seemed it was doing the trick - but under
closer examination it still seems like something is freeing the Irp before
the worker thread completes! I didn’t notice it at first because of the
“try”, but once I removed it … BOOM!

Thanks for any insights.

Neil

// inside completion routine:
IoMarkIrpPending(Irp);
ExInitializeWorkItem( &ioContext->WorkItem,ReadWork, ioContext );
ExQueueWorkItem( &ioContext->WorkItem, CriticalWorkQueue );
return (STATUS_MORE_PROCESSING_REQUIRED);

// inside worker thread
ntStatus = ioContext->Irp->IoStatus.Status; // BOOM!
IoCompleteRequest( ioContext->Irp, IO_DISK_INCREMENT );
ExFreeToNPagedLookasideList(&gLookasideList,ioContext);
return (ntStatus);

----- Original Message -----

Subject: RE: Bugcheck from ExQueueWorkItem in passive mode
From: “Jamey Kirby”
Date: Thu, 29 Jan 2004 11:09:19 -0800

You should be marking the IRP as pending before adding the request to a
queue. What is happening is the request is completing before your call to
IoMarkIrpPending.

Jamey Kirby, Windows DDK MVP
StorageCraft Inc.
xxxxx@storagecraft.com
http://www.storagecraft.com

-----Original Message-----
Sent: Thursday, January 29, 2004 5:37 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Bugcheck from ExQueueWorkItem in passive mode

Thanks for the reply. As I mentioned it is working fine at dispatch level,
so yes, I believe I am doing it the right way. After I kick off the worker
thread I issue the following:

IoMarkIrpPending(Irp);
return (STATUS_MORE_PROCESSING_REQUIRED);

Before the worker thread returns it completes the Irp:

ntStatus = ioContext->Irp->IoStatus.Status; // crash here
IoCompleteRequest( ioContext->Irp, IO_DISK_INCREMENT );
return (ntStatus);

However, I did determine where the crash is occurring (see comment). It
looks like the file is being closed between the time I kick off the worker
thread and the time I complete the Irp. So it looks like something else is
completing the Irp even though I retruned SMPR!

Neil

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

9

Hi Jamey,

Not sure I follow you. Here is the stripped down code in the completion
routine. It is being triggered by the ExQueueWorkItem. Am I missing
something?

Thanks.

Neil

IoMarkIrpPending(Irp);
ExInitializeWorkItem( &ioContext->WorkItem,ReadWork, ioContext );
ExQueueWorkItem( &ioContext->WorkItem, CriticalWorkQueue );
return (STATUS_MORE_PROCESSING_REQUIRED);

Subject: RE: Bugcheck from ExQueueWorkItem in passive mode
From: “Jamey Kirby”

How are you signaling the thread to start processing the request?

Jamey Kirby, Windows DDK MVP
StorageCraft Inc.
xxxxx@storagecraft.com
http://www.storagecraft.com

10

Forgot to mention - I don’t know if this is important, but it is overlapped IO
(although not paging i/o). - Neil

Subject: RE: Bugcheck from ExQueueWorkItem in passive mode
From: “Jamey Kirby”

How are you signaling the thread to start processing the request?

Jamey Kirby, Windows DDK MVP
StorageCraft Inc.
xxxxx@storagecraft.com
http://www.storagecraft.com

11

Neil,

What are you returning from your dispatch entry point? If you are not
returning STATUS_PENDING, then it will not work, even if you mark the
IRP as pending in the completion routine, and would cause exactly the
type of problem that you describe.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Neil Weicher
Sent: Saturday, January 31, 2004 9:09 AM
To: ntfsd redirect
Subject: RE:[ntfsd] Bugcheck from ExQueueWorkItem in passive mode

Hi Jamey,

Not sure I follow you. Here is the stripped down code in the completion
routine. It is being triggered by the ExQueueWorkItem. Am I missing
something?

Thanks.

Neil

IoMarkIrpPending(Irp);
ExInitializeWorkItem( &ioContext->WorkItem,ReadWork, ioContext );
ExQueueWorkItem( &ioContext->WorkItem, CriticalWorkQueue );
return (STATUS_MORE_PROCESSING_REQUIRED);

Subject: RE: Bugcheck from ExQueueWorkItem in passive mode
From: “Jamey Kirby”

How are you signaling the thread to start processing the request?

Jamey Kirby, Windows DDK MVP
StorageCraft Inc.
xxxxx@storagecraft.com
http://www.storagecraft.com

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com To unsubscribe
send a blank email to xxxxx@lists.osr.com

12

Thanks Tony. Hmmm… I wonder if you are right. I am simply returning the
value returned by IoCallDriver. I.e.,

IoSetCompletionRoutine(Irp, BFilterReadCompletion, ioContext, TRUE,
TRUE,TRUE);
return ( IoCallDriver(deviceExtension->FileSystemDeviceObject, Irp) );

Should I change it to this?

IoSetCompletionRoutine(Irp, BFilterReadCompletion, ioContext, TRUE,
TRUE,TRUE);
IoCallDriver(deviceExtension->FileSystemDeviceObject, Irp) ;
return (STATUS_PENDING);

----- Original Message -----
From: “Tony Mason”
To: “Windows File Systems Devs Interest List”
Sent: Saturday, January 31, 2004 9:26 AM
Subject: RE: [ntfsd] Bugcheck from ExQueueWorkItem in passive mode

Neil,

What are you returning from your dispatch entry point? If you are not
returning STATUS_PENDING, then it will not work, even if you mark the
IRP as pending in the completion routine, and would cause exactly the
type of problem that you describe.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Neil Weicher
Sent: Saturday, January 31, 2004 9:09 AM
To: ntfsd redirect
Subject: RE:[ntfsd] Bugcheck from ExQueueWorkItem in passive mode

Hi Jamey,

Not sure I follow you. Here is the stripped down code in the completion
routine. It is being triggered by the ExQueueWorkItem. Am I missing
something?

Thanks.

Neil

IoMarkIrpPending(Irp);
ExInitializeWorkItem( &ioContext->WorkItem,ReadWork, ioContext );
ExQueueWorkItem( &ioContext->WorkItem, CriticalWorkQueue );
return (STATUS_MORE_PROCESSING_REQUIRED);

-----------------

Subject: RE: Bugcheck from ExQueueWorkItem in passive mode
From: “Jamey Kirby”

How are you signaling the thread to start processing the request?

Jamey Kirby, Windows DDK MVP
StorageCraft Inc.
xxxxx@storagecraft.com
http://www.storagecraft.com

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com To unsubscribe
send a blank email to xxxxx@lists.osr.com

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@netlib.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

13

Thanks for the tip. I changed this:

IoSetCompletionRoutine(TRUE,TRUE,TRUE);
return IoCallDriver(…)

to this

IoSetCompletionRoutine(TRUE,TRUE,TRUE);
IoCallDriver(…)
return (STATUS_PENDING);

And it is working now, thanks! The question is, when is this NOT
appropriate? For example, I can’t blindly do it in the following
situations:

IoSetCompletionRoutine(TRUE,FALSE,FALSE);
IoCallDriver(…)
return (STATUS_PENDING);

Thanks again.

Neil

----- Original Message -----
From: “Tony Mason”
Sent: Saturday, January 31, 2004 9:26 AM
Subject: RE: [ntfsd] Bugcheck from ExQueueWorkItem in passive mode

Neil,

What are you returning from your dispatch entry point? If you are not
returning STATUS_PENDING, then it will not work, even if you mark the
IRP as pending in the completion routine, and would cause exactly the
type of problem that you describe.

Regards,

Tony

14

Since the IRP will be completed in the work item queued by its completion
routine, the DISPATCH routine must return STATUS_PENDING so that
IopSynchronousServiceTail won’t free the IRP.

If the dispatch routine returns non-pending status, I/O manager will free
the IRP even the completion has return STATUS_MORE_PROCESSING_REQUIRED.

In you first case:

IoSetCompletionRoutine(TRUE,TRUE,TRUE);
return IoCallDriver(…)

would be fine if lower returned pending, but will fail if lower doesn’t
pent.

Calvin Guan, Software Engineer xxxxx@nospam.ati.com
ATI Technologies Inc. Markham ON. Canada
Tel: (905) 882-2600 Ext. 8654

-----Original Message-----
From: Neil Weicher [mailto:xxxxx@netlib.com]
Sent: Sunday, February 01, 2004 5:46 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Bugcheck from ExQueueWorkItem in passive mode

Thanks for the tip. I changed this:

IoSetCompletionRoutine(TRUE,TRUE,TRUE);
return IoCallDriver(…)

to this

IoSetCompletionRoutine(TRUE,TRUE,TRUE);
IoCallDriver(…)
return (STATUS_PENDING);

And it is working now, thanks! The question is, when is this NOT
appropriate? For example, I can’t blindly do it in the following
situations:

IoSetCompletionRoutine(TRUE,FALSE,FALSE);
IoCallDriver(…)
return (STATUS_PENDING);

Thanks again.

Neil

----- Original Message -----
From: “Tony Mason”
> Sent: Saturday, January 31, 2004 9:26 AM
> Subject: RE: [ntfsd] Bugcheck from ExQueueWorkItem in passive mode
>
>
> Neil,
>
> What are you returning from your dispatch entry point? If you are not
> returning STATUS_PENDING, then it will not work, even if you mark the
> IRP as pending in the completion routine, and would cause exactly the
> type of problem that you describe.
>
> Regards,
>
> Tony
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@ati.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>