Bug: MULTIPLE_IRP_COMPLETE_REQUESTS (44)

NTFSD
1

In completion routine, based on IRQL, I post request to system
DelayedWorkQueue and return STATUS_MORE_PROCESSING_REQUIRED. In thread call
back I complete the request.
I use the above logic for all kind of request.

It works for sometime, then bug checks with 44.

If I call directly without posting, it works fine.

I appreciate any help.

Thanks
Ramaraj

2

Ramaraj,

This is Shyam. I am going to ask the obvious: Did you mark the irp as
pending? It has been some time since I did actual programming on
windows.
I was working on a custom NAS box and then recently started at Allocity.
Here I recently started driver development again.

For your problem it is due to IRP_MJ_CREATE which is synchronous call,
it looks like. So, in your main dispatch routine, you should mark the
irp pending and then return status pending. The best thing to do is to
handle the IRP_MJ_CREATE as a synchronous call and not post it to worker
thread, ie. special case.

-Shyam

-----Original Message-----
From: Ramaraj Pandian [mailto:xxxxx@vormetric.com]
Sent: Thursday, February 13, 2003 1:49 PM
To: File Systems Developers
Subject: [ntfsd] Bug: MULTIPLE_IRP_COMPLETE_REQUESTS (44)

In completion routine, based on IRQL, I post request to system
DelayedWorkQueue and return STATUS_MORE_PROCESSING_REQUIRED. In thread
call
back I complete the request.
I use the above logic for all kind of request.

It works for sometime, then bug checks with 44.

If I call directly without posting, it works fine.

I appreciate any help.

Thanks
Ramaraj

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

3

Do not use the system worker thread queues. Under NT4 you can deadlock the
system very easily and it is very easy to create your own worker thread
queue. In the dispatch function, mark the IRP as pending and return
pending. In the completion routine prorogate the pending flag properly,
queue the IRP to your worker queue, and return SMPR. You then will do an
IoCompleteRequest on the IRP in your worker thread logic. Your description
of what, how and why you are doing the processing could be much more
complete.

----- Original Message -----
From: “Ramaraj Pandian”
To: “File Systems Developers”
Sent: Thursday, February 13, 2003 4:49 PM
Subject: [ntfsd] Bug: MULTIPLE_IRP_COMPLETE_REQUESTS (44)

> In completion routine, based on IRQL, I post request to system
> DelayedWorkQueue and return STATUS_MORE_PROCESSING_REQUIRED. In thread
call
> back I complete the request.
> I use the above logic for all kind of request.
>
> It works for sometime, then bug checks with 44.
>
> If I call directly without posting, it works fine.
>
> I appreciate any help.
>
> Thanks
> Ramaraj
>
>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@yoshimuni.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

4

The most common cause of this bug check in FSF is:

  • incorrect handling of the IRP in the dispatch.
    In your dispatch, if you do KeWaitxxx on an event, that is signaled by your
    completion routine, you must call IoCompleteRequest and return what WAS in
    Irp->IoStatus.Status JUST BEFORE IoCompleteRequest:
    ntRes = Irp->IoStatus.Status;
    IoCompleteRequest(Irp, IO_NO_INCREMENT);
    return ntRes;
    DO NOT return Irp->IoStatus.Status directly, as the IRP will most
    likely be invalid after IoCompleteReqeust (can remain valid if higher FSFs do
    similar logic…).
    In your completion, you MUST return STATUS_MORE_PROCESSING_REQUIRED -
    otherwise, IoCompleteRequest will bug check with this bug.
    If you do not return STATUS_MORE_PROCESSING_REQUIRED all the time, you
    must have a way for your dispatch to know that, and not call IoCompleteRequest
    then. The problem here is that you do not know what irp->IoStatus.Status is -
    you must have a way to tell your dispatch that as well.

Now, if you post to a worker queue, it’s a bit different.
What does your dispatch do? If it doesn’t wait, just call the
IoCompleteRequest in the processing routine - if you returned
STATUS_MORE_PROCESSING_REQUIRED in the completion - not otherwise.

Before I explain any other situation, you’d better post a pseudo code of
you want to do, to cut the story short:-)

Ramaraj Pandian wrote:

