How can I see the 'data abort 'error?

Http://www.armce.com/bbs/thread-194-1-1.html

I said on the Internet that 'data abort 'was caused by memory leakage. Later I went to Microsoft to watch ce Memory leakage videos. I found that the debugging software was too busy when I came back from ce5.

114087 PID: 400002 TID: 4db0016 exception 'data abort '(4): thread-id = 04db0016 (PTH = 997cad5c), proc-id = 00400002 (PPRC = rjbf308) 'nk. EXE ', Vm-active = 04c8000e (PPRC = 9954a560) 'esample.exe'
114090 PID: 400002 TID: 4db0016 Pc = c01cf8ec (GWES. dll + 0x0004f8ec) Ra = c01cf8e4 (GWES. dll + 0x0004f8e4) sp = d1e9fde0, BVA = 00001002

It seems to be a memory configuration problem, config. bib, you should check whether the changes have been made.

========================================================== ======

The main point is to look at PC = c01cf8ec (GWES. dll + 0x0004f8ec). You can find the function with the offset 4f8ec and find the function based on GWES. Map. Then refer to GWES. PDB to find the source code.

========================================================== ======

I cut a section from your map, which contains the offset of 0x0004f8ec.
From the above, 0x0004f88c <0x0004f8ec <0x0004f914
Therefore, the address offset 0x0004f8ec must be the code segment in the middle of the function at 0x0004f88c. We found that the address is in the setfontsmoothing API.
So you can use map to locate the function.
The second step is to locate the code location. I may recall it wrong. The PDB format is binary, and there is a cod format to see which line of code has a problem.

========================================================== ======

The setfontsmoothing function may not be exposed to the system's GDI function. It may be called indirectly by other GDI functions. GWES generally does not have code errors. It must be a problem when processing the pointer you sent to it, check whether there are any problems with the objects of all your GDI operations.

========================================================== ======

COD may need to be modified to generate the makefile. You simply add kitl and check the callstack.

========================================================== ======

PC = c01cf8ec (GWES. dll + 0x0004f8ec) This is the key
You can add wincecod = 1 to sources. Remember that.

========================================================== ======

Teacher walle, you may have made some mistakes, not setfontsmoothing.
After debugging these days, you can confirm that the timerentry of GWES. dll starts the breakpoint
The offset of PC = c01cf8ec (GWES. dll + 0x0004f8ec) is the preferred load address of GWES. dll is 10000000 plus 0x0004f8ec;
That is
0001: 0004e8c4? Isvalidtimerentry @ timerentry_t @ qaa_nxz 1004f8c4 F gwes_lib: timer. OBJ
0001: 0004e940? Timerqueuesremovesingleevent @ timerentry_t @ sapau1 @ pauhwnd __@ @ ipavmsgqueue @ Z 1004f940 F gwes_lib: timer. OBJ
0001: 0004ea38?
Between

From the debugging of cedubgex, we know that the thread for processing this is IE's "new window" thread.

========================================================== ======

I may have neglected this, that is, each process's low 0x1000 is reserved, which is the same as ce5.
Therefore, the algorithm must first subtract 0x1000 from the query table, so it is 0x4e8ec to query the map, and the result will be consistent with yours.
Thank you for your attention.
---------------
|
| Dataabort | 0x0004f8ec --> 0x0004e8ec of the address in the map
|
| ------------ | 0x00001000 --> 0x000000000 of the address in the map
| Reserved |
------------ -- 0x00000000
But you are a DLL, and you do not know whether you can use this method to determine

========================================================== ======

Windows CE: finding the cause of a Data abort

For Windows CE 5.0 and 6.0 looking up the instructions that caused the data abort is easier than in previous versions. The module name and offset are encoded in the Data abort output. Take the following case:

Exception 'data abort '(4): thread-id = 00df0002 (PTH = 87e31c98), proc-
Id = 00400002 (PPRC = 81118308) 'nk. EXE ', Vm-active = 015f0002 (PPRC = 87e07b70) 'udevice.exe'
PC = c098704c (usbfn. dll + 0x0001704c) Ra = c09880b0 (usbfn. dll + 0x000180b0) sp = d03ce2d8 and BVA = 00000000

This output gives us some valuable information including the module that failed and the offset into the module that the failure occurred. for this one, the module is usbfn. DLL and the module offset (Mo) is 0x000180b0. skip ahead to number 3 below.

But if you are using Windows CE 4.2 or prior, then you will need to do some work to get the module name and offset. I have found that using the Ra value, in your case 02ea2614, as your exception address (EA) works best.

Look up EA in your makeimg output. it falls between two modules code starts (CS ). the one with the lower number is the module with the problem. in platform builder for Windows CE 4.X, the makeimg output is in the root folder of your project in <Project Name>. PLG.
Then the module offset (Mo) is EA-CS = Mo.
For Windows CE 5.0 and later, mo = Mo-0x1000
Look Mo up in <module. map> in your target folder. similar to looking it up in the makeimg output, it will give you the function that caused the exception, and the function offset (FO ).
Now find the instruction offsett (IO) MO-FO = Io.
Now figure out which C/C ++ file contains the function, look up the function in the corresponding. cod file, and find Io. that is the assembly instruction that caused the exception, look up a few lines an you will see the C code.

If you don't have the. COD files, set the environment variable wincecod = 1
And rebuild.
========================================================== ================================
How to diagnose Windows CE application crash
Refer to blog:
Http://blog.csdn.net/singlerace/archive/2008/07/15/2655154.aspx
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, the corresponding entry of the crash address is:
0001: Pushed 82f4 ?? 1? $ Ccomptr @ uiimage @ ATL @ Qaa @ xz 000192f4 f I imageviewer. the advantage of the objmap file is that it is a text file and can be read manually. The disadvantage is that there is not enough information, and it can only be located at the function level. 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:
Data ABORT: thread = 8d661000 proc = 81a477c0 &apos;installer.exe & apos;
Aky = 00000401 PC 000000019320(installer.exe + 0x00009320) ra000000019094(installer.exe + 0x0
0009094) 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.
This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/singlerace/archive/2008/07/15/2655154.aspx

This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/dragonliabc/archive/2010/04/25/5527638.aspx