Use Windbg+sos to find out who is taking up too much memory in the program, who consumes too much CPU (reprinted)

Original address:

Http://www.cnblogs.com/Lawson/archive/2011/01/23/1942692.html

Very early to see the knowledge of Windbg+sos, has not studied carefully, perhaps because his system is not enough complex, and no online real-world view of the rights, has not learned this knowledge, in recent days carefully found this information, I also wrote a possible high CPU high memory test Web page , found that really good, even if a novice, you can also use the tool to deceive the guessing where the problem, of course, some commands and internal signs more familiar with, you can better find the problem, it is worth learning. I also encountered a lot of problems in the use of the process, such as system compatibility, software version,. NET version, and so on, some of which I did not understand clearly, but now do use it to find the problem of the program, so make a record for yourself or everyone to access the information to provide a certain convenience.

Basic work:

I use the WinDbg is the 32-bit version of 6.11.1.404, Microsoft Official website: http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx#b, SOS is every. NET framework comes with, I use. net4.0 's SOS.dll, mine in C:\Windows\Microsoft.NET\Framework\ v4.0.30319 inside, in addition I also used the modal PDB symbol file, if not downloaded, can be configured to download automatically when needed, but the download needs to select the operating system version. WinDbg old version of the use of the process reported mscorlib what error, specifically can not remember, but before others used to, I really can't afford to change the new version is good.

Configuration work and Common commands:

In the WinDbg main window, click Symbol Search path under file to set the symbol file path, such as my: c:\windows\symbols\dll;srv*c:\symbols*http:// Msdl.microsoft.com/download/symbols, in fact, C:\symbols is my download symbol file installation location, http://msdl.microsoft.com/download/ Symbols this is necessary, because the symbol file cannot be found, it will be downloaded from here automatically. You can also set it from the registry, but I did not set it in the registry.

I windbg the interface as follows during the debugging process:

Generally we find the program problem in general, you can directly view the corresponding code, if there is no source code, we can also use WinDbg to export the code of the specified assembly address, and then decompile to see the source code, especially for example, some DLL files are other team code, we do not see the time.

Common commands such as:

The first step is generally. Load C:\Windows\Microsoft.NET\Framework\v4.0.30319\SOS.dll, loading SOS so you can debug managed code

View causes CPU high command such as:

!threadpool, look at the thread pool CPU usage, I think the web, such as the IIS application pool process w3wp If the CPU is too high, the view thread pool command must look too high, this is my own understanding, C/s is not necessarily.

!runaway, the view thread consumes CPU time and can find out which thread takes up more time.

~number S,number is the ID of the specific thread.

!clrstack, after a specific thread, view the managed code for the current thread

!NAME2EE, after finding which managed code module, view information such as Methodtable,eeclass.

!DUMPMT, find relevant information about methodtable.

!DUMPMD, according to MethodDesc to find relevant module information, such as MethodTable.

!dumpdomain, displays the assemblies in all domains, or gets the specified domain based on the parameters.

!savemodule, the code of the current assembly is generated to the specified file according to the specific assembly address

To view commands that consume too much memory, such as:

!eeheap to view the information in the heap, you can view the large objects.

!dumpheap, view the information in the heap, usually with parameters such as-min,-stat,-type.

!gcroot, according to the heap address, view the relevant module reference code information.

Other commands, of course, are very many, but also very useful, when needed to turn over the information, if you need to be proficient in windbg+sos, or honestly carefully look at it.

To start Debugging:

General analysis dump file, you can directly attach the process analysis, you can also save the dump file, and then separate offline analysis. Online debugging, direct attach to a process can be, general offline debugging, can be used WinDbg

ADPlus.vbs generate dump file, the command is as follows: Adplus-hang-o d:\dump-p 1234, where hang means attaching to the process, if it is-crash, then the target process crashes, and the parameter after-o indicates that the dump file is placed in the description location , the number after-P is the PID of the process, or it can be-PN followed by the process name. In my use of the process, Win7 system, with ADPlus crawl w3wp process old failure, catch other normal process no problem, finally I use the Windows Task Manager to see the process interface, click W3WP Process, right button to create a dump file, It automatically generates the DMP dump file to the temp directory, where it creates a dump file that is much larger than the actual size of the current process.

The MVC2 code of my test program under VS2010 is as follows: simulating common programs causes loops to be too large, static events bound to instance objects, causing the CPU to be too large and over-memory to be caused by not releasing memory.