In completion routine, based on IRQL, I post request to system
DelayedWorkQueue and return STATUS_MORE_PROCESSING_REQUIRED. In thread call
back I complete the request.
I use the above logic for all kind of request.

It works for sometime, then bug checks with 44.

If I call directly without posting, it works fine.

I appreciate any help.

Thanks
Ramaraj

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

–
Kind regards, Dejan M. www.alfasp.com
E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.

5

Do NOT call IoMarkIrpPending in the completion if returning SMPR.

In the completion routine prorogate the pending flag properly,
queue the IRP to your worker queue, and return SMPR.

–
Kind regards, Dejan M. www.alfasp.com
E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.

6

I think that I said in the specific case I gave you need to do the mark
pending. The IRP is going to a worker thread that will complete it again,
but since the thread context is not the same as in the dispatch routine the
bit should be set to get the IoManager to queue it back to the correct
thread context.

I am not sure that I am correct, but my understanding of the mechanism
involved in IO completion suggests this is the best solution. I know the
reason for the pending flag is to tell the IoManager that a context switch
is required or not required.

----- Original Message -----
From: “Dejan Maksimovic”
To: “File Systems Developers”
Sent: Thursday, February 13, 2003 8:30 PM
Subject: [ntfsd] Re: Bug: MULTIPLE_IRP_COMPLETE_REQUESTS (44)

>
> Do NOT call IoMarkIrpPending in the completion if returning SMPR.
>
> > In the completion routine prorogate the pending flag properly,
> > queue the IRP to your worker queue, and return SMPR.
>
> –
> Kind regards, Dejan M. www.alfasp.com
> E-mail: xxxxx@alfasp.com
> Alfa Transparent File Encryptor - Transparent file encryption services.
> Alfa File Protector - File protection and hiding library for Win32
developers.
> Alfa File Monitor - File monitoring library for Win32 developers.
>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@yoshimuni.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

7

OK - I thought it was synced back to Dispatch.

“David J. Craig” wrote:

I think that I said in the specific case I gave you need to do the mark
pending. The IRP is going to a worker thread that will complete it again,
but since the thread context is not the same as in the dispatch routine the
bit should be set to get the IoManager to queue it back to the correct
thread context.

I am not sure that I am correct, but my understanding of the mechanism
involved in IO completion suggests this is the best solution. I know the
reason for the pending flag is to tell the IoManager that a context switch
is required or not required.

----- Original Message -----
From: “Dejan Maksimovic”
> To: “File Systems Developers”
> Sent: Thursday, February 13, 2003 8:30 PM
> Subject: [ntfsd] Re: Bug: MULTIPLE_IRP_COMPLETE_REQUESTS (44)
>
> >
> > Do NOT call IoMarkIrpPending in the completion if returning SMPR.
> >
> > > In the completion routine prorogate the pending flag properly,
> > > queue the IRP to your worker queue, and return SMPR.
> >
> > –
> > Kind regards, Dejan M. www.alfasp.com
> > E-mail: xxxxx@alfasp.com
> > Alfa Transparent File Encryptor - Transparent file encryption services.
> > Alfa File Protector - File protection and hiding library for Win32
> developers.
> > Alfa File Monitor - File monitoring library for Win32 developers.
> >
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@yoshimuni.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> You are currently subscribed to ntfsd as: xxxxx@alfasp.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

–
Kind regards, Dejan M. www.alfasp.com
E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.

8

Solved, I was not marking as pending.
Thank you guys

-Ramaraj

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Dejan Maksimovic
Sent: Thursday, February 13, 2003 6:53 PM
To: File Systems Developers
Subject: [ntfsd] Re: Bug: MULTIPLE_IRP_COMPLETE_REQUESTS (44)

OK - I thought it was synced back to Dispatch.

“David J. Craig” wrote:

I think that I said in the specific case I gave you need to do the mark
pending. The IRP is going to a worker thread that will complete it again,
but since the thread context is not the same as in the dispatch routine
the
bit should be set to get the IoManager to queue it back to the correct
thread context.

I am not sure that I am correct, but my understanding of the mechanism
involved in IO completion suggests this is the best solution. I know the
reason for the pending flag is to tell the IoManager that a context switch
is required or not required.

