I discovered yesterday that while remote debugging (WindBg) the kernel the Print Screen/System request key on my target will “crash” my code; that is stop at a break point in my driver code to detect a failure.
I believe that the System Request is designed to do this.
However when I try to run the target machine without the debugger Sys Rq will still “crash” my code (I the code stops after TraceView shows the tracing errors in that the DPC is not receiving IO requests to terminate).
Adding a value named BreakOnSysRq, and set it equal to DWORD 0x0 in
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\i8042prt\Parameters
And rebooting has no effect.
I tried pressing Sys Rq on other machines running our code and the code continues to run with no TraceView errors i.e. the DPC is receiving IO requests in a timely fashion.
So my question is does kernel debugging in WindBg leave the target with the SysRq key in a state that causes it to try to interrupt the kernel even after the kernel, on the target, is up and running without WindBg?
We are using Windows 10 IoT Enterprise build 1809.