MULTIPLE_IRP_COMPLETE_REQUESTS (44)

NTDEV
1

Hello everybody,

I was trying to make asynchrous reads from the application on the driver. At
the driver side I am trying to queue the IRP. My system crashed with the
code MULTIPLE_IRP_COMPLETE_REQUESTS.

The following is the error message from the debugger. Can anyone give some
comments?

Thanks a lot!

Yuanhui

*** Fatal System Error: 0x00000044

(0xFFAAF528,0x00000CCA,0x00000000,0x00000000)

Break instruction exception - code 80000003 (first chance)

A fatal system error has occurred.

Debugger entered on first try; Bugcheck callbacks have not been invoked.

A fatal system error has occurred.

****************************************************************************
***

* *

* Bugcheck Analysis *

* *

****************************************************************************
***

Use !analyze -v to get detailed debugging information.

BugCheck 44, {ffaaf528, cca, 0, 0}

Probably caused by : ndishk.sys ( ndishk!NdishkDispatchRequest+18b )

Followup: MachineOwner

nt!RtlpBreakWithStatusInstruction:

80452e70 cc int 3

kd> !analyze -v

****************************************************************************
***

* *

* Bugcheck Analysis *

* *

****************************************************************************
***

MULTIPLE_IRP_COMPLETE_REQUESTS (44)

A driver has requested that an IRP be completed (IoCompleteRequest()), but

the packet has already been completed. This is a tough bug to find because

the easiest case, a driver actually attempted to complete its own packet

twice, is generally not what happened. Rather, two separate drivers each

believe that they own the packet, and each attempts to complete it. The

first actually works, and the second fails. Tracking down which drivers

in the system actually did this is difficult, generally because the trails

of the first driver have been covered by the second. However, the driver

stack for the current request can be found by examining the DeviceObject

fields in each of the stack locations.

Arguments:

Arg1: ffaaf528, Address of the IRP

Arg2: 00000cca

Arg3: 00000000

Arg4: 00000000

Debugging Details:

IRP_ADDRESS: ffaaf528

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x44

LAST_CONTROL_TRANSFER: from 8042bcb9 to 80452e70

STACK_TEXT:

fe6787e8 8042bcb9 00000003 fe678830 ffaaf528
nt!RtlpBreakWithStatusInstruction

fe678818 8042c068 00000003 ff0e43b0 ffaaf528 nt!KiBugCheckDebugBreak+0x31

fe678ba0 8041f68a 00000000 ffaaf528 00000cca nt!KeBugCheckEx+0x37b

fe678bd4 fc698e0e 80000014 0000000e 5deb0025 nt!IopfCompleteRequest+0x32

fe678c0c 8041f54b ff0e43b0 ffaaf528 ffaaf528
ndishk!NdishkDispatchRequest+0x18b [C:\NDISPIM\BASE\NTPIMEB\iodev.c @ 207]

fe678c20 804ba5e8 ffa74392 00000000 ffaaf528 nt!IopfCallDriver+0x35

fe678c34 804ac5de ff0e43b0 ffaaf528 ffa2c768
nt!IopSynchronousServiceTail+0x60

fe678d00 804a8f1e 0000002c 00000000 00000000 nt!IopXxxControlFile+0x5e4

fe678d34 80461691 0000002c 00000000 00000000 nt!NtDeviceIoControlFile+0x28

fe678d34 77f96be2 0000002c 00000000 00000000 nt!KiSystemService+0xc4

0006ed34 0040181c 0000002c 80000014 0006edac ntdll!ZwDeviceIoControlFile+0xb

WARNING: Frame IP not in any known module. Following frames may be wrong.

0006ed34 0040181c 0000002c 80000014 0006edac 0x40181c

0006eee0 00401909 00000000 00000000 7ffdf000 0x40181c

0012ff80 00402429 00000002 00300ea0 00300df0 0x401909

0012ffc0 77e87903 00000000 00000000 7ffdf000 0x402429

0012fff0 00000000 00402340 00000000 000000c8 0x77e87903

FOLLOWUP_IP:

ndishk!NdishkDispatchRequest+18b

fc698e0e 8b45f0 mov eax,[ebp-0x10]

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: ndishk!NdishkDispatchRequest+18b

MODULE_NAME: ndishk

IMAGE_NAME: ndishk.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3d8b7b90

STACK_COMMAND: kb

BUCKET_ID: 0x44_ndishk!NdishkDispatchRequest+18b

Followup: MachineOwner

2

Umm…looks like you completed the same IRP twice.

