Two mini filters may conflict (includes a guidance to crash)

Hi.

I came across a crash where my mini filter (AV) conflicts with another third
party mini filter (no AV). From my point of view neither of both is
misbehaving. But hey, what do I know?

My filter issues a read IO and another filter below completes this request
with status “lock conflict”-> BANG! Instead of boring you with the details I
did slight modifications on two mini filter samples to reproduce the crash.
I tested with XP SP2. Here’s the guide:

  1. Take the scanner sample

  2. In scanner.c: switch “FltReadFile” from sync to async mode by providing a
    CallbackRoutine. Just KeWaitForSingleObject for the call to complete

  3. Install and run the modified scanner sample

  4. Take the passThrough (mini) sample

  5. In passThrough.c: provide a separate PreOp function for IRP_MJ_READ (e.g.
    “PtPreOperationPassThroughRead”)

  6. Implement “PtPreOperationPassThroughRead” this way that it will complete
    every file named “foo.txt” with STATUS_FILE_LOCK_CONFLICT

  7. Install and run the modified passThrough sample

Any vetos so far? Finally touch a file “foo.txt” and you will receive an
instant bugcheck:

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: 81d8fe48, Address of the IRP
Arg2: 00000d62
Arg3: 00000000
Arg4: 00000000

Debugging Details:

IRP_ADDRESS: 81d8fe48

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x44

PROCESS_NAME: notepad.exe

LAST_CONTROL_TRANSFER: from 805360bf to 804e2a52

STACK_TEXT:
f629df38 805360bf 00000003 f629e294 00000000
nt!RtlpBreakWithStatusInstruction
f629df84 80536b96 00000003 c0000054 81d8fe48 nt!KiBugCheckDebugBreak+0x19
f629e364 805371aa 00000044 81d8fe48 00000d62 nt!KeBugCheck2+0x574
f629e384 80520683 00000044 81d8fe48 00000d62 nt!KeBugCheckEx+0x1b
f629e3bc f845e735 f629e3f0 f845ed6b 81d8fe48 nt!IopfCompleteRequest+0x2ce
f629e3c4 f845ed6b 81d8fe48 c0000054 00000000 fltMgr!FltpCompleteRequest+0x2d
f629e3f0 f845fbd9 f629e410 c0000054 00000000
fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x10f
f629e428 f845fc12 81bf6e84 f845f966 81ee94e0
fltMgr!FltPerformAsynchronousIo+0xcf
f629e43c f845fd57 81bf6e84 f62f36a8 f629e4d8
fltMgr!FltpPerformAsynchronousIoWrapper+0x2c
f629e470 f62f37fa 81bf6e84 01d4a818 0129e4f0 fltMgr!FltReadFile+0x12d
f629e93c f62f3970 81d64a28 81d4a818 f629e96f
scanner!ScannerpScanFileInUserMode+0x126
[c:\users\frank\desktop\test\test\scanner\filter\scanner.c @ 1177]
f629e964 f845bfa1 01c44e84 f629e988 00000000 scanner!ScannerPostCreate+0x76
[c:\users\frank\desktop\test\test\scanner\filter\scanner.c @ 688]
f629e9cc f845e3ea 00c44e28 00000000 81c44e28
fltMgr!FltpPerformPostCallbacks+0x1c5
f629e9e0 f845e817 81c44e28 81dc0e48 f629ea20
fltMgr!FltpProcessIoCompletion+0x10
f629e9f0 f845eec5 81c030c8 81dc0e48 81c44e28
fltMgr!FltpPassThroughCompletion+0x89
f629ea20 f846b153 f629ea40 00000000 00000000
fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x269
f629ea5c 804e13d9 81c030c8 81dc0fd8 81dc0e48 fltMgr!FltpCreate+0x1e3
f629ea6c 8057ccc7 81fcb8e8 81d53364 f629ec04 nt!IopfCallDriver+0x31
f629eb4c 8056c063 81fcb900 00000000 81d532c0 nt!IopParseDevice+0xa58
f629ebc4 8056f2a8 00000000 f629ec04 00000040 nt!ObpLookupObjectName+0x53c
f629ec18 8057d2d3 00000000 00000000 00000001 nt!ObOpenObjectByName+0xea
f629ec94 8057d3a2 0007fd94 80100080 0007fd34 nt!IopCreateFile+0x407
f629ecf0 8057d3e5 0007fd94 80100080 0007fd34 nt!IoCreateFile+0x8e
f629ed30 804dd99f 0007fd94 80100080 0007fd34 nt!NtCreateFile+0x30
f629ed30 7c91eb94 0007fd94 80100080 0007fd34 nt!KiFastCallEntry+0xfc
0007fcf0 7c91d68e 7c810b2c 0007fd94 80100080 ntdll!KiFastSystemCallRet
0007fcf4 7c810b2c 0007fd94 80100080 0007fd34 ntdll!NtCreateFile+0xc
0007fd8c 010033b0 00000000 80000000 00000003 kernel32!CreateFileW+0x35f
0007fdb4 01003416 00000233 0007fde0 0100383d notepad!FileDragOpen+0x32
0007fdc0 0100383d 0083001c 000300e4 0007fe48 notepad!doDrop+0x3a
0007fde0 77d18734 000300e4 00000233 0083001c notepad!NPWndProc+0x414
0007fe0c 77d18816 01003429 000300e4 00000233 USER32!InternalCallWinProc+0x28
0007fe74 77d189cd 00000000 01003429 000300e4
USER32!UserCallWinProcCheckWow+0x150
0007fed4 77d18a10 0007fefc 00000000 0007ff1c
USER32!DispatchMessageWorker+0x306
0007fee4 01002a12 0007fefc 00000000 7c80b529 USER32!DispatchMessageW+0xf
0007ff1c 01007511 01000000 00000000 000a2332 notepad!WinMain+0xdc
0007ffc0 7c816d4f 00efd8b0 00000018 7ffde000 notepad!WinMainCRTStartup+0x174
0007fff0 00000000 0100739d 00000000 78746341 kernel32!BaseProcessStart+0x23

