Dump File Analysis of Windows Phone App,

Dump File Analysis of Windows Phone App,
Preface

After we release our own App, Windows Phone's Error Report mechanism will help us collect program crash information and send it to Microsoft's server, which can help developers improve App stability.

So how can we use these dump files? First, we need to download these dump files from the Microsoft developer website, and then use debugging tools for analysis. Here we choose Windbg. Download procedure

1. login http://dev.windows.com/en-us/dashboard

2. Select Windows Phone Store

3. Go to Reports, select Crash count, select App and date, and click Refresh.

4. Click Export stack traces, which includes the crash transfer records for the last 30 days.

5. Develop the downloaded Excel file, which contains nine columns. They are the App name, App ID, App version number, operating system version number, problematic function, exception type, and the total number of crashes within 30 days, stack tracing and Dump File.

6. We can use column E and column F to quickly check whether the crash was caused by our App, and then click Download dump file for analysis.

Use Windbg to open dump file

1. Download windbg from Microsoft Website:

Http://msdn.microsoft.com/en-us/library/windows/hardware/ff551063 (v = vs.85). aspx

2. Run windbg, choose to open crash file from the file menu, or press Ctrl + D.

3. Set the symbol server,

A. You can use the shortcut key Ctrl + S:

B. Or run the ". sympath" command:

. Sympath srv * e: \ bclCache * http://msdl.microsoft.com/download/symbols

C. You can also use ". symfix"

4. After specifying the symbol server, we need to reload the symbol file and input ". reload" in the Command window ". You can use the shortcut key Alt + 1 to locate the command window.

5. Load the SOS module. SOS. dll is an extended command module written by Windbg to debug managed code. The latest windbg will automatically load this module.

6. Check whether the SOS version is correctly loaded. First, check the version number of coreclr. dll and compare whether the installed SOS. dll version is consistent.

A. Enter "lmv mcoreclr" in the Command window ". The command lmv prints the module information. The m + Module name is used to specify the module to be printed. The information of the coreclr module is printed here.

B. Enter ". chain" in the Command window ". This command displays the default loading sequence for all loaded debug extension modules.

Compare the version number of the coreclr module with that of the first in the search chain. If they do not match, we can use ". unload" to unload the loaded SOS module and use ". load + path" again to select the correct item in the extended Dll search chain. For example:

. Unload e: \ bclcache \ symbols \ sos_x86_ARM_4.0.50829.00.dll \ 503D5669449000

. Load c: \ Debuggers \ SOS

. Chain again to check whether the first matching Summary

Now we know how to download the dump file and use windbg to open it. In the subsequent articles, I will give some examples to illustrate how to find the wrong code.

 

Share code and change the world!

Windows Phone Store App link:

Bytes

Windows Store App link:

Http://apps.microsoft.com/windows/zh-cn/app/c76b99a0-9abd-4a4e-86f0-b29bfcc51059

GitHub open source link:

Https://github.com/MS-UAP/cnblogs-UAP

MSDN Sample Code:

Https://code.msdn.microsoft.com/CNBlogs-Client-Universal-477943ab

MS-UAP

January