If you enable the two registry values specified in this MSDN topic, windbg will helpfully pause every time an exceptional condition is encountered in dxgkrnl, letting you choose how to proceed (break, break then repeat message, ignore, ignore all). This works great, and does allow me to see when errors have occurred, but it doesn’t allow me to see what errors have occurred.
I can see the callstack (with public dxgkrnl symbols), which does provide some clues, but not nearly enough to understand what specifically the issue might be. I spent some time trying to poke around in the disassembly to see if I might be able to find a pointer to an actual message, but had no luck.
Is there any way to actually get at the log messages being reported here?
After spending some more time poking around in the disassembly, it seems like there’s an NTSTATUS code in r15 at the point where it breaks when telling it to do so. While this isn’t the most convenient (I found in the dxgkrnl module the actual string it sends to windbg prompting the user what to do next, why couldn’t they just log the error as well?!), at the very least it’s useful enough to make progress debugging.
Thanks to Ghidra, I was able to disassemble watchdog.sys and figure out much of how it works. I’ve written a simple windbg extension that can help in displaying the log entries and enabling various features of the library.
It is currently capable of configuring the different log categories, and dumping the log details for any log entry. I still plan on adding the ability to dump all the logs from the circular buffers that the library saves the logs to, but I haven’t done so yet.
Hopefully this might help the next person trying to deal with this stuff.