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 fffff806
366296a9 : 000000000000000a 00000000
00000000 0000000000000002 00000000
00000000 : nt!KeBugCheckEx
ffffb8089dd0ec40 fffff806
36625800 : ffffba8d73866a30 fffff806
3779c2b9 0000000000000200 ffffb808
9dd0ee69 : nt!KiBugCheckDispatch+0x69
ffffb8089dd0ed80 fffff806
365217cd : 0000000000000000 00000000
00000000 ffffba8d73985200 00000000
00000000 : nt!KiPageFault+0x440
ffffb8089dd0ef10 fffff806
3655b7d6 : fffff806b772e320 fffff806
00000022 ffffba8d00008000 00000000
ffff7f00 : nt!KeWaitForSingleObject+0x1dd
ffffb8089dd0f000 fffff806
3655b4dc : fffff806b772e308 ffffb808
9dd0f149 0000000000000000 00000000
00000000 : nt!ExpAcquireFastMutexContended+0x7a
ffffb8089dd0f040 fffff806
b7723268 : ffffe604f26730f8 00000000
00000000 ffffba8d73866a30 ffffba8d
70e9db88 : nt!KeAcquireGuardedMutex+0x6c
ffffb8089dd0f070 fffff806
b772378f : 0000000000000000 ffffba8d
6c1c50c0 ffffb8089dd0f128 ffffb808
9dd0f128 : MyDriver!MyFunction+0x28 [mypath\myfile.c @ 157]
ffffb8089dd0f0a0 fffff806
377966de : 0000000000000000 ffffba8d
70e9daa0 ffffba8d73d9e010 00000000
00000000 : MyDriver!PostOperation+0x8f [mypath\myfile2.c @ 896]
ffffb8089dd0f0e0 fffff806
37795f93 : ffffba8d70e9da00 00000000
00000000 0000000000000000 00000000
00000000 : FLTMGR!FltpPerformPostCallbacksWorker+0x32e
ffffb8089dd0f1b0 fffff806
37797d0f : ffffb8089dd09000 ffffb808
9dd10000 0000000000000000 00000000
00000008 : FLTMGR!FltpPassThroughCompletionWorker+0x143
ffffb8089dd0f250 fffff806
377cd974 : ffffb8089dd0f300 ffffb808
9dd09000 ffffba8d6662ec00 fffff806
36908869 : FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x34f
ffffb8089dd0f2c0 fffff806
364f68d5 : 0000000000000000 ffffba8d
6662e4b0 0000000000000000 00000000
00000000 : FLTMGR!FltpCreate+0x314
ffffb8089dd0f370 fffff806
36909557 : ffffba8d6662ec90 ffffba8d
6662e4b0 ffffb8089dd0f670 ffffba8d
00000040 : nt!IofCallDriver+0x55
ffffb8089dd0f3b0 fffff806
3696ad91 : 000000f800000001 ffffe604
e62aac00 ffffb8089dd0f760 ffffe604
e62aabd0 : nt!IopParseDevice+0x897
ffffb8089dd0f570 fffff806
36969d91 : 0000000000000000 ffffb808
9dd0f7a0 0000000000000040 ffffba8d
61f35c40 : nt!ObpLookupObjectName+0xac1
ffffb8089dd0f710 fffff806
369d029f : ffffba8d00000000 00000000
00000001 ffffba8d706cc330 0000007e
c20fa080 : nt!ObOpenObjectByNameEx+0x1f1
ffffb8089dd0f840 fffff806
369cfe79 : 0000007ec20fa048 00000000
00000000 0000007ec20fa080 0000007e
c20fa070 : nt!IopCreateFile+0x40f
ffffb8089dd0f8e0 fffff806
36629075 : 0000000000000000 00000000
00000001 ffffba8d61e78ef0 0000007e
c20fa218 : nt!NtCreateFile+0x79
ffffb8089dd0f970 00007ffe
ec844954 : 0000000000000000 00000000
00000000 0000000000000000 00000000
00000000 : nt!KiSystemServiceCopyEnd+0x25
0000007ec20f9fd8 00000000
00000000 : 0000000000000000 00000000
00000000 0000000000000000 00000000
00000000 : 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: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)