Debugging StackOverflowException Exceptions using WinDbg

Recently, the company server-side program encountered a stack overflow problem, but it is sporadic but in a relatively fixed time, there is a server easier to trigger, the average interval of 5, 6 days will occur once, and each time around 8:23 throws an exception. Server development colleagues preliminary positioning is the timer out of the problem, simply look at the code to see no problem, hit the log also did not see the useful information (in fact, here is a bit of ability problems, embarrassed ~ See the code is not serious and meticulous. The log did not hit the point). The eldest brother threw this question to me, let me go to solve, hint with some tools to test directly, for example WinDbg, so began WinDbg journey.

Internet search for the next WinDbg related blog, mainly from the following two articles benefited a lot.

Article 1. NET application debugging-principles, tools, methods

Article 2 windbg-How to crawl dump files

　　WinDbg Tools: http://www.microsoft.com/whdc/devtools/debugging/default.aspx

After reading the article decided to use the analysis of DMP files to solve this problem.

The first is to get the dump file. Although the Windows system comes with the task manager can easily dump files, but due to the 64-bit system and 32-bit process (the problem of the daemon) problem, this way to obtain a DMP file with WinDbg analysis of things, will always report some mistakes, so in other ways, There are two of the more reliable, from the above article is mentioned in the separate.

One is mentioned in article 1, using the NTSD tool in the Windows Debugging Toolbox, Step: 1, cmd Run the command "Windows Debug Toolbox installation directory \x86\tlist" To view the PID of all processes, find the ID of the crash process. 2. CMD Run command "Windows Debug Toolbox installation directory \x86\ntsd-pv-p process pid". 3. Run the command ". DUMP/MF dmp file path" in the NTSD interface to generate the DMP file.

Second, the article 2 refers to the direct use of WinDbg to dump files, open the "Windows Debugging Toolbox installation directory \x86\windbg.exe", click File->attach to a process-> Select the process of crash- > Click OK, go to crawl dump interface, enter ". Dump-ma dmp File path" on the command line to generate the DMP file.

Note that the steps here need to be performed on the machine where the crash is occurring and not before shutting down the process after the crash has occurred, and here is the Toolbox under x86, which can be referenced in this article Windbg Choice of 32-bit and 64-bit editions .

After you get the DMP file, you can open it with the x86 version of the WinDbg tool. Here is a brief description of the commands used in debugging. The use of methods in article 1 is mentioned in article 2.

. Sympath Path

. symfix+ Path

. reload

. Loadby SOS CLR

!analyze-v

!threads

~0s

!clrstack

It is best to place the symbol path in the directory where the program is located, with a PDB file. When you use!threads to get all the threads, which thread occurs exception will be displayed, use the ~0s command to enter the thread, use!clrstack to see the call stack, so you can see the problem.

Roughly like this, I see the code that's having the problem, There is a timing event occurred in the daily 5.50 points, in the trigger because of code problems, there will be a small probability that the next time (that is, tomorrow, 5.50 minutes) is set correctly, resulting in today's event has been in the trigger, and each timer poll is 3 seconds interval, to 8.23 points just stack overflow.

At this point, the problem is resolved. The first time to write a blog, not how to edit, will see first. Because the time is not enough, the content is not detailed, then slowly add complete.

Debugging StackOverflowException Exceptions using WinDbg