ETW Verifier Functions

NTDEV
1

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.

  1. fffff8800d9824c8 fffff80003b751b0 nt!KeBugCheckEx
  2. fffff8800d9824d0 fffff80003aa7ddc nt!MmAccessFault+0x1d20
  3. fffff8800d982620 fffff88004e59aa4 nt!KiPageFault+0x35c
  4. fffff8800d9827b8 fffff80003d4bb37 Null!gDeviceObject+0x8b4
  5. fffff8800d9827c0 fffff80003d57792 nt!EtwpSendDataBlock+0x137
  6. fffff8800d982870 fffff80003dea460 nt!EtwpClearSessionAndUnreferenceEntry+0x246
  7. fffff8800d982920 fffff80003ea4748 nt!EtwpDisableTraceProviders+0x30
  8. fffff8800d982950 fffff80003ea4d99 nt!EtwpStopLoggerInstance+0x58
  9. fffff8800d982990 fffff80003ede6e0 nt!EtwpStopTrace+0x129
  10. fffff8800d982a00 fffff80003aa9d53 nt!NtTraceControl+0x270
  11. fffff8800d982a70 0000000076ecb0ca 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!

2

Apologies, I got a timeout error when I posted this and reposted so I’ve ended up with a duplicate.

3

[mods: I deleted the duplicate post]

4

I’m not sure what that Verifier routine gets you… but I think it’s just one of the many “standard” Verifier settings. Select everything except the Low Resources Simulations, the IRP Logging, and anything else clearly not applicable to your driver (like, NDIS/WIFI verification if you’re not an NDIS driver)… and you should get it.

Again, I’m not sure what it DOES… but…

Peter

5

Ok thanks Peter,

That set of options doesn’t seem to produce any BSODs in my environment but I’ll pass it on to my customer and see if it gives me a more interesting BSOD on theirs. I suppose it’s possible that it’s not my driver that’s responsible for this, but it does seem a bit of a coincidence that it occurs right after our driver was unloaded.

Thanks for your help.