–
Bill McKenzie
Windows DDK MVP
OSR - Windows System Software Development, Training, and Consulting

“Yuanhui Zhao” wrote in message news:xxxxx@ntdev…
>
> Hello everybody,
>
> I was trying to make asynchrous reads from the application on the driver.
At
> the driver side I am trying to queue the IRP. My system crashed with the
> code MULTIPLE_IRP_COMPLETE_REQUESTS.
>
> The following is the error message from the debugger. Can anyone give some
> comments?
>
> Thanks a lot!
>
> Yuanhui
>
> Fatal System Error: 0x00000044
>
> (0xFFAAF528,0x00000CCA,0x00000000,0x00000000)
>
> Break instruction exception - code 80000003 (first chance)
>
> A fatal system error has occurred.
>
> Debugger entered on first try; Bugcheck callbacks have not been invoked.
>
> A fatal system error has occurred.
>
>

>
>
> *
>
> * Bugcheck Analysis
>
> *
>
>
>
>
> Use !analyze -v to get detailed debugging information.
>
> BugCheck 44, {ffaaf528, cca, 0, 0}
>
> Probably caused by : ndishk.sys ( ndishk!NdishkDispatchRequest+18b )
>
> Followup: MachineOwner
>
> ---------
>
> nt!RtlpBreakWithStatusInstruction:
>
> 80452e70 cc int 3
>
> kd> !analyze -v
>
>

>
>
> *
>
> * Bugcheck Analysis
>
> *
>
>
> ***
>
> MULTIPLE_IRP_COMPLETE_REQUESTS (44)
>
> A driver has requested that an IRP be completed (IoCompleteRequest()), but
>
> the packet has already been completed. This is a tough bug to find because
>
> the easiest case, a driver actually attempted to complete its own packet
>
> twice, is generally not what happened. Rather, two separate drivers each
>
> believe that they own the packet, and each attempts to complete it. The
>
> first actually works, and the second fails. Tracking down which drivers
>
> in the system actually did this is difficult, generally because the trails
>
> of the first driver have been covered by the second. However, the driver
>
> stack for the current request can be found by examining the DeviceObject
>
> fields in each of the stack locations.
>
> Arguments:
>
> Arg1: ffaaf528, Address of the IRP
>
> Arg2: 00000cca
>
> Arg3: 00000000
>
> Arg4: 00000000
>
> Debugging Details:
>
> ------------------
>
>
>
> IRP_ADDRESS: ffaaf528
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0x44
>
> LAST_CONTROL_TRANSFER: from 8042bcb9 to 80452e70
>
> STACK_TEXT:
>
> fe6787e8 8042bcb9 00000003 fe678830 ffaaf528
> nt!RtlpBreakWithStatusInstruction
>
> fe678818 8042c068 00000003 ff0e43b0 ffaaf528 nt!KiBugCheckDebugBreak+0x31
>
> fe678ba0 8041f68a 00000000 ffaaf528 00000cca nt!KeBugCheckEx+0x37b
>
> fe678bd4 fc698e0e 80000014 0000000e 5deb0025 nt!IopfCompleteRequest+0x32
>
> fe678c0c 8041f54b ff0e43b0 ffaaf528 ffaaf528
> ndishk!NdishkDispatchRequest+0x18b [C:\NDISPIM\BASE\NTPIMEB\iodev.c @ 207]
>
> fe678c20 804ba5e8 ffa74392 00000000 ffaaf528 nt!IopfCallDriver+0x35
>
> fe678c34 804ac5de ff0e43b0 ffaaf528 ffa2c768
> nt!IopSynchronousServiceTail+0x60
>
> fe678d00 804a8f1e 0000002c 00000000 00000000 nt!IopXxxControlFile+0x5e4
>
> fe678d34 80461691 0000002c 00000000 00000000 nt!NtDeviceIoControlFile+0x28
>
> fe678d34 77f96be2 0000002c 00000000 00000000 nt!KiSystemService+0xc4
>
> 0006ed34 0040181c 0000002c 80000014 0006edac
ntdll!ZwDeviceIoControlFile+0xb
>
> WARNING: Frame IP not in any known module. Following frames may be wrong.
>
> 0006ed34 0040181c 0000002c 80000014 0006edac 0x40181c
>
> 0006eee0 00401909 00000000 00000000 7ffdf000 0x40181c
>
> 0012ff80 00402429 00000002 00300ea0 00300df0 0x401909
>
> 0012ffc0 77e87903 00000000 00000000 7ffdf000 0x402429
>
> 0012fff0 00000000 00402340 00000000 000000c8 0x77e87903
>
>
>
> FOLLOWUP_IP:
>
> ndishk!NdishkDispatchRequest+18b
>
> fc698e0e 8b45f0 mov eax,[ebp-0x10]
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: ndishk!NdishkDispatchRequest+18b
>
> MODULE_NAME: ndishk
>
> IMAGE_NAME: ndishk.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 3d8b7b90
>
> STACK_COMMAND: kb
>
> BUCKET_ID: 0x44_ndishk!NdishkDispatchRequest+18b
>
> Followup: MachineOwner
>
> ---------
>
>
>
>
>

