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?

Was it helpful?

Solution

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.

OTHER TIPS

You cannot debug the kernel interactively (or locally) because the kernel itself is in charge even for displaying the picture on the monitor (by communicating with the appropriate display driver) and more than just that. I would put your question in an another way: Is it possible to debug the kernel easier than by connecting through telnet?

To that question my answer is: yes, it is. At least on X86/X64 architectures by using virtualization. I am using VirtualBox to run a guest OS which I can debug on my local machine. I'm also using VirtualKD (http://virtualkd.sysprogs.org/) which speeds up the communication drastically between the debugging machine (the host) and the VM.

The VirtualKD contains a package which modifies the guest Windows' boot.ini thus you can enable debugging at the boot time by selecting the proper menu item which Windows displays to you.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top