WinDbg debugging. NET program entry, windbg debugging. net
As the saying goes:Everything starts with hard!
Since I came to a new company and encountered performance problems, I had to find a solution to this problem, but I had never had a proper performance analysis tool. Then I found out how to help me, he used the WinDbg tool to remotely analyze a dump file, but he only saw the keyboard "Snap" and got the result, but he didn't know exactly how to use the WinDbg magic. As a result, the next day, the performance problem came up again, so I had to start learning WinDbg myself. Here I will record a getting started process.
1. First, download and install the WinDbg Program
Open from the following address:
Https://msdn.microsoft.com/en-us/windows/hardware/hh852365
Then you can see
Standalone Debugging Tools for Windows (WinDbg)
Download.
After the installation is complete, there are shortcuts for the WinDbg (x86) and WinDbg (x64) programs in the "Start" Windows Kits folder. If you want to debug
For 64-bit programs, use WinDbg (x64 ).
2. Create a memory dump file
You can create a dump file in Task Manager, process-> to get the dump file of the current process. I used the following program to generate the dump file:
Procdump
: Https://technet.microsoft.com/en-us/sysinternals/dd996900.aspx
For the use of the ProDump program, refer to the following two blog articles:
High CPU Dump collection tool-ProcDump usage
This article introduces a useful dump capture tool-ProcDump
In the command line, run this program:
procdump -ma mydotNetApp.exe d:\myapp.dmp
After running, you will get a myapp. dmp file. If the file is generated on the local machine, VS2013 can open the file directly and analyze the managed memory. However, usually the memory dump file is generated on the server, the server is likely to be different from the development environment, so we need the WinDbg introduced in this article for debugging.
3. Configure the debugging environment
First, open the dump file. You can use the menu command to open it:
File-> Open Crash Dump...
After opening, the environment where the program is running is displayed. At this time, the system prompts that the symbolic file is not found:
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll -
If this parameter is not configured, an error is prompted when you use the command, for example:
0:000> .loadby sos clrjit0:000> !tp*** ERROR: Symbol file could not be found. Defaulted to export symbols for clr.dll - ************* Symbol Loading Error Summary **************Module name Errorclr PDB not found : e:\appserver\symbols\dll\clr.pdb
E: \ appserver is the directory where my dmp file is located. By default, it goes to the symbols subdirectory to find the symbol file.
Then, configure the debugging environment for this file.
In the menu command File-> Symbol path... open the dialog box, select Browse, and find the program file directory E: \ AppServer related to the directory where the dmp file is located. The directory contains the program-related exe and pdb files.
Enter the following command:
0: 000>. sympath + c: \ symbolsSymbol search path is: E: \ AppServer; c: \ symbolsExpanded Symbol search path is: e: \ appserver; c: \ symbolsError: Attempts to access 'C: \ symbols 'failed': 0x2-the system cannot find the specified file. * Response Time (MS) LocationOK E: \ AppServerError
This folder can be generated later.
0:000> .symfix0:000> .symfix+ c:\symbols0:000> .sympathSymbol search path is: srv*Expanded Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols************* Symbol Path validation summary **************Response Time (ms) LocationDeferred
That's right.
Run the reload command:
0:000> .reload............................................................................................................................................
Run the following command:
0:000> .loadby sos clr0:000> !tpThe version of SOS does not match the version of CLR you are debugging. Pleaseload the matching version of SOS for the version of CLR you are debugging.CLR Version: 4.0.30319.296SOS Version: 4.6.96.0Failed to load data access DLL, 0x80004005
Note that the SOS version does not match the CLR version. You need to find the Dump file generated at the time.Sos. dll on the server where it is located, Note that because the server program is 64-bit, it must be in.. Net Framework64 directory, and set mscordacwks. copy the dll file together (this is not required for the moment, as will be discussed below ).
After executing this command, we were pleasantly surprised to find that the c: \ symbols directory was created by ourselves and the clr was downloaded. pdb and other directories. This is the sos copied on the server. dll, mscordacwks. dll and put it under the c: \ symbols directory of the local machine.
Execute these commands again:
0:000> .reload............................................................................................................................................0:000> .loadby sos clr0:000> !tpThe version of SOS does not match the version of CLR you are debugging. Pleaseload the matching version of SOS for the version of CLR you are debugging.CLR Version: 4.0.30319.296SOS Version: 4.6.96.0Failed to load data access DLL, 0x80004005
An error is reported. It seems that sos. dll is not correctly loaded. Use the following command:
0:000> .load c:\symbols\sos.dll0:000> .loadby sos clr0:000> !tp
Here, the load command must contain the SOS. dll path. Load it, and then execute. loadby sos clr to debug the. NET Host Program.
When a long wait starts, the program window prompts:
* BUSY *
Downloading symbols for [clr. pdb]/
After all the symbolic files have been downloaded, a long-overdue success page is displayed:
CPU utilization: 11%Worker Thread: Total: 8 Running: 0 Idle: 8 MaxLimit: 32767 MinLimit: 8Work Request in Queue: 0--------------------------------------Number of Timers: 14--------------------------------------Completion Port Thread:Total: 1 Free: 1 MaxFree: 16 CurrentLimit: 0 MaxLimit: 1000 MinLimit: 8
4. Get help information
For detailed debugging naming of WinDbg, refer to the following article:
Windbg debugging command
Http://www.cnblogs.com/kekec/archive/2012/12/02/2798020.html
Alternatively, you can use help to view how to use it at any time:
0:000> !help-------------------------------------------------------------------------------SOS is a debugger extension DLL designed to aid in the debugging of managedprograms. Functions are listed by category, then roughly in order ofimportance. Shortcut names for popular functions are listed in parenthesis.Type "!help <functionname>" for detailed info on that function. Object Inspection Examining code and stacks----------------------------- -----------------------------DumpObj (do) ThreadsDumpArray (da) ThreadStateDumpStackObjects (dso) IP2MDDumpHeap UDumpVC DumpStackGCRoot EEStackObjSize CLRStackFinalizeQueue GCInfoPrintException (pe) EHInfoTraverseHeap BPMD COMStateExamining CLR data structures Diagnostic Utilities----------------------------- -----------------------------DumpDomain VerifyHeapEEHeap VerifyObjName2EE FindRootsSyncBlk HeapStatDumpMT GCWhereDumpClass ListNearObj (lno)DumpMD GCHandlesToken2EE GCHandleLeaksEEVersion FinalizeQueue (fq)DumpModule FindAppDomainThreadPool SaveModuleDumpAssembly ProcInfo DumpSigElem StopOnException (soe)DumpRuntimeTypes DumpLogDumpSig VMMapRCWCleanupList VMStatDumpIL MinidumpMode AnalyzeOOM (ao)Examining the GC history Other----------------------------- -----------------------------HistInit FAQHistRootHistObjHistObjFindHistClear
You can also use the. help Command. Different commands are listed here:
0:000> .help. commands: .allow_exec_cmds [0|1] - control execution commands .allow_image_mapping [0|1] - control on-demand image file mapping .apply_dbp [<options>] - add current data breakpoint state to a register context .asm [<options>] - set disassembly options .asm- [<options>] - clear disassembly options .attach <proc> - attach to <proc> at next execution .block { <commands> } - brackets a set of commands for nested execution .break - break out of the enclosing loop
You can also use the. hh command:
Use ". hh <command>" or open debugger. chm in the debuggers directory to get
Detailed documentation on a command.
OK. Now we are getting started with dump file generation, debugging environment configuration, and help commands.