When you debug a program, you do not want to deal with most of the debugger is not working properly. When you try to concentrate on tracking a bug, always because of minor problems are ignored, especially when the debugger problem cause you to lose a re-programming or waste a lot of time waiting for it to complete the debugger, and the debugger it takes time to know what to do forever.
This is a question I often encounter a lot, so I put together a short list of some common problems that people could easily trip over these issues (and how to avoid or solve them).
- I am using ntsd, unable to load or most symbolic debugger extension command (! Command) does not work. This usually means that you start with the operating system ntsd (prior to Windows Vista), this package comes with a debugger than ntsd much older. Because it is in the system directory, so it will be in your executable search path. To resolve this issue, use ntsd executable debugger installation directory.
- WinDbg event processing module loading takes a long time, it uses the maximum processor time (rotation) in one CPU. If the work area to save a lot of tracking module load event (created by bu) of non-defined breakpoints, usually this happens. When the program you are working in a large number of modified C ++ symbol, the problem is particularly evident, for example, heavy use of the debugger STL template class or other building. The forced loading symbols for all modules immediately, non-limiting breakpoints are usually expensive, but they also force the debugger module being loaded each symbol (for each breakpoint unresolved) cancel the modifications and performs pattern matching.
If allowed to save a large number of unqualified breakpoint in the default workspace, regardless of which program debugging, the debugger can make look very slow.
In order to avoid being plagued by this problem, do not use substandard breakpoint (breakpoint modulename no! Unless absolutely necessary. In addition, if you do not need to save all breakpoints in debugging session next debugger workspace (default , bu breakpoint debugger will remain in the work area, and bp will disappear after each breakpoint debugging session), then remove all breakpoints is usually a good idea before you save the workspace. If you are used each additional to the running process are saved workspace, and you use frequently bu breakpoint, then this will make the user default workspace become disorganized, if not careful, could soon lead to the debugger performance is very poor.
You can use bc command to delete a breakpoint (bc * delete all breakpoints), but you need to save your work area to keep the changes. If the issue is not even complete modules to be loaded within a reasonable amount of time, in order to use the degree bc * Clear saved breakpoints, you can remove the \ Software \ Microsoft \ Windbg \ Workspaces registry key HKCU and children's content, so that Windbg return to the original state. this will clear Saved debugger window position and other saved debug settings, so use it as a last resort. - WinDbg processing module load event takes a long time, but it does not take up a lot of processor time. This usually means that the symbol path includes broken links or HTTP symbolic memory storage symbol UNC path disconnected. Symbol in the path of non-response path will lead to the operation of any attempt to load module symbol takes a long time to complete because the network time-out will occur repeatedly.
use! sym noise, followed .reload / f symbol to determine which part of the work path is not normal. Then, repair or remove the conflict part of the symbol path.
When the debugger program is located in the path of the packet, this problem may also occur, which sends the data packet to a location on the symbol path. In this case, I suggest that the typical solution is to set a path empty sign, attached to the process in question, write a dump file, then separated from the process. Then, back to normal symbol path and open the dump file in the debugger, and issued .reload / f command to force the early pre-cache all symbols. After the cache memory at the downstream pre-caching all symbols, the symbol path to reference the cache storage location downstream only, without any reference symbols HTTP server or UNC path and debugger attached to the process path for the packet server access symbol . - WinDbg refused to sign the server I know there are modules loaded symbol symbols. If WinDbg previously tried (but failed) to download symbols modules This problem may occur. symbol server support dbghelp's appears to be a bug, sometimes leads to partial download PDB files remain in the downstream storage cache. If this happens, future attempts to access the module symbol will fail with an error, the module could not be found symbol.
If you open the noisy symbol loading (! Sym noise), usually gives a more descriptive error. If you see the complaints about E_PDB_CORRUPT, then you may be a victim of this problem. Indicating the problem debugger output is as follows:
DbgHelp: c: \ Symbols \ ntdll.pdb \ 2744327E50A64B24A87BDDCFC7D435A02 \ ntdll.pdb - E_PDB_CORRUPT
If you encounter this problem, simply remove the error message in the name of the .pdb, then .reload / f <modulename> command retry loading symbols. - When I attach to a particular process (such as svchost instance), WinDbg will hang and never returned. If you save a sure sign workspace module load path is disconnected or fail to track the breakpoint, the debugger and never return (or attach to the process when attaching to a process almost always after the first command pending), then the debug symbols may be in charge of loading the code path.
When debugging svchost instance, this problem is particularly common, because running a number of important but not related to the code snippets in various svchost instance, some of which work is essential for the code symbol web server supports. If you are debugging the critical path network symbol server support in the process, and has set up a symbolic path network components, it may result in a deadlock debugger (permanently hang) when you first try to load symbols.
An example might be the case is that if you are debugging the code to the DNS cache service located in the same svchost instance. In this case, when you try to load the symbol and the symbol have HTTP symbol server path in the link, the debugger will be a deadlock, because when it tries to resolve the host name of the server referenced in the path of the symbol, it will try to DNS cache RPC service calls. Because before the debugger recovery process, the DNS cache service is not responding, and the debugger before obtaining a response to a request from the RPC service DNS cache, it will not restore process, so the debugging session will hang indefinitely.
Please note that some content if only symbolic debug data package path storage area in the server, you'll often see the debugger become unresponsive for a long period of time, but not completely suspended. This is because the debugger can handle network timeouts (if a little slow, then) and eventually sign a request for a network path fails. However, if the debugger trying to send out some kind of IPC requests and requests IPC does not have any built-in time-out (most of the local IPC mechanism is not), then the debugger session will be lost forever to the process being debugged.
The solution to this problem is similar to how I normally recommend that users processing module loads slowly or symbol server access failure problem, the problem is that the packet path symbol using the symbol server path referenced in the program to solve. Specifically, you can create all symbols from the debugger instance with an empty symbol path in the process dump, then separated and open the dump has a full symbol path, and forced to download all symbols to pre-caching process. Then, using the symbol path to start debugging session on real-time process, the symbol path only reference symbols downloaded to local downstream storage, to prevent any risk of network access.
Another common method that lets you debugger deadlock problems fall into is that when you have something to debug a program into the clipboard, use the clipboard into the WinDbg. This can lead to a similar deadlock because WinDbg may be blocked in the DDE request of the owner of the clipboard, and the clipboard owner will never be due to the commissioning and response. In this case, the solution is just to copy or paste text or copy from WinDbg WinDbg or to be careful when you paste text. - -Remote or use remote debugging .server be unstable or stop working correctly after a period of time. If all the debuggers different sessions running the debugger version, this situation may occur.
Ensure that all remote debugging scenarios peers use the (same) The latest version of the debugger. If the debugger version mix and match with -remote, in my experience, things tend to appear strange and hard to diagnose way (for the debugger remoting protocol backward or forward compatibility, it seems not too many decent support).
In addition, on Windows2000, the debugger package of several latest version does not work in remote debug mode. As far as I know, this is fixed in the latest version.
Once you know what to look for, most of these problems are easy to solve or avoid (although if you do not know it was found that these problems will certainly spend a lot of time, because I myself in the process of learning these "traps" in do these things).
If you encounter a strange WinDbg problem, you should not be ashamed to appear debugger debugger instances of failure itself. Normally, all threads debugger instance there is a problem in the stack trace is enough to make you understand what kind of problems have hindered the work (Remember, Microsoft public symbol server has a symbolic debugger binary files and operating system binaries) .