Basic windbg-3. analysis and diagnosis of high CPU

View 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 ( " To stop the program, press Ctrl + C to end the program. " );
13 Console. writeline ( " ========================================================== ================ " );
14
15 While ( True )
16 {
17Console. setcursorposition (0,3);
18Console. 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.exe1_w3wp.exe isA period of time"Internal high, or your own Windows service,"A period of time"CPU usage remains high. 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
Then, run the following command:! RunawayThe 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, they provideSource codeThat's better.

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 is a little high. 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.