You could not possibly overstate the importance of debugging in kernel-mode programming. By debugging here, I mean the interruption of a machine’s execution for examination and control. There are application programmers who have never—even in decades of highly regarded achievement—done any significant debugging of this sort but have instead been content to sprinkle their code with diversions that trace their programs’ execution and allow the deduction of defects by inspecting logs. This has its place in kernel-mode debugging too. Indeed, it is sometimes all that’s available because the act of interrupting the machine’s execution so much disturbs this execution that the defect no longer shows. Generally, though, you can’t do much kernel-mode programming without proficiency at breaking to a debugger for close inspection of registers and memory and at using the debugger to step through the machine’s execution.

My purpose, however, is not to give some overview of kernel-mode debugging. It’s even less to instruct on debugging. I must assume that skill at kernel-mode debugging is a skill you already have or are at least well on the way to developing. Anyway, since I myself think I’ve had this skill to take for granted for three decades and mostly taught myself by disassembling the debuggers, I have no experience of books or courses for you to learn from and I therefore have none to recommend.

That said, one source of guidance about kernel-mode debugging stands out. Because Microsoft needs that programmers can debug their code (the programmers’, if not Microsoft’s), Microsoft of course documents its Debugging Tools for Windows. What concerns me for this section of my website is the disparity between what I imagine is a typical first view of Microsoft’s documentation and what I see when looking into the details.

At first glance, Microsoft looks to have documented its Debugging Tools for Windows extensively. There are numerous pages of directions for set up and use, of guidance and technique, and especially of reference, with page after page for each of very many commands. Someone new to debugging or an expert at it on a different operating system might easily take this in as substantial and extensive, and perhaps even as detailed and comprehensive. In many ways, they would not be wrong.