Analysis of dump file instances in Windows Phone App-Stack Overflow,

Analysis of dump file instances in Windows Phone App-Stack Overflow,
Preface

This article analyzes a dump file downloaded from Windows Phone Dev Center. First, set our Windbg according to the previous step, and press Ctrl + d to open dumpfile. You can see the following interface:

Analysis of a dump file can be divided into four steps. The first step is information collection, the second step is to locate the exception context, and the third step is to analyze and reason for the problem, step 4: Analyze and locate our source code and perform repair and verification. Information Collection

We can use some commands to view the system version of the dump file and the information of some modules to assist us in subsequent analysis.

1. Run the version command to view the system version number.

2. lm command to display the currently loaded modules.

You can use the lmv command to View Details of all modules. To view details of a module, you need to use the Parameter m, for example, to View Details of System_Data_Linq_ni.dll, "lmv mSystem_Data_Linq_ni"

Locate exception Context

When an exception occurs, the context of the Register is saved on the stack by the exception distributor. We can use some methods to locate and restore the context when an exception occurs, and find the information we need from the context. Here we use "! The analyze-v command.

1. First confirm the thread with exception. Sometimes there are more than one exception thread. We are using "! Before analyze-v, you must confirm the thread where an exception occurs. Use "~ * Kvb "command to view the call stacks of all threads ."~ * "Command is to enumerate all threads," kvb "command is to list the call stacks of threads.

It can be found that all threads are in the waiting state, and only Thread 0 is not. From the callstack of Thread 0, we can see that Thread 0 is the thread we are looking for that exception ,.

2. Switch to the abnormal thread ,"~ 0 s"

3. Use "! "Analyze-v", this extended command helps us find the context when an exception occurs and display the call stack at that time. In some cases, the call stack is not the first scene when an exception occurs, in this case, further analysis is required.

Analysis and speculation

In the above display, we found a very interesting managed call stack, which repeatedly showed "System. Diagnostics. StackTrace .. ctor () + 0x12 ". It seems that a StackTrack object calls its own member function GetStackFramesInternal during the construction, and this function constructs a new StackTrack object, as a result, the stack is exhausted due to repeated calls. The call related to our code is not provided here, which looks like.. net framework bug. So why is such a call? Let's continue to analyze and see where this call is triggered.

In order to find more clues, we can further check what is retained in the thread stack where an exception occurs. We can use "! Teb command to view the attributes of the current thread, and find the stack base address and size. With the stack base address and size, we can view the content.

1. view the attributes of the current thread ,"! Teb "command

2. The "dps + address range" command allows us to view the information retained in the stack.

Skip the Invalid Content and we will continue to check it later.

The module and function of the red line are exactly the code in our App. We can make a bold reasoning here. Our function DecrementPendingAndFinishIfNecessary calls the Logger. Info function, which uses the system StackTrace. CaptureStackTrace to obtain the current call stack. So why does this function StackTrace. CaptureStackTrace construct its own object? Let's open the source code of our program for further analysis. Analyze and locate our source code

Open our code and find the implementation of Logger. Info. The red code verifies our reasoning above. In some extreme situations, StackTrace fails to be created and throws an exception. This exception happens to be caught by the catch Block and the Logger function is called again, this function will create a StackTrace type object again and trigger an exception to cause repeated calls.

Private static void WriteLine (Level level, string message) {try {if (0 = message. length) {return;} StackTrace st = new StackTrace (); // 1. here exception string name = st. getFrame (2 ). getMethod (). name; string prefix = 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 void Fatal (string message) {WriteLine (Level. fatal, message); // 3. execute 1, 1 continue exception}

Once we know the cause, we can modify the code to fix it. The simplest way is to first remove the call in catch.

Follow-up questions

So why does the GetStackFramesInternal of the StackTrack fail? If you are interested, you can try to decompile the command to view the details.

 

Share code and change the world!