0

This is a theoretical question because I've never set up remote kernel debugging before -- but I will do at some point, which should hopefully answer some of the experimental questions I have.

What happens if you put a breakpoint in the breakpoint trap handling or kdcom / kdnet itself

I can't find a single thing about this, but in the former case, wouldn't the CPU just freeze because the breakpoint is continually being hit without the remote debugger getting chance to remove the breakpoint or iretting to the instruction after the breakpoint.

Also, from what I'm seeing, it seems like a stack trace hides any of the trap handling, and shows the breakpoint as the top frame on the stack.

Improve this question
1

The earliest break is sxe ibp break on kd communication
if you want to break earlier than that you need to lookup boot debugging
you can use ctrl+alt+d for a debug spew of kdcom kdnet packets sent to and fro

Improve this answer
2
  • I managed to break in at nt!DebugService2+0x5 <- nt!DbgLoadImageSymbols+0x4d <- nt!KdInitSystem+0x429 <- nt!KiSystemStartup+0x12 where only nt was loaded when I set bootdebug on and restarted but I can't reproduce it again, so it only worked the first time and not subsequently. Ctrl+Alt+K only breaks into the debugger at the initial breakpoint and when you select first module load, no breakpoint is hit. I still don't know how I was able to break in if kdcom isn't loaded I don't know how it's communicating with the debugger – Lewis Kelsey Apr 15 at 7:30
  • 1
    I answered a similar query here take a look the debugging system is a seperate entity and is active even at winload when nt isnt even loaded stackoverflow.com/a/66976337/3622813 – blabb Apr 15 at 18:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.