Right, so a user shared their dump and I began to look, and it was of the 0xDEADDEAD bug check. I have never actually seen this bug check outside of driver development, crash and/or hang troubleshooting, learning, etc, because those are generally the only things it's used for. However, today, I learned that a driver can call KeBugCheckEx and pass it the code.
MANUALLY_INITIATED_CRASH1 (deaddead)So here we have the basic bug check information. As far as I know, the parameters have no meaning in this bug check. There's no 'if parameter 1 = 3, it means x'. We can even see the description of the bug check via WinDbg is 'The user manually initiated this crash dump'.
The user manually initiated this crash dump.
From the call stack we can see that 0xdeaddead called into NETwNs64+0xa6fcf (Intel(R) Wireless WiFi Link 5000 Series Adapter Driver for Windows 7). Also, what's interesting, in the RetAddr portion of the call stack, we can see deaddead is mentioned. I am going to assume that this indicates that NETwNs64.sys went ahead and called nt!KeBugCheckEx and passed it the code. That's what gave us the 0xDEADDEAD bug check.
1: kd> kv
Child-SP RetAddr : Args to Child : Call Site
fffff880`009e85f8 fffff880`0775bfcf : 00000000`deaddead 00000000`0f000101 00000000`0023002c 00000000`12a70000 : nt!KeBugCheckEx
fffff880`009e8600 00000000`deaddead : 00000000`0f000101 00000000`0023002c 00000000`12a70000 00000000`00000000 : NETwNs64+0xa6fcf
fffff880`009e8608 00000000`0f000101 : 00000000`0023002c 00000000`12a70000 00000000`00000000 fffffa80`1419ceae : 0xdeaddead
fffff880`009e8610 00000000`0023002c : 00000000`12a70000 00000000`00000000 fffffa80`1419ceae 00000000`00000000 : 0xf000101
fffff880`009e8618 00000000`12a70000 : 00000000`00000000 fffffa80`1419ceae 00000000`00000000 00000000`00000000 : 0x23002c
fffff880`009e8620 00000000`00000000 : fffffa80`1419ceae 00000000`00000000 00000000`00000000 fffffa80`0a73ed80 : 0x12a70000
Cool : )