3

You need to make sure that

  1. You did not complete the IRP when it is on your queue.
  2. You called IoMarkIrpPending on IRP and return STATUS_PENDING from your
    dispatch routine
  3. If you forwarded the IRP to the device under you, you must set completion
    routine so you can dequeue the IRP on your queue and do proper completion of
    the IRP

Cheer.

Bi

-----Original Message-----
From: Yuanhui Zhao [mailto:xxxxx@nexland.com]
Sent: Friday, September 20, 2002 2:19 PM
To: NT Developers Interest List
Subject: [ntdev] MULTIPLE_IRP_COMPLETE_REQUESTS (44)

Hello everybody,

I was trying to make asynchrous reads from the application on the driver. At
the driver side I am trying to queue the IRP. My system crashed with the
code MULTIPLE_IRP_COMPLETE_REQUESTS.

The following is the error message from the debugger. Can anyone give some
comments?

Thanks a lot!

Yuanhui

*** Fatal System Error: 0x00000044

(0xFFAAF528,0x00000CCA,0x00000000,0x00000000)

Break instruction exception - code 80000003 (first chance)

A fatal system error has occurred.

Debugger entered on first try; Bugcheck callbacks have not been invoked.

A fatal system error has occurred.

****************************************************************************
***

* *

* Bugcheck Analysis *

* *

****************************************************************************
***

Use !analyze -v to get detailed debugging information.

BugCheck 44, {ffaaf528, cca, 0, 0}

Probably caused by : ndishk.sys ( ndishk!NdishkDispatchRequest+18b )

Followup: MachineOwner

nt!RtlpBreakWithStatusInstruction:

80452e70 cc int 3

kd> !analyze -v

****************************************************************************
***

* *

* Bugcheck Analysis *

* *

****************************************************************************
***

MULTIPLE_IRP_COMPLETE_REQUESTS (44)

A driver has requested that an IRP be completed (IoCompleteRequest()), but

the packet has already been completed. This is a tough bug to find because

the easiest case, a driver actually attempted to complete its own packet

twice, is generally not what happened. Rather, two separate drivers each

believe that they own the packet, and each attempts to complete it. The

first actually works, and the second fails. Tracking down which drivers

in the system actually did this is difficult, generally because the trails

of the first driver have been covered by the second. However, the driver

stack for the current request can be found by examining the DeviceObject

fields in each of the stack locations.

Arguments:

Arg1: ffaaf528, Address of the IRP

Arg2: 00000cca

Arg3: 00000000

Arg4: 00000000

Debugging Details:

IRP_ADDRESS: ffaaf528

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x44

LAST_CONTROL_TRANSFER: from 8042bcb9 to 80452e70

STACK_TEXT:

fe6787e8 8042bcb9 00000003 fe678830 ffaaf528
nt!RtlpBreakWithStatusInstruction

fe678818 8042c068 00000003 ff0e43b0 ffaaf528 nt!KiBugCheckDebugBreak+0x31

fe678ba0 8041f68a 00000000 ffaaf528 00000cca nt!KeBugCheckEx+0x37b

fe678bd4 fc698e0e 80000014 0000000e 5deb0025 nt!IopfCompleteRequest+0x32

fe678c0c 8041f54b ff0e43b0 ffaaf528 ffaaf528
ndishk!NdishkDispatchRequest+0x18b [C:\NDISPIM\BASE\NTPIMEB\iodev.c @ 207]

fe678c20 804ba5e8 ffa74392 00000000 ffaaf528 nt!IopfCallDriver+0x35

fe678c34 804ac5de ff0e43b0 ffaaf528 ffa2c768
nt!IopSynchronousServiceTail+0x60

fe678d00 804a8f1e 0000002c 00000000 00000000 nt!IopXxxControlFile+0x5e4

fe678d34 80461691 0000002c 00000000 00000000 nt!NtDeviceIoControlFile+0x28

fe678d34 77f96be2 0000002c 00000000 00000000 nt!KiSystemService+0xc4

