Use windbg + SOS to find out who occupies too high memory and who occupies too high CPU in the program

I have seen windbg + SOS knowledge for a long time and have never studied it carefully. Maybe the system I have built is not complex enough and I have no permission to view it in the real online environment, I have never learned this knowledge. I have carefully searched for this information in recent days and wrote a test web page that may result in high CPU and high memory, even if you have a chance, you can use a tool to guess what went wrong. Of course, if you are more familiar with some commands and internal labels, you can better locate the problem, it is worth learning. During use, I also encountered a lot of problems, such as system compatibility, software version ,. I have not been able to understand the Net version, but now I have used it to find out the program problems. Therefore, I have made a record to make it easier for myself or everyone to check the information.

Basic work:

Windbg I use is a 32-bit version of 6.11.1.404. Some errors of mscorlib were reported during the use of old windbg versions. I can't remember them, but someone else used them before. I really can't afford them. Just change the version to a new one.

Configuration and Common commands:

In the windbg main window, click the symbol search path under file to set the symbolic file path, for example, my c: \ windows \ symbols \ DLL; SRV * c: \ symbols * example. You can also set it from the registry, but I didn't set it in the registry.

In the debugging process, the windbg interface is as follows:

Generally, we can find the general problem of the program and 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 it to see the source code, especially if some DLL files are code from other teams, we can't see them.

Common Commands include:

The first step is generally. Load c: \ windows \ Microsoft. NET \ framework \ v4.0.30319 \ SOS. dll and load SOS to debug managed code

View CPU overhead commands such:

! Threadpool: view the CPU usage of the thread pool. I think if the CPU usage of the IIS application pool process w3wp for Web applications is too high, the thread pool command check must be too high, this is my own understanding, and C/S is not necessarily the case.

! Runaway: Check the CPU usage time of the thread. You can find the thread that occupies a higher time.

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

! Clrstack: view the managed code of the current thread after a specific thread

! Name2ee: Find the managed code module and view information such as methodtable and eeclass.

! Dumpmt, find the relevant information at the relevant methodtable.

! Dumpmd: Find related module information based on methoddesc, such as methodtable.

! Dumpdomain: displays the Assembly in all domains, or obtains the specified domain based on parameters.

! The savemodule generates the code of the current Assembly to the specified file based on the specific Assembly address.

To view commands that occupy too much memory, for example:

! Eeheap: View information in the heap. You can view large objects.

! Dumpheap: View heap information. It generally includes parameters such as-min,-Stat, and-type.

! Gcroot: view the reference code of the relevant module based on the heap address.

Of course, there are many other commands, which are also very useful. If you need to be proficient in windbg + SOS, you should take a closer look.

 

Start debugging:

Generally, you can directly attach Process Analysis to the dump file, save the dump file, and perform offline analysis separately. Online debugging: attach to a process directly. Generally, You can debug it offline.

Adplus. vbs generates the dump file. The command is adplus-Hang-o d: \ dump-P 1234. Hang indicates attaching it to the process. If it is-crash, it is captured when the target process crashes. The parameter after-O indicates that the dump file is placed in the description position, and the number after-P is the PID of the process, it can also be the process name after-PN. In my use process, the win7 system failed to capture w3wp process with adplus, but it was okay to catch other common processes. Finally, I used the process interface viewed by Windows Task Manager, right-click the w3wp process and right-click it to create a dump file. The dump file automatically generated by it is in the temporary directory. The size of the dump file created by it is much larger than the actual size of the current process.

 

The MVC2 code of my test program under vs2010 is as follows: Simulate common programs to cause excessive loops and bind static events to instance objects, resulting in excessive CPU usage if the memory is not released, the memory is too high.

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. net mvc! ";
8
9 myevent + = new eventhandler (testevent );
10 myevent (null, new eventargs ());
11 mymethod ();
12
13 return view ();
14}
15
16 public void mymethod ()
17 {
18 long I = 0;
19 while (I <999000000)
20 {
21 I ++;
22}
23}
24
25 public void testevent (Object OBJ, eventargs ARGs)
26 {
27 For (INT I = 0; I <20; I ++)
28 {
29 List. Add (New byte [1024*1024*10]);
30}
31}
32}

 

 

After accessing/home/index, my CPU immediately rose to around 50%, but the memory could not be seen, but after multiple accesses, the memory will become larger and larger.

After loading SOS, the following is my command record :(......... to omit more content, as the thread has switched to 25 when I record it, It is 0: 025>)

0: 025>! Threadpool
CPU utilization: 51%

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

Check which thread occupies 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> ~ 25 s
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

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

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. Net files \ Root \ 9f8ccc72 \ b9d96a8 \ Assembly \ dl3 \ 9b2cfeec \ scripts \ dumpwebtests. dll
Basesize: 0x38
Componentsize: 0x0
Slots in vtable: 45
Number of ifaces in ifacemap: 6

View All assemblies:

0: 025>! Dumpdomain

The following information is displayed:

Module name
008b689c c: \ windows \ Microsoft. NET \ framework \ v4.0.30319 \ temporary ASP. Net files \ Root \ 9f8ccc72 \ b9d96a8 \ Assembly \ dl3 \ 9b2cfeec \ Users \ 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

You have saved the analyzed program DLL to the out directory of the dump directory on disk D. DLL file. If the source code is available, you can view the code of the corresponding method directly. This will find the program with too high CPU. The specific reason is, of course, you have to analyze the code yourself,

If the analysis memory is too high, you can find the frequently used method in the previous steps. Here, we will not write it into the blog.

 

In fact, I am still unfamiliar with the method of debugging the windbg + SOS code, but I am still not familiar with it, as I mentioned at the beginning, as long as I am a little familiar with it, the contact belt deviation can still locate the problem and locate the problem accurately. Further study is required.

In this article, there may be something wrong. If you find it, please correct it to prevent yourself from having the same problems as everyone in the future :)