Windbg Load Dump File

.Table of contents.In my professional career, I have seen most of us use Visual Studio for debugging but not many of the other debuggers that come for free. You may want such a debugger for many reasons, for example, on your home PC which you do not use for development but on which a certain program crashes from time to time.

• Windbg Dump File
• Windbg Tutorial

From the stack dump, you can figure out if IE crashed because of a third party plug-in.I did not find any good quick starters for WinDbg. This article discusses WinDbg with examples. I assume you know the basic concepts of debugging – stepping in, stepping out, breakpoints and what it means to do remote debugging.Note that this is meant to be a Getting Started document, which you can read and start using WinDbg. To know more about specific commands, consult the WinDbg documentation. You can use the commands presented in this document with any debugger provided by Microsoft, e.g. From the Command window of Visual Studio.NET.This article is based on WinDbg 6.3.This is the first of a series of articles on debugging.

In my next article, I shall explain how to write debugger extension DLLs.A brief overview of the Windows debuggers that you can download for free from:. KD – Kernel debugger. You want to use this to remote debug OS problems like blue screens. You want it if you develop device drivers. CDB – Command-line debugger. This is a console application. NTSD – NT debugger.

This is a user-mode debugger that you can use to debug your user-mode applications. Effectively, this is Windows-style UI added to CDB. Windbg – wraps KD and NTSD with a decent UI. WinDbg can function both as a kernel-mode and user-mode debugger. Visual Studio, Visual Studio.NET – use the same debugging engine as KD and NTSD and offer richer UI than WinDbg for debugging purposes.FeatureKDNTSDWinDbgVisual Studio.NETKernel-mode debuggingYNYNUser-mode debuggingYYYUnmanaged debuggingYYYYManaged debuggingYYYRemote debuggingYYYYAttach to processYYYYDetach from process in Win2K and XPYYYYSQL debuggingNNNYWinDbg is a debugger that wraps NTSD and KD with a better UI. It provides command-line options like starting minimized (-m), attach to a process by pid (-p) and auto-open crash files (-z).

It supports three types of commands:. regular commands (e.g.: k). The regular commands are to debug processes. dot commands (e.g.:.sympath). The dot commands are to control the debugger. extension commands (e.g.:!handle) – these are custom commands that you can add to WinDbg; they are implemented as exported functions in extension DLLs.PDB files are program database files generated by the linker.

Private PDB files contain information about private and public symbols, source lines, types, locals and globals. Public PDB files do not contain types, local and source line information.Doing remote debugging using WinDbg is easy and can be done in one of a number of ways.

Windbg Dump File

In the following, ‘debugging server’ is the debugger running on the machine where you’d like to debug; ‘debugging client’ is the debugger controlling the session. Using the debugger: You need CDB, NTSD or WinDbg on the server. A WinDbg client can connect to any of CDB, NTSD and WinDbg, and vice versa. The server and client have choices of TCP and named pipes for communication protocol.

To start a server:. WinDbg –server npipe:pipe= pipename (note: multiple clients can connect), or. from within WinDbg:.server npipe:pipe= pipename (note: single client can connect)You can start multiple server sessions using multiple protocols. You can password-protect a session. To connect from a client:. WinDbg -remote npipe:server = Server, pipe = PipeName,password = Password.

from within WinDbg: File-Connect to Remote Session: for connection string, enter npipe:server= Server, pipe= PipeName ,password= Password. Using remote.exe: remote.exe uses named pipes for communicating. If you use a console-based application like KD, CDB or NTSD, you could use remote.exe to do remote debugging. Note: use @q (not q) to quit the client without quitting the server. To start a server:. Remote.exe /s “cdb –p ” test1.

To connect from a client:. Remote.exe /c test1test1 above is the arbitrary named pipe name we chose.Server will display who all are connected from which servers and commands executed. You can quit the server by issuing ‘qq’; or quit the client using File-Exit.

Windbg Tutorial

You’d need to belong to the “Debugger Users” user group and the server has to allow remote connectivity if you want to remote-debug.The section “Enabling Postmortem Debugging” in the WinDbg documentation discusses this well. In short, you can set WinDbg as the default JIT debugger by running Windbg –I. This sets the registry key HKLMSoftwareMicrosoftWindows NTCurrentVersionAeDebug to WinDbg.

To set WinDbg as the default managed debugger, you’d need to set these registry keys explicitly:. HKLMSoftwareMicrosoft.NETFrameworkDbgJITDebugLaunchSetting to 2. HKLMSoftwareMicrosoft.NETFrameworkDbgManagedDebugger to Windbg.With the JIT setting, WinDbg will be launched if an application throws an exception while not being debugged and does not handle the exception itself.All these debuggers support 64-bit debugging on AMD64 and IA64.WinDbg 6.3+ supports managed debugging, with the Whidbey.NET CLR. There is a good discussion on managed debugging in the documentation. Remember that there are no PDBs with managed code since managed code is compiled to ILASM; the debugger talks to the CLR to query extra information.Points to note:You can set a breakpoint at a managed code function only after it has been invoked at least once; because that is when it is JIT-compiled to ASM code.

Keep in mind:. Complications with function addresses and hence breakpoints:. The CLR can discard compiled code, so function addresses may change.

The same code may be multiply compiled if multiple app domains do not share the code. Ashok Srinath 23-Mar-Mar-16 10:22Thank you for this article - I'm still reading it, but it's very informative so far. Javaman 29-Nov-11 8:3929-Nov-11 8:39As we.NET Developers dive deeper into the MSFT OS, we find that there really is no substitute for WINDBG for the worst of the worst. I used this article today after having read it 5 years ago to solve an issue on our production servers today. Thanks for this post!!!!!This article will be valid for a long time.it is timeless.TIP: If you use WINDBG for.NET, make sure to first load SOS. '.loadby sos mscorwks' You can avoid parsing method tables looking for values by running!dso which will show values of parameters.

First, you need to install your debug driver along with its symbols. Then run msconfig on the target machine and go to boot - advanced options. Click on 'Debug' to enable the lower panel and select how you wish to connect: COM, Firewire, etc. Note down the baud rate/firewire port you set there and then make sure to have the host system ready and running WinDbg with the same parameters in 'Kernel Debug Mode'. Reboot the target machine.

If all goes well, upon reboot you should connect with the target machine. You'll also need a crossover COM cable and the corresponding COM port (you can also set up virtual COM ports with an USB-to-COM port driver). Alternatively you can also use Firewire or maybe a regular network cable, not sure about that. That's more or less how to set that up. Daniel Xu 26-Nov-Nov-07 17:39Hi,In Crash Dump Analysis, I set the right PDB file, and traced the right source code. How can I get the value of the variable?e.g.I have a Unicode String named szMyValue, in MyModules!MyFunction.

How can I located this variable in memory and get it's value?I have an idea to use Unassemble code get the value. I'm not the skilled guy to read assemble code.The command of 'dt' could only display data type, and the 'dv' command does not work at all.Do you have any new idea about my question? Need your help.Thanks.Daniel.