0006ed34 0040181c 0000002c 80000014 0006edac ntdll!ZwDeviceIoControlFile+0xb

WARNING: Frame IP not in any known module. Following frames may be wrong.

0006ed34 0040181c 0000002c 80000014 0006edac 0x40181c

0006eee0 00401909 00000000 00000000 7ffdf000 0x40181c

0012ff80 00402429 00000002 00300ea0 00300df0 0x401909

0012ffc0 77e87903 00000000 00000000 7ffdf000 0x402429

0012fff0 00000000 00402340 00000000 000000c8 0x77e87903

FOLLOWUP_IP:

ndishk!NdishkDispatchRequest+18b

fc698e0e 8b45f0 mov eax,[ebp-0x10]

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: ndishk!NdishkDispatchRequest+18b

MODULE_NAME: ndishk

IMAGE_NAME: ndishk.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3d8b7b90

STACK_COMMAND: kb

BUCKET_ID: 0x44_ndishk!NdishkDispatchRequest+18b

Followup: MachineOwner

You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%

4

> Bi Chen wrote:

  1. If you forwarded the IRP to the device under you, you must set
    completion routine so you can dequeue the IRP on your queue and do
    proper completion of the IRP

This is very bad advice. One must remove the IRP from the queue (and
clear the cancel routine pointer) before sending it to another driver.

–
Walter Oney, Consulting and Training
Check out new US seminar schedule at http://www.oneysoft.com

5

Sorry, I am wording is confusing. What I meant was before he forward IRP to
device in stack below him, he must set up an completion routine. And in
the completion routine, he can dequeue IRP and do proper completion of the
IRP.

Walter. It is always refresh to read your comment and your book.

Thanks.

Bi

-----Original Message-----
From: Walter Oney [mailto:xxxxx@oneysoft.com]
Sent: Saturday, September 21, 2002 5:15 AM
To: NT Developers Interest List
Subject: [ntdev] Re: MULTIPLE_IRP_COMPLETE_REQUESTS (44)

Bi Chen wrote:
3. If you forwarded the IRP to the device under you, you must set
completion routine so you can dequeue the IRP on your queue and do
proper completion of the IRP

This is very bad advice. One must remove the IRP from the queue (and
clear the cancel routine pointer) before sending it to another driver.

–
Walter Oney, Consulting and Training
Check out new US seminar schedule at http://www.oneysoft.com

You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%

6

> Bi Chen wrote:

Sorry, I am wording is confusing. What I meant was before he forward
IRP to device in stack below him, he must set up an completion
routine. And in the completion routine, he can dequeue IRP and do
proper completion of the IRP.

Okay, I think I see what you’re driving at. Something like this:

Dispatch routine:

IoMarkIrpPending()

return STATUS_PENDING;

Queue manager:
-------------

enqueue routine either sends IRP straight to StartIo, or
queues IRP (with cancel routine)

dequeue-next routine clears cancel routine before calling StartIo

StartIo routine:
---------------

IoCopyCurrentIrpStackLocationToNext()
IoSetCompletionRoutine()
IoCallDriver()

Completion routine:
-------------------

KeInsertQueueDpc(completion-dpc)
return STATUS_SUCCESS;

Completion-dpc routine:
----------------------



—

There are other arrangements of routines that would also work. The point
of the example is that the completion routine calls the queue manager
routine that will dequeue the next IRP. The current IRP has long since
been removed from the queue. Note that recursion through StartIo and the
completion routine is a real possibility and can be addressed by using a
DPC as shown. You could optimize this a bit in the completion routine
like this:

if (Irp->PendingReturned)

else
KeInsertQueueDpc(completion-dpc)

This avoids recursion into StartIo in a synchronous completion case.

There is another issue here, too, and that relates to how we handle
IRP_MN_REMOVE_DEVICE and when exactly we call IoDetachDevice. The above
sketch would be safe for the vast majority of IRPs, which are related to
an open FILE_OBJECT. This is the wrong context to delve into other
cases, concerning which I’ve written many confusing paragraphs for the
2d edition of my WDM book (due out in January, if you care).

–
Walter Oney, Consulting and Training
Check out new US seminar schedule at http://www.oneysoft.com

7

> This avoids recursion into StartIo in a synchronous completion case.

I have written my own queue instead of StartIo to avoid recursion.
XP also has IoSetStartIoAttributes, but I have too many tasks with
earlier NT versions.

Max

8

Thanks for all the comments I received on this issue. The problem was I
tried to call IoCompleteRequest twice.

Yuanhui