MULTIPLE_IRP_COMPLETE_REQUESTS Stop Error

NTFSD
1

In my HSM minifilter driver, if my user-mode service cannot retrieve a file (indicate by a reparse point) from remote storage, it sends message to the minifilter indicating so. The minifilter in the MessageNotifyCallback function will remove the IRP from a cancel-safe queue and call FltCompletePendedPostOperation on that callback data. I get a Stop error not when my driver calls FltCompletePendedPostOperation, but usually a few lines of code after, or right when my MessageNotifyCallback function exits.

Any thoughts on what's going on with ntoskrnl.exe? Or how to avoid this altogether? Thanks.

Bill

*** Fatal System Error: 0x00000044
(0x81275648,0x00001B1F,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.

Connected to Windows 2000 2195 x86 compatible target, ptr64 FALSE
Loading Kernel Symbols
..............................................................................................
Loading User Symbols
......................................................................
Loading unloaded module list
...
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 44, {81275648, 1b1f, 0, 0}

*** ERROR: Symbol file could not be found. Defaulted to export symbols for COMCTL32.DLL -
Probably caused by : ntoskrnl.exe ( nt!IopParseDevice+b4f )

Followup: MachineOwner

nt!RtlpBreakWithStatusInstruction:
80455554 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: 81275648, Address of the IRP
Arg2: 00001b1f
Arg3: 00000000
Arg4: 00000000

Debugging Details:

IRP_ADDRESS: 81275648

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x44

PROCESS_NAME: explorer.exe

LAST_CONTROL_TRANSFER: from 8042a9e7 to 80455554

STACK_TEXT:
f1cd74c4 8042a9e7 00000003 f1cd750c 81275648 nt!RtlpBreakWithStatusInstruction
f1cd74f4 8042afda 00000003 00000000 81275648 nt!KiBugCheckDebugBreak+0x31
f1cd7880 8041e658 00000044 81275648 00001b1f nt!KeBugCheckEx+0x390
f1cd78a8 8041e634 81275648 804bfbb9 81275648 nt!IopFreeIrp+0x20
f1cd78b0 804bfbb9 81275648 804825a0 804bf06a nt!IoFreeIrp+0xa
f1cd7a44 80450893 8181ebb0 00000000 f1cd7afc nt!IopParseDevice+0xb4f
f1cd7abc 804d5b3e 00000000 8181cc00 00000040 nt!ObpLookupObjectName+0x4e7
f1cd7bcc 8049fadd 00000000 00000000 00000001 nt!ObOpenObjectByName+0xc8
f1cd7ca8 8049f682 0139e5d0 00120089 0139e590 nt!IopCreateFile+0x407
f1cd7cf0 804a719a 0139e5d0 00120089 0139e590 nt!IoCreateFile+0x36
f1cd7d30 80465014 0139e5d0 00120089 0139e590 nt!NtCreateFile+0x2e
f1cd7d30 77f88283 0139e5d0 00120089 0139e590 nt!KiSystemService+0xc4
0139e558 7cecc4fd 0139e5d0 00120089 0139e590 ntdll!NtCreateFile+0xb
0139e5c4 7cecb36f 0139e5f0 00000000 00000040 OLE32!CNtfsStorage::OpenNtFileHandle+0x82
0139e5fc 7ceb8f6f 0139e970 0139e8f8 00000000 OLE32!CNtfsStorage::IsNffAppropriate+0x40
0139e820 7ceb921d 0139e970 00000000 00000020 OLE32!DfOpenStorageEx+0x96
0139e854 7cf82ab3 0139e970 00000020 00000004 OLE32!StgOpenStorageEx+0xa9
0139e87c 7cfdaa26 0139e970 00000020 00000004 SHELL32!StgOpenStorageEx+0x3f
0139e8c8 7cfe3c99 0139e970 00000020 00000000 SHELL32!SHStgOpenStorageW+0xb8
0139e904 7cf8faf2 000dea7c 0139f5cc 0139e960 SHELL32!CDocFileColumns::GetItemData+0xc9
0139eb94 7cf8fbed 000ed058 00000005 0139f5cc SHELL32!FS_GetDetailsEx+0x1fe
0139eba8 7cff6384 000ed05c 000ce830 0139f5cc SHELL32!CFSFolder_GetDetailsEx+0x19
0139f604 7cf5722a 0139f778 7cf5d672 000e4380 SHELL32!CInfoTip::_GetInfoTipFromItem+0x89
0139f60c 7cf5d672 000e4380 00000000 0139f778 SHELL32!CInfoTip::GetInfoTip+0x19
0139f770 7cf5d5b4 00000000 000e4380 0139f8f8 SHELL32!DV_DoDefaultStatusBar+0xa2
0139f780 7cf5cfdc 000f38d8 00000000 0139f9c8 SHELL32!DV_UpdateStatusBar+0x29
0139f8f8 77e4158f 0003010c 000004a8 00000000 SHELL32!DefView_WndProc+0xcc3
0139f9b0 71729ac8 0139f9c8 00000005 00000000 USER32!__ClientCharToWchar+0x38
WARNING: Stack unwind information not available. Following frames may be wrong.
00000000 00000000 00000000 00000000 00000000 COMCTL32!GetMUILanguage+0x42e

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!IopParseDevice+b4f
804bfbb9 8a8d18ffffff mov cl,byte ptr [ebp-0E8h]

SYMBOL_STACK_INDEX: 5

SYMBOL_NAME: nt!IopParseDevice+b4f

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntoskrnl.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 45069e6e

FAILURE_BUCKET_ID: 0x44_nt!IopParseDevice+b4f

BUCKET_ID: 0x44_nt!IopParseDevice+b4f

Followup: MachineOwner

2

You aren’t returning the correct value in your dispatch (preop)
function. Thus, you complete it once (FltCompletePendedPostOperation)
and then it returns to the I/O Manager without STATUS_PENDING being
returned so it is completed again.

The only way I can envision this happening is that you aren’t returning
the correct value in your preop routine.

Tony

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

3

You don’t say anything about the logic in your post-operation callback
in your email, but by any chance did you return
FLT_POSTOP_FINISHED_PROCESSING in your post-operation callback and not
FLT_POSTOP_MORE_PROCESSING_REQUIRED?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@edsiohio.com
Sent: Tuesday, January 30, 2007 12:18 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] MULTIPLE_IRP_COMPLETE_REQUESTS Stop Error

