Question

I understand the purpose of both kernel and user mode, and how transitions from the former to the latter happen. Yet many sources state that a crash happening in kernel mode is hard to debug and that it should be done remotely, by connecting through telnet for instance (here is an example).

Why is it so hard to debug?
Why can’t you just attach a (kernel) debugger to one of the kernel thread and use it the usual way?

Answer 1

Crashing in kernel mode can potentially corrupt data structures anywhere in memory, even the debugger itself. Making that bulletproof is hard.

In normal debugging you have two completely isolated processes – the debugger and the thing you’re debugging. They’re “peers”, created equal. The process being debugged can’t touch the debugger, no matter what it does (and probably doesn’t know it even exists). The debugger on the other hand can interact with the process being debugged in fixed, predictable ways which are always applicable to all regular user processes.

An example: How would you debug the keyboard interface if it’s local debugging, or the RS232 code if it’s over a serial port? The NIC driver or network stack if it’s over a network? Setting a breakpoint in one of those would be unrecoverable because you’d lose access to the device controlling the debugger. Worst case scenario, how would you debug the kernel debugger? With GDB you could, at least theoretically attach a GDB instance to another instance of GDB without too much trouble. In kernel space it’s just not possible, because there is no layer above to mediate things.