Sometimes when log files and standard troubleshooting does not yield the needed results in troubleshooting an issue a debug is desired.
Debugging with the use of a debugger involves examining memory of the computer. This can be done post-mortem or real time (live debug). The difference between the two is very simple. With post-mortem you create a dump that can be examined offline if needed and the system from which the dump was taken can resume operations. This limits the person(s) doing the debug because they can only see that moment in time.
A live debug involves halting execution for the given process or in the case of a kernel debug for the entire system. If one were connected to a live debug session that person can set a breakpoint where the system will halt execution. One can even modify memory or the run time version of the source code on the fly depending on the situation. Generally only simple programming errors can be live tested like this at runtime.
Not all debug situations require a kernel debug. Often in these situations no kernel mode debug is needed and no special configuration is required when the computer is booted. An example of this is debugging an application or non system service running on the system. Having the server booted in debug mode and fully configured for kernel debug is always better because while in a user mode debug session, the person doing the debug may need to also explore the kernel. The details of your situation should always be discussed prior to doing any configuration.
Many people will suggest you read Microsoft knowledge base articles on setting up the debugger. I now suggest using the help file as a sole resource for this.
General best particles on system requirements before live debugging
To debug your system you should be on the latest publicly available code:
Windows 2003 SP1 + All updates available in Windows update to include non critical updates
Windows XP SP2 + All updates available in Windows update to include non critical updates
Windows 2000 SP4 with URP + All updates available in Windows update to include non critical updates
Also test any hotfixes or updates which may resolve the issue, no sense in reinventing the wheel.
If the debugger system is connected to Internet you can use the preferred symbol server which contains most symbols.
Using this symbol path will download most of the needed symbols as needed and keep them at c:\websymbols, it will not download any excess symbols that you do not need.
If for some reason you need all of the symbols locally prior to the debug.
The symbol files must match the files actually running on the system. A symbol tree should be created.
Under each directory other directories will exist such as dll, exe, com, and such. A symbol file for ntdll.dll would be called ntdll.dbg or ntdll.pdb and would reside in c:\symbols\sp1\dll assuming that it was the sp1 version.
Symbols for the operating system can generally be downloaded from
The symbol path can be set in a batch file as follows:
Notice that in the above path hot fix was first so that if I was debugging a file that has a hot fix that goes with it that symbol is first in the search path.
Where do I get the debugger from?
Doing user mode debugging in the kernel debugger
Debugging user mode components generally involves the use of a user mode debugger. Because certain components are so critical to the operating of the system it makes sense to pipe the output of this debug session to the kernel debugger. This is especially useful when debugging any user mode process which is so critical to the system that debugging it effectively halts the operation of the system. Examples of this include services.exe, lsass.exe, winlogon.exe, or termsrv.exe or another user mode process that the server is dedicated to and debugging that process effetely takes the server down anyway.
In order to give the me or another engineer remote access to the debug session it needed to be shared out on a network which we have access to.
cdb -server tcp:port=1720 notepad.exe
or for the kernel debugger
kd -server tcp:port=1720
to test the remote you can connect from a client using the following command example for the kd session above assuming that the port being used is 1720 and the debugger system is called debug-laptop
kd -remote tcp:port=1720,server=debug-laptop
In this case 1720 is the port to use. If this port does not work well for your network administrators please contact me so that we can determine a port to work with, Microsoft does not allow outbound traffic on all ports.
To setup the preferred environment only one system needs to be directly on the Internet and that is the system that is running the debugger software. The system being debugged doesn't have to be on the Internet to debug it but can be very helpful for unrelated matters.
Dialing into the corporate network
If the problem being troubleshot is one which may also require us to access not just the debugger but other systems as well, and the system running the debugger is not on the Internet then providing a dial in account works well. The downfall to this method is speed.
Just provide the details of the dial in account and the remote.exe session can be accessed as described Q151981.
Dialing directly into the debugger system
If security is an issue and you would rather Microsoft have very limited access to your corporate resources this is one of the best solutions.
This requires setting up the debugger system as a RAS server and we would dial into this just as we would the corporate network
I need userdump where can I get it?
How can I just create a memory dump file on demand with Windows 2000 or higher??