Basic windbg-2. Analysis and diagnosis of high CPU

Guidance:

Check the code first:

　　

　　

　　

　　

Code 1

　　

Using system; 2

　　

Using system. Threading; 3

　　

4

　　

Namespace highcpu 5

　　

　　

　　

　　

　　

{6

　　

Class program 7

　　

　　

　　

　　

　　

{8

　　

Static void main (string [] ARGs) 9

　　

　　

　　

　　

　　

{10

　　

Console. Clear (); 11

　　

Console. writeline ("go to the command line, switch to the windbg directory, and run adplus-Hang-PN highcpu.exe-o C: // dumps"); 12

　　

Console. writeline ("if you want to stop, press Ctrl + C to end the program"); 13

　　

Console. writeline ("========================================== ================== "); 14

　　

15

　　

While (true) 16

　　

　　

　　

　　

　　

{17

　　

Console. setcursorposition (0, 3); 18

　　

Console. Write (datetime. Now. ticks. tostring (); 19

　　

}

20

　　

}

21

　　

}

22

　　

}

23

　　

　　

Here we will introduce the content: in the production environment, we find that the CPU of aspnet_wp.exe0000w3wp.exe remains high for a certain period of time, or your own Windows service occupies a high CPU usage for a certain period of time. This is short for high CPU.

High CPU is relatively simple. Run adplus-Hang-PN highcpu.exe-o C:/dumps. For the actual production environment, generally, you need to do this: adplus-Hang-PN w3wp.exe-o C:/dumps

When dump is captured, do not worry. Wait for 2-3 minutes and try again (assuming that the cpu Of Your process is still high at this time). Wait for 2-3 minutes and try again. Generally, it is enough to catch three.

Open windbg and open the three dump files in sequence.

Load SOS:. Load clr20/SOS. dll

Run the following command :! Runaway, the result of the first dump is as follows:

0: 000>! Runaway

User Mode Time

Thread time

0: 12a8 0 days 0:00:00. 967

2: 148c 0 days 0:00:00. 000

0:00:00 0 days. 000

I can't see anything. continue to look at the second

0: 000>! Runaway

User Mode Time

Thread time

0: 12a8 0 days 0:00:05. 678

2: 148c 0 days 0:00:00. 000

0:00:00 0 days. 000

It's a bit interesting. continue to look at the third

0: 000>! Runaway

User Mode Time

Thread time

0: 12a8 0 days 0:00:10. 795

2: 148c 0 days 0:00:00. 000

0:00:00 0 days. 000

We can see that the Thread 0 execution time is growing, from the first 0 s to the current 10 s. From the current situation, the high CPU is basically caused by the code of Thread 0. Then, we will use the commands described above! Clrstack:

0: 000>! Clrstack

OS thread ID: 0x12a8 (0)

ESP EIP

0026edb8 774e0f34 [Clerk: 0026edb8] system. Io. _ lelestream. writefile (Microsoft. win32.safehandles. safefilehandle, byte *, int32, int32 byref, intptr)

0026edd4 7936b388 system. Io. _ lelestream. writefilenative (Microsoft. win32.safehandles. safefilehandle, byte [], int32, int32, int32, int32, int32 byref)

0026ee00 7936b2f4 system. Io. _ lelestream. Write (byte [], int32, int32)

0026ee20 7936ab1c system. Io. streamwriter. Flush (Boolean, Boolean)

0026ee38 793a7d8c system. Io. streamwriter. Write (system. String)

0026ee50 79499046 system. Io. textwriter + synctextwriter. Write (system. String)

0026ee5c 793ea4f6 system. Console. Write (system. String)

0026ee68 003e010f highcpu. program. Main (system. String [])

0026f0a8 79e7c74b [gcframe: 0026f0a8]

This is the first dump, from which we can see that it is calling console. Write

Next, let's look at the second dump. Similarly, we found the following code:

0026ee5c 793ea4f6 system. Console. Write (system. String)

0026ee68 003e010f highcpu. program. Main (system. String [])

Let's look at the third dump. Well, this is a little special.

0: 000>! Clrstack

OS thread ID: 0x12a8 (0)

ESP EIP

0026ee20 774e0f34 [ndirectmethodframeslim: 0026ee20] Microsoft. win32.win32native. setconsolecursorposition (intptr, coord)

0026ee34 793e8acb system. Console. setcursorposition (int32, int32)

0026ee68 003e00d5 highcpu. program. Main (system. String [])

0026f0a8 79e7c74b [gcframe: 0026f0a8]

Then, we can dump the Code through the dumpmodule Command introduced later, and then use reflector to decompile the code. Of course, it would be better if the customer wanted to provide the source code directly.

If you carefully compare the above three! Runaway results, you will find that the time is 0, 5, 10 seconds. In fact, I basically catch the Dump Based on the time progress. In the production environment, it is better to catch it every 2 or 3 minutes.

This CPU High is a little simpler. In complex cases, we will find dozens or hundreds of threads. After capturing dump, We will compare each of the three dump! The first 10 results of runaway (basically similar to this number), find the repeated threads, and then read the code to find the problem.

This article is transferred from

Http://www.cnblogs.com/juqiang/archive/2008/01/11/1035689.html