IRP_MJ_CREATE post operation being called at DISPATCH_LEVEL

User3 · May 30, 2022, 11:18am

Isn’t IRP_MJ_CREATE guaranteed to be called at PASSIVE_LEVEL according to the docs?

According to WinDbg, my post operation of IRP_MJ_CREATE was called at DISPATCH_LEVEL. (See attached screenshot) This resulted in an instant crash.

In the following thread, there are mentions of a potential faulty driver in the altitude chain messing things up https://community.osr.com/discussion/279973/irp-mj-create-irql-of-pre-and-post-handlers

If was truly a faulty driver causing this, then why doesn’t a crash occur unless my driver is loaded? I guarantee, the IRQL isn’t raised by my driver at any point, at all.

I’m looking for an actual solution rather than checking if the IRQL is at DISPATCH_LEVEL before calling API that can’t be called at that level.

There’s also a comment: “You must not lower IRQL if you have not raised it. If you detected a wrong condition complete request with an error.”

Should I just return an error if the IRQL isn’t at PASSIVE_LEVEL? This doesn’t seem right, if the docs say “it’s guaranteed”, then it must be so

I’m so confused that I decided to finally make an account here after having been a guest here for years.

Thanks in advance

[Mods: Arbitrary link deleted]

rod_widdowson · May 30, 2022, 12:19pm

Aside: please do not post random links. Cut and paste the text from the debugger. Most people won’t just click on links these days (I looked at this in a secured VM),

When i did look at it image actually doesn’t show anything . You need, at the very least, to provide a stack. You we might be able to see who completed the irp.

User3 · May 30, 2022, 4:02pm

When I pasted the link inside the image box here, it did nothing, hence I posted the link as is and I just realized, the box needs the actual image link, like the source one (.jpg) I took note though, thank you.

Anyway, I did more than 20 tests since I posted without touching the source code and got absolutely no problems but I still have the memdump and am even more interested now to know what happened there.

Here’s the stacktrace + what I think may be important:

Are the 4 address in a row, right before the symbols, RCX, RDX, R8 and R9 at the time a function was called?

