Here’s a little known tidbit of information that you might find useful while debugging things:
All the extra windows that you may have open in WinDbg (disassembly, registers, memory, and soforth) actually slow the debugger down. Really.
This is typically only noticible on targets with a non-local connection in between your local debugger and the target. Primarily, then, this applies to kernel debugging and remote debugging.
These windows slow down the debugger because they represent extra information that the debugger must fetch each time the target breaks into the debugger. The debugger engine tends to follow a rule of “lazy fetching”; that is, it will try to avoid asking the target for extra information until it absolutely must do so. If you don’t have your disassembly window open, then, you’ll save the debugger from having to read memory from the disassembly target address on every debugger event that causes a breakin (until you actually explicitly request that information via the “u” command, for instance). There are similar speed consequences for having the registers window open (or setting your default register mask to show all registers, as usermode debugging does by default – this is, I suspect, why kernel debugging defaults to a very minimal register mask that is displayed on each prompt), and for having the memory window open. Keeping these windows open will require the debugger to go out of its way to request extra register information (and to read memory on each debugger event).
The result of having these extra windows open is that the debugger will just seem significantly slower when you are doing things like stepping or hitting breakpoints and continuing execution. If you’ve ever wondered why sometimes it takes the debugger a couple seconds or more to come back after each step or trace operation, this is a big contributor to that (especially in kernel debugging).
So, close those extra windows unless you really need them, as they really do slow things down in kernel debugging and remote debugging scenarios. You’ll find that your kernel debugging and remote debugging experiences are much more responsive without the debugger having all those extra round trip times being inserted on each trace/step/break event.
Oh, and you can also temporarily suspend the behavior of keeping these windows up to date while still keeping them open with a command that was recently introduced to WinDbg: “.suspend_ui flag“, where flag is either 0 to disable UI window refreshing, or 1 to enable it. This is mostly useful for scenarios where you still find the disassembly or memory windows useful, but are about to execute a large number of traces or steps and want to reduce overhead for the duration of that activity only.