STACK_COMMAND: kb

FOLLOWUP_IP:
scanner!ScannerpScanFileInUserMode+126
[c:\users\frank\desktop\test\test\scanner\filter\scanner.c @ 1177]
f62f37fa 8985d8fbffff mov dword ptr [ebp-428h],eax

I forgot to mention: altitude of passThrough filter has to changed so that
it will be lower than the scanner filter

“Frank” wrote news:xxxxx@ntfsd…
> Hi.
>
> I came across a crash where my mini filter (AV) conflicts with another
> third party mini filter (no AV). From my point of view neither of both is
> misbehaving. But hey, what do I know?
>
> My filter issues a read IO and another filter below completes this request
> with status “lock conflict”-> BANG! Instead of boring you with the details
> I did slight modifications on two mini filter samples to reproduce the
> crash. I tested with XP SP2. Here’s the guide:
>
> 1. Take the scanner sample
>
> 2. In scanner.c: switch “FltReadFile” from sync to async mode by providing
> a CallbackRoutine. Just KeWaitForSingleObject for the call to complete
>
> 3. Install and run the modified scanner sample
>
> 4. Take the passThrough (mini) sample
>
> 5. In passThrough.c: provide a separate PreOp function for IRP_MJ_READ
> (e.g. “PtPreOperationPassThroughRead”)
>
> 6. Implement “PtPreOperationPassThroughRead” this way that it will
> complete every file named “foo.txt” with STATUS_FILE_LOCK_CONFLICT
>
> 7. Install and run the modified passThrough sample
>
> Any vetos so far? Finally touch a file “foo.txt” and you will receive an
> instant bugcheck:
>
>
> 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: 81d8fe48, Address of the IRP
> Arg2: 00000d62
> Arg3: 00000000
> Arg4: 00000000
>
> Debugging Details:
> ------------------
>
> IRP_ADDRESS: 81d8fe48
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0x44
>
> PROCESS_NAME: notepad.exe
>
> LAST_CONTROL_TRANSFER: from 805360bf to 804e2a52
>
> STACK_TEXT:
> f629df38 805360bf 00000003 f629e294 00000000
> nt!RtlpBreakWithStatusInstruction
> f629df84 80536b96 00000003 c0000054 81d8fe48 nt!KiBugCheckDebugBreak+0x19
> f629e364 805371aa 00000044 81d8fe48 00000d62 nt!KeBugCheck2+0x574
> f629e384 80520683 00000044 81d8fe48 00000d62 nt!KeBugCheckEx+0x1b
> f629e3bc f845e735 f629e3f0 f845ed6b 81d8fe48 nt!IopfCompleteRequest+0x2ce
> f629e3c4 f845ed6b 81d8fe48 c0000054 00000000
> fltMgr!FltpCompleteRequest+0x2d
> f629e3f0 f845fbd9 f629e410 c0000054 00000000
> fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x10f
> f629e428 f845fc12 81bf6e84 f845f966 81ee94e0
> fltMgr!FltPerformAsynchronousIo+0xcf
> f629e43c f845fd57 81bf6e84 f62f36a8 f629e4d8
> fltMgr!FltpPerformAsynchronousIoWrapper+0x2c
> f629e470 f62f37fa 81bf6e84 01d4a818 0129e4f0 fltMgr!FltReadFile+0x12d
> f629e93c f62f3970 81d64a28 81d4a818 f629e96f
> scanner!ScannerpScanFileInUserMode+0x126
> [c:\users\frank\desktop\test\test\scanner\filter\scanner.c @ 1177]
> f629e964 f845bfa1 01c44e84 f629e988 00000000
> scanner!ScannerPostCreate+0x76
> [c:\users\frank\desktop\test\test\scanner\filter\scanner.c @ 688]
> f629e9cc f845e3ea 00c44e28 00000000 81c44e28
> fltMgr!FltpPerformPostCallbacks+0x1c5
> f629e9e0 f845e817 81c44e28 81dc0e48 f629ea20
> fltMgr!FltpProcessIoCompletion+0x10
> f629e9f0 f845eec5 81c030c8 81dc0e48 81c44e28
> fltMgr!FltpPassThroughCompletion+0x89
> f629ea20 f846b153 f629ea40 00000000 00000000
> fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x269
> f629ea5c 804e13d9 81c030c8 81dc0fd8 81dc0e48 fltMgr!FltpCreate+0x1e3
> f629ea6c 8057ccc7 81fcb8e8 81d53364 f629ec04 nt!IopfCallDriver+0x31
> f629eb4c 8056c063 81fcb900 00000000 81d532c0 nt!IopParseDevice+0xa58
> f629ebc4 8056f2a8 00000000 f629ec04 00000040 nt!ObpLookupObjectName+0x53c
> f629ec18 8057d2d3 00000000 00000000 00000001 nt!ObOpenObjectByName+0xea
> f629ec94 8057d3a2 0007fd94 80100080 0007fd34 nt!IopCreateFile+0x407
> f629ecf0 8057d3e5 0007fd94 80100080 0007fd34 nt!IoCreateFile+0x8e
> f629ed30 804dd99f 0007fd94 80100080 0007fd34 nt!NtCreateFile+0x30
> f629ed30 7c91eb94 0007fd94 80100080 0007fd34 nt!KiFastCallEntry+0xfc
> 0007fcf0 7c91d68e 7c810b2c 0007fd94 80100080 ntdll!KiFastSystemCallRet
> 0007fcf4 7c810b2c 0007fd94 80100080 0007fd34 ntdll!NtCreateFile+0xc
> 0007fd8c 010033b0 00000000 80000000 00000003 kernel32!CreateFileW+0x35f
> 0007fdb4 01003416 00000233 0007fde0 0100383d notepad!FileDragOpen+0x32
> 0007fdc0 0100383d 0083001c 000300e4 0007fe48 notepad!doDrop+0x3a
> 0007fde0 77d18734 000300e4 00000233 0083001c notepad!NPWndProc+0x414
> 0007fe0c 77d18816 01003429 000300e4 00000233
> USER32!InternalCallWinProc+0x28
> 0007fe74 77d189cd 00000000 01003429 000300e4
> USER32!UserCallWinProcCheckWow+0x150
> 0007fed4 77d18a10 0007fefc 00000000 0007ff1c
> USER32!DispatchMessageWorker+0x306
> 0007fee4 01002a12 0007fefc 00000000 7c80b529 USER32!DispatchMessageW+0xf
> 0007ff1c 01007511 01000000 00000000 000a2332 notepad!WinMain+0xdc
> 0007ffc0 7c816d4f 00efd8b0 00000018 7ffde000
> notepad!WinMainCRTStartup+0x174
> 0007fff0 00000000 0100739d 00000000 78746341
> kernel32!BaseProcessStart+0x23
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> scanner!ScannerpScanFileInUserMode+126
> [c:\users\frank\desktop\test\test\scanner\filter\scanner.c @ 1177]
> f62f37fa 8985d8fbffff mov dword ptr [ebp-428h],eax
>
>
>
>
>
>