----- Original Message -----
From: “Dejan Maksimovic”
> To: “File Systems Developers”
> Sent: Thursday, February 13, 2003 8:30 PM
> Subject: [ntfsd] Re: Bug: MULTIPLE_IRP_COMPLETE_REQUESTS (44)
>
> >
> > Do NOT call IoMarkIrpPending in the completion if returning SMPR.
> >
> > > In the completion routine prorogate the pending flag properly,
> > > queue the IRP to your worker queue, and return SMPR.
> >
> > –
> > Kind regards, Dejan M. www.alfasp.com
> > E-mail: xxxxx@alfasp.com
> > Alfa Transparent File Encryptor - Transparent file encryption services.
> > Alfa File Protector - File protection and hiding library for Win32
> developers.
> > Alfa File Monitor - File monitoring library for Win32 developers.
> >
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@yoshimuni.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> You are currently subscribed to ntfsd as: xxxxx@alfasp.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

–
Kind regards, Dejan M. www.alfasp.com
E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32
developers.
Alfa File Monitor - File monitoring library for Win32 developers.

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

9

This is a good reason to take a course in writing Windows NT drivers. Maybe
a good book that explains the reasons for the various “rules” would help. I
have started reading Walter Oney’s 2nd Edition, but I am not sure if he
covers it with the reasons and variations that can occur. When I learned
from OSR that the primary/only reason for marking an IRP pending was to get
the IoManager to switch thread context, many of these rules became much
easier to understand. Of course there are a lot of rules/problems that
aren’t well documented, especially in the file systems arena.

There are also some interesting questions about some hardware or pseudo
hardware drivers that don’t fit the normal models.

----- Original Message -----
From: “Ramaraj Pandian”
To: “File Systems Developers”
Sent: Thursday, February 13, 2003 10:02 PM
Subject: [ntfsd] Re: Bug: MULTIPLE_IRP_COMPLETE_REQUESTS (44)

> Solved, I was not marking as pending.
> Thank you guys
>
> -Ramaraj
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Dejan Maksimovic
> Sent: Thursday, February 13, 2003 6:53 PM
> To: File Systems Developers
> Subject: [ntfsd] Re: Bug: MULTIPLE_IRP_COMPLETE_REQUESTS (44)
>
>
>
> OK - I thought it was synced back to Dispatch.
>
> “David J. Craig” wrote:
>
> > I think that I said in the specific case I gave you need to do the mark
> > pending. The IRP is going to a worker thread that will complete it
again,
> > but since the thread context is not the same as in the dispatch routine
> the
> > bit should be set to get the IoManager to queue it back to the correct
> > thread context.
> >
> > I am not sure that I am correct, but my understanding of the mechanism
> > involved in IO completion suggests this is the best solution. I know
the
> > reason for the pending flag is to tell the IoManager that a context
switch
> > is required or not required.
> >
> > ----- Original Message -----
> > From: “Dejan Maksimovic”
> > To: “File Systems Developers”
> > Sent: Thursday, February 13, 2003 8:30 PM
> > Subject: [ntfsd] Re: Bug: MULTIPLE_IRP_COMPLETE_REQUESTS (44)
> >
> > >
> > > Do NOT call IoMarkIrpPending in the completion if returning SMPR.
> > >
> > > > In the completion routine prorogate the pending flag properly,
> > > > queue the IRP to your worker queue, and return SMPR.
> > >
> > > –
> > > Kind regards, Dejan M. www.alfasp.com
> > > E-mail: xxxxx@alfasp.com
> > > Alfa Transparent File Encryptor - Transparent file encryption
services.
> > > Alfa File Protector - File protection and hiding library for Win32
> > developers.
> > > Alfa File Monitor - File monitoring library for Win32 developers.
> > >
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntfsd as: xxxxx@yoshimuni.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@alfasp.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> –
> Kind regards, Dejan M. www.alfasp.com
> E-mail: xxxxx@alfasp.com
> Alfa Transparent File Encryptor - Transparent file encryption services.
> Alfa File Protector - File protection and hiding library for Win32
> developers.
> Alfa File Monitor - File monitoring library for Win32 developers.
>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@vormetric.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@yoshimuni.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com