Hacker News Reader

Comment by yuhong | Hacker News Reader

I even used a checked build of NTLDR with the boot debugger to confirm.

BTW, the boot debugger in checked builds of NTLDR is harder to use than the one in BOOTMGR. You have to manually load symbols by reading the PE header into memory using a copy with the real mode stub removed, and you have to use F10 at the boot menu in order to break into the debugger.

As someone completely naive about Windows (and particularly low-level development), I'm casually/idly curious if the DDK includes the debugging tools you used, or if I have to throw money at people to get at them. (I know the DDK exists, but not much more than that.)

Also, how did you remove the real-mode stub? Hex editing, or is there a tool that will do that if fed the right combination of [obscure] options?

IMHO, the best way to finish this off would be an in-depth tutorial-style blog post. You definitely get my recommendation to consider that :)

Yes, the DDK used to include the needed debug version of NTLDR too. And yes, it is done by hex editing looking for the "MZ" signature and trimming everything before that. With BOOTMGR you just set some BCD options to enable the boot debugger.

Oh of course, the XP DDK.

And MZ-hunting makes perfect sense.

Thanks for the quick reply :) and kudos for figuring out it was the bootloader, hah

What does "checked build" mean here?

https://msdn.microsoft.com/en-us/windows/hardware/drivers/de...

A checked build basically has optimization off and assert() on.

Optimizations are still on in checked builds.

From the MSDN article I linked:

> Many compiler optimizations (such as stack frame elimination) are disabled in the checked build. This makes it easier to understand disassembled machine instructions, and therefore it is easier to trace the cause of problems in system software.

Reply on news.ycombinator.com