Debugging Speed-up Guide

By default, Visual Studio queries lots of information from the debuggee after each step. Autos window generate expression evaluating requests for every token existing in the current line, locals window evaluates every local variable (even if the window is in the background). Memory windows execute memory reading requests. Everyone, who used WinDbg at least once, knows that evaluating unresolved symbols is a great bottleneck of WinDbg that can easily take several seconds for each symbol to be searched.

VisualDDK contains a partial workaround for that problem: it uses DIA interface to build its own hash table of all symbols present in all loaded modules. If a symbol that does not exist in any of the modules is requested, MS debug engine is not even queried. If a symbol is found in a module, its name is automatically prefixed by module name, that speeds up the job of MS debug engine. However, this workaround has a significant limitation: only raw symbol names are processed that way. Every C/C++ expression containing something else than just an identifier will be parsed by MS Debug Engine and, thus, may cause long delays in case of unresolved symbols.

Nevertheless, if you want to speed up your debugging, consider closing all windows that are related to querying debuggee (putting them into background is not enough!). VisualDDK console simplifies this task by showing a list of windows that could be closed to speedup debugging. Please also not that it is highly recommended to close the Autos window, as sometimes it evaluates complex expressions (such as someconst << 5), that are passed directly to MS Debug Engine and may cause very long processing time. Closing other windows can reduce stepping time. Closing VisualDDK Console itself does not affect stepping time, as it does not evaluate any data on its own.

You can also speed up the kernel debugging by using 1394 port, or VirtualKD extension (works with VMWare and VirtualBox).