How to debug Windows CE application exceptions -- reprint

Whether you are a computer user or a senior software engineer, you must be familiar with program crashes. As a Windows CE application developer, you must have encountered this scenario:

In this dialog box, a program named installer.exe crashes at address 00019320. If you are responsible for this program, your problem arises: how can we find this bug? I want to talk about some of my experiences in this article.
The Windows CE crash interface provides very little information, the most useful of which is undoubtedly the crash address. If you can locate the source code from the crash address, this problem can be solved in half.
There are several methods to locate the source code from the address. One is to use the map file: You can generate a map file during the build program. A map file is a text file that records the address information corresponding to each function entry. In this example, view plaincopy to clipboardprint?

1. 0001: Pushed 82f4 ?? 1? $ Ccomptr @ uiimage @ ATL @ Qaa @ xz 000192f4 f I imageviewer. OBJ

0001:000082f4 ??1?$CComPtr@UIImage@@@ATL@@QAA@XZ 000192f4 f i ImageViewer.obj

The advantage of a map file is that it is a text file and can be read manually. The disadvantage is that there is not enough information to locate it at the function level, and you need to have enough experience to understand the map file, for example, the long and garbled string is the result of name mangling processing by the C ++ function. Without some experience, you cannot restore the actual function.
Another method is to use the PDB file, which collects debugging symbols for the application. The PDB file provides comprehensive information, but you need some tools to interpret it. If you are an experienced Windows desktop platform application developer, you may have heard of the Microsoft system journal magazine. If you have read this magazine before, you should be familiar with bugslayer. In this article, bugslayer introduces a tool called crashfinder. Crashfinder can directly locate the source code line that causes the crash by querying the corresponding PDB file from the crash address. Fortunately, since Windows CE executable programs and their PDB files are in the same format as Windows desktop systems, crashfinder can also be used to locate Windows CE program crash addresses. The result displayed by crashfinder is as follows:

The information provided by crashfinder is very useful, but not intuitive enough. Therefore, I provide a more convenient interface in Remote Process explorer, which can directly display the source code and generate the line of highlight that causes the crash:

The PDB file contains a large amount of debugging information to help you diagnose application errors. Therefore, you should generate and maintain these PDB files even for the official release version. The key to using the PDB file is that the crashed application must match the PDB file. Otherwise, it will not help you, But mislead you. Is the place where the PDB file and map file are generated in vs2005:

As mentioned above, the Windows CE crash interface provides very little information. In many cases, we still need more information to locate the problem. In addition, some Windows CE devices may have no monitors at all. To solve this problem, Windows CE outputs related crash information when the application crashes at the same time (usually a serial port. In this example, if you debug the serial port and enable HyperTerminal, you will see the following information when the program crashes: View plaincopy to clipboardprint?

1. Data ABORT: thread = 8d661000 proc = 81a477c0 'installer.exe & apos;
2. Aky = 00000401 PC 000000019320(installer.exe + 0x00009320) ra000000019094(installer.exe + 0x0
3. 0009094) BVA = 16080100 FSR = 00000007

Data Abort: Thread=8d661000 Proc=81a477c0 'installer.exe'AKY=00000401 PC=00019320(installer.exe+0x00009320) RA=00019094(installer.exe+0x00009094) BVA=16080100 FSR=00000007

I believe that Windows CE developers are also familiar with these lines of information. How can I use this information to diagnose program problems? The most critical information here is the address information provided by the PC and RA. PC is the crash address mentioned above. Use crashfinder or the crack address interface in my remote process explorer to locate the source code line that causes the crash; ra is the return address of the PC. Based on this address, you can find the upper-level function that causes the crash. This information is also very important, in many cases, the cause of the crash is that the upper-layer function passes invalid parameters to the underlying function. For example, your application calls the MFC function with an invalid window class, the crash address is in the MFC function, but the cause is in your call code. Source code corresponding to the RA address:

In addition to PC and Ra, other information can also be used as a reference: BVA is the fault Address Register (FAR) in arm and is the virtual address that causes data abort, for example, if your program tries to access the content in an illegal address, BVA is the illegal address in data abort; FSR is fault Status Register, specifying the cause of the exception, FSR can be explained here. Note that thread and proc do not provide thread ID/thread handle or process ID/Process Handle. They give pointers to the kernel objects corresponding to the thread or proc, similar to the concepts of Teb and peb on Windows NT platform. Because the thread has exited when you see the crash information, you cannot know which thread made the error Afterwards based on this information. In the future, I will introduce a system-level logging mechanism that records the thread ID and Teb of each log at the same time, in this way, the faulty thread can be found based on the Teb information of Data abort and the Teb in the previous log. In this way, you can not only locate the error source code, but also find the thread that runs the error code, which will greatly improve the efficiency of solving the problem.

Original address http://blog.csdn.net/singlerace/archive/2008/07/15/2655154.aspx