The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
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
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.
|Upcoming OSR Seminars|
|OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!|
|Internals & Software Drivers||30 Nov 2020||LIVE ONLINE|
|Writing WDF Drivers||7 Dec 2020||LIVE ONLINE|
|Developing Minifilters||Early 2021||LIVE ONLINE|