In my HSM minifilter driver, if my user-mode service cannot
retrieve a file (indicate by a reparse point) from remote
storage, it sends message to the minifilter indicating so.
The minifilter in the MessageNotifyCallback function will
remove the IRP from a cancel-safe queue and call
FltCompletePendedPostOperation on that callback data. I get
a Stop error not when my driver calls
FltCompletePendedPostOperation, but usually a few lines of
code after, or right when my MessageNotifyCallback function exits.

Any thoughts on what’s going on with ntoskrnl.exe? Or how to
avoid this altogether? Thanks.

[big snip]

4

In my post-operation calback, I return FLT_POSTOP_MORE_PROCESSING_REQUIRED if it is one of my reparse points, then insert it into a CSQ. Then I message a user-mode service to retrieve the file from remote storage. The user-mode service then replies to the minifilter either to re-issue the IRP or to just complete it (if the file retrieval failed).

Even if I just test with a text file using notepad, the application will block until the file is retrieved (if it does get retrieved). So I can’t have returned FLT_POSTOP_FINISHED_PROCESSING because the application wouldn’t block and would error immediately.

Does FltCompletePendedPostOperation need to be called in a work item? That’s how I normally issue completions, and that seems to work fine. I don’t know why that would matter, though, seeing how it can be called IRQL <= DISPATCH_LEVEL.

Any ideas?

5

I believe the MULTIPLE_IRP_COMPLETE_REQUESTS Stop problem may be due to duplicate messages that may be sent from user-mode. I am going to investigate and hopefully this will be the case. Please ignore this thread for now.

Thanks for the help, though,

Bill