Hi there,
I’m looking at a BSOD issue at the moment which has this stack trace. It’s happened after an older version of our driver has been uninstalled and wevtutil.exe is installing a trace manifest for a later version of our product. Wevtutil.exe has called an svchost via ALPC and this has called down to the kernel producing the following stack trace.
- fffff880
0d9824c8 fffff800
03b751b0 nt!KeBugCheckEx - fffff880
0d9824d0 fffff800
03aa7ddc nt!MmAccessFault+0x1d20 - fffff880
0d982620 fffff880
04e59aa4 nt!KiPageFault+0x35c - fffff880
0d9827b8 fffff800
03d4bb37 Null!gDeviceObject+0x8b4 - fffff880
0d9827c0 fffff800
03d57792 nt!EtwpSendDataBlock+0x137 - fffff880
0d982870 fffff800
03dea460 nt!EtwpClearSessionAndUnreferenceEntry+0x246 - fffff880
0d982920 fffff800
03ea4748 nt!EtwpDisableTraceProviders+0x30 - fffff880
0d982950 fffff800
03ea4d99 nt!EtwpStopLoggerInstance+0x58 - fffff880
0d982990 fffff800
03ede6e0 nt!EtwpStopTrace+0x129 - fffff880
0d982a00 fffff800
03aa9d53 nt!NtTraceControl+0x270 - fffff880
0d982a70 00000000
76ecb0ca nt!KiSystemServiceCopyEnd+0x13
Disassembling EtwpSendDataBlock() appears to show that the ETW subsystem has attempted to call a callback which is now pointing at the Null driver (although I’ve seen 3 other drivers implicated in other versions of the dump). I suspect the cause is actually that our driver has failed to unregister from ETW in some way although right now we call EtwUnregister() on driver unload which seems to work ordinarily. This crash can’t be reproduced in house and only occurred on a relatively small percentage of a customers estate.
I’ve noticed that some of the ETW functions have exported verifier versions such as VerifierEtwUnregister(). I was wondering if there’s a reliable way of looking at these verifier functions to figure out which verifier option would have to be enabled to turn it on? Does anyone know? Thanks!