STACK_TEXT:
ffffb8089dd0ec38 fffff806366296a9 ffffb8089dd0ec40 fffff80636625800 ffffb8089dd0ed80 fffff806365217cd ffffb8089dd0ef10 fffff8063655b7d6 ffffb8089dd0f000 fffff8063655b4dc ffffb8089dd0f040 fffff806b7723268 ffffb8089dd0f070 fffff806b772378f ffffb8089dd0f0a0 fffff806377966de ffffb8089dd0f0e0 fffff80637795f93 ffffb8089dd0f1b0 fffff80637797d0f ffffb8089dd0f250 fffff806377cd974 ffffb8089dd0f2c0 fffff806364f68d5 ffffb8089dd0f370 fffff80636909557 ffffb8089dd0f3b0 fffff8063696ad91 ffffb8089dd0f570 fffff80636969d91 ffffb8089dd0f710 fffff806369d029f ffffb8089dd0f840 fffff806369cfe79 ffffb8089dd0f8e0 fffff80636629075 ffffb8089dd0f970 00007ffeec844954 0000007ec20f9fd8 0000000000000000 : 000000000000000a 0000000000000000 0000000000000002 0000000000000000 : nt!KeBugCheckEx
: ffffba8d73866a30 fffff8063779c2b9 0000000000000200 ffffb8089dd0ee69 : nt!KiBugCheckDispatch+0x69
: 0000000000000000 0000000000000000 ffffba8d73985200 0000000000000000 : nt!KiPageFault+0x440
: fffff806b772e320 fffff80600000022 ffffba8d00008000 00000000ffff7f00 : nt!KeWaitForSingleObject+0x1dd
: fffff806b772e308 ffffb8089dd0f149 0000000000000000 0000000000000000 : nt!ExpAcquireFastMutexContended+0x7a
: ffffe604f26730f8 0000000000000000 ffffba8d73866a30 ffffba8d70e9db88 : nt!KeAcquireGuardedMutex+0x6c
: 0000000000000000 ffffba8d6c1c50c0 ffffb8089dd0f128 ffffb8089dd0f128 : MyDriver!MyFunction+0x28 [mypath\myfile.c @ 157]
: 0000000000000000 ffffba8d70e9daa0 ffffba8d73d9e010 0000000000000000 : MyDriver!PostOperation+0x8f [mypath\myfile2.c @ 896]
: ffffba8d70e9da00 0000000000000000 0000000000000000 0000000000000000 : FLTMGR!FltpPerformPostCallbacksWorker+0x32e
: ffffb8089dd09000 ffffb8089dd10000 0000000000000000 0000000000000008 : FLTMGR!FltpPassThroughCompletionWorker+0x143
: ffffb8089dd0f300 ffffb8089dd09000 ffffba8d6662ec00 fffff80636908869 : FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x34f
: 0000000000000000 ffffba8d6662e4b0 0000000000000000 0000000000000000 : FLTMGR!FltpCreate+0x314
: ffffba8d6662ec90 ffffba8d6662e4b0 ffffb8089dd0f670 ffffba8d00000040 : nt!IofCallDriver+0x55
: 000000f800000001 ffffe604e62aac00 ffffb8089dd0f760 ffffe604e62aabd0 : nt!IopParseDevice+0x897
: 0000000000000000 ffffb8089dd0f7a0 0000000000000040 ffffba8d61f35c40 : nt!ObpLookupObjectName+0xac1
: ffffba8d00000000 0000000000000001 ffffba8d706cc330 0000007ec20fa080 : nt!ObOpenObjectByNameEx+0x1f1
: 0000007ec20fa048 0000000000000000 0000007ec20fa080 0000007ec20fa070 : nt!IopCreateFile+0x40f
: 0000000000000000 0000000000000001 ffffba8d61e78ef0 0000007ec20fa218 : nt!NtCreateFile+0x79
: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x25
: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x00007ffe`ec844954

PROCESS_NAME: MsMpEng.exe

BUGCHECK_CODE: a
BUGCHECK_P1: 0
BUGCHECK_P2: 2
BUGCHECK_P3: 0

READ_ADDRESS: 0000000000000000 (I’m not sure why or how)

nt!KeWaitForSingleObject+0x1dd:
fffff806365217cd 483901 cmp qword ptr [rcx],rax ds:0000000000000000=???

KeAcquireGuardedMutex(&g_Lock); // This is the last piece of code executed from my driver before the exception occurred

I can guarantee, the lock was 100% initialized correctly.

The lock is a global variable, hence it must not be pagable by default, right? I’m also not sure why KeWaitForSingleObject (received? and) tried to dereference a NULL!! The stacktrace inside in WinDbg shows that &g_Lock was a proper value that has sensical information.

Edit: Why does !irql keep showing the same output across all stack frames? Is this the IRQL captured just before the crash? If so, then my Thread is nonsense and cause of the crash was completely different…

8: kd> !irql
Debugger saved IRQL for processor 0x8 – 2 (DISPATCH_LEVEL)

User3 · May 30, 2022, 5:05pm

https://community.osr.com/discussion/293036/bsod-kernel-security-check-failure
This looks similar to my issue considering the stacktrace:
My stacktrace:
fffff40ec8355fe0 fffff8006f75b7d6 : fffff8008bbb3300 0000000000000022 0000000000000000 fffff80071b95300 : nt!KeWaitForSingleObject+0x1dd
fffff40ec83560d0 fffff8006f75b4dc : fffff8008bbb32e8 fffff40ec8356249 0000000000000000 0000000000000000 : nt!ExpAcquireFastMutexContended+0x7a
fffff40ec8356110 fffff8008bba4e7d : ffffb68f9d725010 ffffb68f9cfe32b0 ffffb68f9d725198 0000000000000000 : nt!KeAcquireGuardedMutex+0x6c

Their stacktrace:
ffff800b63dd2640 fffff8032332efc9 : ffff9b0c14c33dd0 fffff80300000022 ffff800b63dd2700 fffff803299e4500 : nt!KeWaitForSingleObject+0xcdf
ffff800b63dd2710 fffff8032332f58b : ffff9b0c143cd3a0 0000000000000000 0000000000000000 ffff800b00000000 : nt!ExpAcquireFastMutexContended+0x79
ffff800b63dd2750 fffff803299e8c6a : fffff803236eabf8 ffff9b0c16344ba0 0000000000000000 fffff80329a0a06a : nt!KeAcquireGuardedMutex+0x6b

What’s the possibility of it being a problem with KGUARDED_MUTEX implementation?