1 public class Homecontroller:controller
2 {
3 public static event EventHandler MyEvent;
4 list<byte[]> List = new list<byte[]> ();
5 public ActionResult Index ()
6 {
7 viewdata["Message"] = "Welcome to ASP. mvc!";
8
9 MyEvent + = new EventHandler (testevent);
MyEvent (NULL, New EventArgs ());
MyMethod ();
12
return View ();
14}
15
public void MyMethod ()
17 {
A long i = 0;
while (I < 999000000)
20 {
i++;
22}
23}
24
public void TestEvent (object obj, EventArgs args)
26 {
(int i = 0; i <; i++)
28 {
List. ADD (New byte[1024 * 1024 * 10]);
30}
31}
32}

After accessing/home/index, it caused my CPU horse to rise to about 50%, the memory is not visible, but after multiple accesses there will be more and more memory that cannot be freed.

After first loading SOS, here is my command record: (...). To omit more content, because the thread has switched to 25 when I record it, the 0:025> is displayed.

0:025>!threadpool
CPU utilization:51%

...................

See what threads occupy a bit more CPU

0:025>!runaway
User Mode Time
Thread time
25:920 0 Days 0:00:03.042
0:150c 0 Days 0:00:00.046
9:6c 0 Days 0:00:00.015
27:1598 0 Days 0:00:00.000
26:15cc 0 Days 0:00:00.000
24:1084 0 Days 0:00:00.000

Switch to 25 Threads:

0:025> ~25s
EAX=2362D4FC ebx=00000000 ecx=00000001 edx=00000000 esi=01c9e838 edi=01ca4934
eip=00d70746 esp=0e2dee44 ebp=0e2dee58 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
00d70746 8BD9 mov ebx,ecx

To view managed code:

0:025>!clrstack
OS Thread id:0x920 (25)
Child SP IP Call Site
0e2dee44 00d70746 DumpWebTests.Controllers.HomeController.MyMethod ()
0e2dee60 00d70580 DumpWebTests.Controllers.HomeController.Index ()

...............................

0:025>!NAME2EE * DumpWebTests.Controllers.HomeController
module:64bd1000
Assembly:SMDiagnostics.dll

................

module:008b689c
Assembly:DumpWebTests.dll
token:02000004
methodtable:0130002c
eeclass:00c84348
Name:DumpWebTests.Controllers.HomeController

To view module information:

0:025>!DUMPMT 0130002c
eeclass:00c84348
module:008b689c
Name:DumpWebTests.Controllers.HomeController
mdtoken:02000004
File:c:\windows\microsoft.net\framework\v4.0.30319\temporary ASP. files\root\9f8ccc72\b9d96a8\assembly\dl3\9b 2cfeec\916cd56e_eebacb01\dumpwebtests.dll
basesize:0x38
componentsize:0x0
Slots in vtable:45
Number of ifaces in Ifacemap:6

To view all assemblies:

0:025>!dumpdomain

View the following information:

Module Name
008b689c C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP. files\root\9f8ccc72\b9d96a8\assembly\d L3\9b2cfeec\916cd56e_eebacb01\dumpwebtests.dll

ASSEMBLY:00E4B2C8 [C:\Windows\assembly\GAC_MSIL\System.Web.Mvc\2.0.0.0__31bf3856ad364e35\System.Web.Mvc.dll]
Classloader:00e234f8
securitydescriptor:00e82280

Save the Assembly:

0:025>!savemodule 008b689c D:\dump\out.dll
3 sections in File
Section 0-va=2000, VASIZE=39C4, fileaddr=200, filesize=3a00
Section 1-va=6000, vasize=320, FILEADDR=3C00, filesize=400
Section 2-va=8000, Vasize=c, fileaddr=4000, filesize=200

Has analyzed the problematic program DLL saved to the D-Disk dump directory Out.dll file, if there is source code, of course, you can directly see the corresponding method of code, this is the CPU too high program found, the specific reason of course, but also to analyze the code,

The method of analyzing the memory is too high, the common method in front of the steps can be found, here is not written in the blog.

In fact, I also Windbg+sos debugging the way the code is unfamiliar, is not familiar, but still like the beginning said, as long as a little more familiar with, even if the poor still can generally find the place of the problem, pinpoint the problem, or need further study.

In this article, perhaps there is a wrong place, if found, please correct me, to prevent yourself and everyone after the same problem:)

Use Windbg+sos to find out who is taking up too much memory in the program, who consumes too much CPU (reprinted)