Instance analysis of dump file for Windows Phone app-stack Overflow

Objective

This article together we analyze a dump file that is downloaded from Windows Phone Dev Center. First, follow the steps in my previous article to set up our WinDbg, and hold down CTRL +d to open DumpFile. You can see the following interface:

Analysis of a dump file can be decomposed into 4 steps, the first step is information collection, the second step is to locate the exception context, the third step analysis and reasoning the cause of the problem, the fourth step to analyze and locate our source code and repair and verification. Information collection

We can use some of the commands to browse the system version of the dump file and the information of some modules to assist the analysis behind us.

1. Version command, view the system revision number

2. LM command to display the currently loaded module.

You can use the LMV command to view the details of all modules, if you want to see the details of a module, you need to use the parameter m, such as View system_data_linq_ni.dll details, "LMV Msystem_data_linq_ni"

Locating exception contexts

When an exception occurs, the context of the register is stored on the stack by the exception dispatcher. We can find and recover the context in which the exception occurred, and find the information we need from the context, using the "!analyze-v" command.

1. First confirm the thread where the exception occurred. Sometimes there are more than one thread that has an exception, and we need to confirm the thread where the exception occurred before using "!analyze–v". Use the ~* KVB command to view the call stacks for all threads. The "~*" command is to enumerate all the threads, and the "KVB" command is the call stack for the outgoing thread.

You can see that all the threads are waiting, only thread 0 is not, and from thread 0, callstack can see that thread 0 is the one we're looking for.

2. Switch to the thread where the exception occurred, "~0 S"

3. Use "!analyze–v", this extension command to help us find the context of the occurrence of the exception, and display the call stack at the time, in some cases the call stack given is not the first scene of the exception, encountered this situation we need to further analysis.

Analysis and speculation

In the above display, we found a very interesting managed call stack, which repeatedly appeared "System.Diagnostics.StackTrace." ctor () +0x12 ". It seems stacktrack this type of object calls its own member function getstackframesinternal when constructed, and this function again constructs a new Stacktrack object, so repeatedly that a loop call is made and the stack is exhausted. This does not give a call related to our code that looks much like a bug in the. NET Framework. So why would such a call happen? Let's continue with the analysis to see where this call was raised.

In order to find more clues, we can further see what happened to the line Cheng, we can view the properties of the current thread through the "!teb" command, and find the base and size of the stack, with the base and size of the stack, we can view the contents.

1. View the properties of the current thread, the "!teb" command

2. The DPS + address range command lets us view the information that is kept in the stack.

Skipping these invalid content, we continue to look back.

The red-line modules and functions are just the code in our app, and we can do a bold reasoning here. Our function decrementpendingandfinishifnecessary called the Logger.info function, which uses the stacktrace.capturestacktrace of the system to get the current call stack. So why is this function stacktrace.capturestacktrace to construct its own object? Let's open our program's source code for further analysis. Analyze and locate our source code

Opening our code and finding the implementation of Logger.info, the red code validates the reasoning above us. In some extreme situations, StackTrace creates a failure and throws an exception, which is called again by the subsequent catch block to call the logger function again, and this function creates an object of type StackTrace again, and continuing to trigger the exception causes repeated calls.

Private Static voidWriteLine (Level,stringmessage) {    Try    {        if(0==message. Length) {return; } StackTrace St=NewStackTrace ();//1. Here exception        stringname = St. GetFrame (2). GetMethod ().        Name; stringprefix =string. Format ("[{0}]@{1}", level, name); Message= prefix +"-"+message; }    Catch(Exception e) {logger.fatal ("faild in Writelog,message:"+ e.message);//2. Then execute here    }} Public Static voidFatal (stringmessage) {WriteLine (level.fatal, message);//3. Continue execution here 1, 1 continue exception}

Knowing the reason, we can modify the code to fix it, the simplest way is to first remove the call inside the catch.

Follow-up questions

So why does the system's Stacktrack getstackframesinternal fail? Interested students can try the anti-compilation command to see the details inside.

Share the code and change the world!

Instance analysis of dump file for Windows Phone app-stack Overflow