WinDbg slow when debugging local process (step ove

问题:

This is really driving me crazy. I am using WinDbg as my primary debugger. It is used to debug local service (WinDbg running locally, debugging service on the same machine). The PDB files are stored on local hard drive. Source code is accessed via SMB share.

Debugging works in bursts, sometimes it flow well, most of the time I keep seeing the unbelievably annoying "*BUSY*" message, this happens almost every time when I perform a "step-over".

Any ideas what I could do to speed things up?

Thanks

回答1:

This may happens if you have many unqualified breakpoints that track module load events (created via bu) saved in your workspace.
Also it is worth to check network connection and local symbols cache size

回答2:

I was having the exact same problem, and was able to see a big improvement by adjusting the symbol options. Specifically, the SYMOPT_NO_PUBLICS option seemed to be the most important, but I adjusted a few other related options. I did the following...

.symopt-0x4 .symopt+0x100 .symopt+0x8000 .symopt-0x10000

...which is:

-SYMOPT_DEFERRED_LOADS +SYMOPT_NO_UNQUALIFIED_LOADS +SYMOPT_NO_PUBLICS -SYMOPT_AUTO_PUBLICS

After all that, I had a symopt bit mask value of 0x80028333, which I now use as a WinDbg command line option, as in:

windbg.exe -sflags 0x80028333

I haven't yet discovered if there is any downside to this approach. Perhaps there are some cases where using SYMOPT_NO_PUBLICS results in missing information, but it's been working well for me thus far, and it's definitely way faster.

WinDbg Symbol Options MS Documentation

回答3:

Usually this happened to me when multiple tool windows (locals, watches, call stack ) were opened. If those windows are opened, WinDbg will spend cycles to update all of them using slow symbols lookups on each 'step-over' command.

In this regard using just a command line ( ntsd ) debugger is much faster.

回答4:

If it's slowly pulling Windows symbol files from the internet, consider downloading all of them to your hard drive and pointing WinDbg to their location on it. It would be best to have your service's symbol files and source files on the local drive too.

回答5:

A couple of things to try:

• Use the !sym noisy command to show more detailed information on the images and pdbs that windbg is referencing. You may see that it's accessing the network more than you're expecting, or that a network server is unavailable and requests are timing out
• Ensure that your symbol path has got a cache in it
• Take a copy of the sources locally and add to the source path

回答6:

Instead of using 'step-over', set a breakpoint on the next command, or even a hardware breakpoint (using ba)

回答7:

When your symbol path contains a large file store, WinDbg can take a long time searching for symbols that don't exist. You'll can diagnose this behavior by, as user eran suggested, by running Process Monitor and observing the file operations being made by WinDbg.

This was an extreme pain point for our organization, but I found a workaround detailed in this question: "WinDbg takes extremely long time to loading symbols; is searching every directory in large network UNC symbol store"