Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
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]
Upcoming OSR Seminars | ||
---|---|---|
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead! | ||
Kernel Debugging | 9-13 Sept 2024 | Live, Online |
Developing Minifilters | 15-19 July 2024 | Live, Online |
Internals & Software Drivers | 11-15 Mar 2024 | Live, Online |
Writing WDF Drivers | 20-24 May 2024 | Live, Online |
Comments
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.
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:
ffffb808
9dd0ec38 fffff806
366296a9 : 000000000000000a 00000000
00000000 0000000000000002 00000000
00000000 : nt!KeBugCheckExffffb808
9dd0ec40 fffff806
36625800 : ffffba8d73866a30 fffff806
3779c2b9 0000000000000200 ffffb808
9dd0ee69 : nt!KiBugCheckDispatch+0x69ffffb808
9dd0ed80 fffff806
365217cd : 0000000000000000 00000000
00000000 ffffba8d73985200 00000000
00000000 : nt!KiPageFault+0x440ffffb808
9dd0ef10 fffff806
3655b7d6 : fffff806b772e320 fffff806
00000022 ffffba8d00008000 00000000
ffff7f00 : nt!KeWaitForSingleObject+0x1ddffffb808
9dd0f000 fffff806
3655b4dc : fffff806b772e308 ffffb808
9dd0f149 0000000000000000 00000000
00000000 : nt!ExpAcquireFastMutexContended+0x7affffb808
9dd0f040 fffff806
b7723268 : ffffe604f26730f8 00000000
00000000 ffffba8d73866a30 ffffba8d
70e9db88 : nt!KeAcquireGuardedMutex+0x6cffffb808
9dd0f070 fffff806
b772378f : 0000000000000000 ffffba8d
6c1c50c0 ffffb8089dd0f128 ffffb808
9dd0f128 : MyDriver!MyFunction+0x28 [mypath\myfile.c @ 157]ffffb808
9dd0f0a0 fffff806
377966de : 0000000000000000 ffffba8d
70e9daa0 ffffba8d73d9e010 00000000
00000000 : MyDriver!PostOperation+0x8f [mypath\myfile2.c @ 896]ffffb808
9dd0f0e0 fffff806
37795f93 : ffffba8d70e9da00 00000000
00000000 0000000000000000 00000000
00000000 : FLTMGR!FltpPerformPostCallbacksWorker+0x32effffb808
9dd0f1b0 fffff806
37797d0f : ffffb8089dd09000 ffffb808
9dd10000 0000000000000000 00000000
00000008 : FLTMGR!FltpPassThroughCompletionWorker+0x143ffffb808
9dd0f250 fffff806
377cd974 : ffffb8089dd0f300 ffffb808
9dd09000 ffffba8d6662ec00 fffff806
36908869 : FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x34fffffb808
9dd0f2c0 fffff806
364f68d5 : 0000000000000000 ffffba8d
6662e4b0 0000000000000000 00000000
00000000 : FLTMGR!FltpCreate+0x314ffffb808
9dd0f370 fffff806
36909557 : ffffba8d6662ec90 ffffba8d
6662e4b0 ffffb8089dd0f670 ffffba8d
00000040 : nt!IofCallDriver+0x55ffffb808
9dd0f3b0 fffff806
3696ad91 : 000000f800000001 ffffe604
e62aac00 ffffb8089dd0f760 ffffe604
e62aabd0 : nt!IopParseDevice+0x897ffffb808
9dd0f570 fffff806
36969d91 : 0000000000000000 ffffb808
9dd0f7a0 0000000000000040 ffffba8d
61f35c40 : nt!ObpLookupObjectName+0xac1ffffb808
9dd0f710 fffff806
369d029f : ffffba8d00000000 00000000
00000001 ffffba8d706cc330 0000007e
c20fa080 : nt!ObOpenObjectByNameEx+0x1f1ffffb808
9dd0f840 fffff806
369cfe79 : 0000007ec20fa048 00000000
00000000 0000007ec20fa080 0000007e
c20fa070 : nt!IopCreateFile+0x40fffffb808
9dd0f8e0 fffff806
36629075 : 0000000000000000 00000000
00000001 ffffba8d61e78ef0 0000007e
c20fa218 : nt!NtCreateFile+0x79ffffb808
9dd0f970 00007ffe
ec844954 : 0000000000000000 00000000
00000000 0000000000000000 00000000
00000000 : nt!KiSystemServiceCopyEnd+0x250000007e
c20f9fd8 00000000
00000000 : 0000000000000000 00000000
00000000 0000000000000000 00000000
00000000 : 0x00007ffe`ec844954PROCESS_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:
fffff806
365217cd 483901 cmp qword ptr [rcx],rax ds:00000000
00000000=????????????????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)
https://community.osr.com/discussion/293036/bsod-kernel-security-check-failure
This looks similar to my issue considering the stacktrace:
My stacktrace:
fffff40e
c8355fe0 fffff800
6f75b7d6 : fffff8008bbb3300 00000000
00000022 0000000000000000 fffff800
71b95300 : nt!KeWaitForSingleObject+0x1ddfffff40e
c83560d0 fffff800
6f75b4dc : fffff8008bbb32e8 fffff40e
c8356249 0000000000000000 00000000
00000000 : nt!ExpAcquireFastMutexContended+0x7afffff40e
c8356110 fffff800
8bba4e7d : ffffb68f9d725010 ffffb68f
9cfe32b0 ffffb68f9d725198 00000000
00000000 : nt!KeAcquireGuardedMutex+0x6cTheir stacktrace:
ffff800b
63dd2640 fffff803
2332efc9 : ffff9b0c14c33dd0 fffff803
00000022 ffff800b63dd2700 fffff803
299e4500 : nt!KeWaitForSingleObject+0xcdfffff800b
63dd2710 fffff803
2332f58b : ffff9b0c143cd3a0 00000000
00000000 0000000000000000 ffff800b
00000000 : nt!ExpAcquireFastMutexContended+0x79ffff800b
63dd2750 fffff803
299e8c6a : fffff803236eabf8 ffff9b0c
16344ba0 0000000000000000 fffff803
29a0a06a : nt!KeAcquireGuardedMutex+0x6bWhat's the possibility of it being a problem with KGUARDED_MUTEX implementation?