Example analysis of dump file for Windows Phone app-System.ExecutionEngineException

Source: Internet
Author: User
Tags try catch

Objective

Before starting this article, let's talk about how to find the correct exception context address from a highly optimized release version of dump and manually recover the first scene of the exception that occurred.

1. What is the exception context

Simply put, within the Windows system's operating system, each thread has its own thread context to hold the required information, including the value of the current register. The exception context we need to find here is that when an exception occurs, the exception dispatcher helps us save the value of the current register (also called the Register context), and with this information combined with the analysis of the assembly code, we can further find out why the exception occurred. About the definition of the context structure of a register we can find it in the winnt.h, which is not explained here.

2. The ". CXR + Context Address" command in Windbg can help us recover the primary data of the register at the time of the exception, so we just need to find the address of this context to be processed by this command.

3. How do I find the address of the save context?

When we use WinDbg to open dump file, we will see a call stack pattern similar to the following:

This formal exception dispatcher helps us save the context, let's look at Rtldispatchexception's function declaration, which uses the "x" command:

As you can see, the second parameter of this function is the context address we're looking for.

4. With this context address, we can use the ". CXR" command to recover. The second parameter here is 00c2e168, which executes the ". CXR 00c2e168" command.

5. Is this value really right? The context at which the exception occurred is restored, so let's look at the change in the call stack

The value of this stack and register seems so bizarre that we have doubts about the address above!

6. Consider that the dump file is from the release version of the app, the compiler will be generated in the release version of the executable to do a lot of optimization, in this case, the function call will use our register to the greatest extent to pass parameters, rather than relying on @esp+0x? Thought of here, let's go back to rtldispatchexception to check it out again.

7. Use ". Frame + index" to jump to the stack frame specified in the call stack and use the "DV" command to view local variables

This time we clearly saw the contents of the registers R6 and R9, which is the result of the code optimization. The compiler optimizes the code to use R6, R9 two registers instead of "stack operation" for the reference.

8. Use ". CXR" and "K" again, this time we'll see the real anomaly happen first scene

The original LDR command attempted to load an empty address causing a disaster.

Now that we have learned how to identify the correct context address in the highly optimized release version, we continue to look for the reason why the program is crashing.

Locating exception contexts

1. We found the real exception context, which looks at the call stack first.

2. Let's see what Fontfilereference::releasefragment has done, using the command "UF module name! Function name" to decompile the function.

3. Review the contents of the stack frame of this function again to assist us in understanding the assembly code above, ". Frame + Frame Index"

4. Use the command "DT module name! Class name" To view Fontfilereference's memory layout

Analysis and speculation

1. From the call stack can be seen, the following statement triggered an exception, where the instruction is performing the operation of the load register, load R3 Register the address stored inside, but r3=0, we cannot help but ask, R3 why is 0, and this r3 inside should be what?

2. Key analysis Register, R3. Here to share a look at the assembly instructions, in fact, we do not use each line of the analysis, the simple way is to find the key instructions! In this case, I put the following command as a key command:

Why are these lines classified as key directives? This is because "r0, #0x10" and BLX appear here. Here the "r0, #0x10" is the meaning of "R0 + 0x10", "BLX" is called the sub-function meaning. Combined with the structure of the Fontfilereference class, we can reasonably guess that the address inside the R0 should point to the this pointer, then R0 + 0x10 is fontfilereference the member variable "STREAM_" in this class.

We already know that the r0 inside is the this pointer, R3 inside is pointing to the type of comptr<idwritefontfilestream> COM object STREAM_, then what is the next r3+0x10? The definition of Idwritefontfilestream can be found in dwrite.h and can be displayed using "dt/v".

We know that the first three functions of the COM interface inherited from IUnknown must be queryinterfacy,release and AddRef, so r3+0x10 is the function of releasefilefragment. The layout is roughly as follows:

Here we need to explain why we are "guessing" instead of invoking the "DT this" command directly to see the current Fontfilereference object. Because this dump was generated by release, a lot of the information has been invalidated:

3. Through the above analysis, we know that the main task of this assembly code is to invoke "Stream_->releasefilefragement". Comparing the information given by the "!analyze–v" command validates our guesses and concludes that it is STREAM_ that the variable is null, which results in an exception. Let's take a look at what useful information is in this thread heap:

Analyze and locate our source code

The remaining information in the stack also points to the font,fontfamily related content, from the native callstack we can not locate our code, here use "! CLRStack "command to see the invocation information in our CLR's Code stack:

The code of the Red line is our own code, okay. Open the code to see:

From this code we did not specify the FontFamily property when we created the TextBlock dynamically. Programmers in the development of code and testing, this exception does not appear, from the Excel file we downloaded, this exception appears only on the WP8.0 platform, 30 days caused by the cumulative number of flash back is 4,000 times. This number is very small compared to the activity of our app. So we can infer that this bug should be a system problem, it is likely that stream_ this COM object's ref count increment and decrement operation in the absence of the specified fontfamily in some special cases, it caused the STREAM_ was released early. Since it's a systemic problem, what can we do? First, we can specify a fontfamily to the control TextBlock, and secondly, add a try catch on the render call Createwidetilebackgroundimage this function to capture this " System.ExecutionEngineException ".

Summary

Although sometimes the problem is caused by the system, but through analysis we can still take some measures in our code to deal with.

Dump file instance analysis for Windows Phone app-System.ExecutionEngineException

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.