Windows Mobile Application Crash Trouble Shooting Manual
Doc.id.: | RC_WIN_WM_0001 |
Issue date: | 2009-02-09 |
Issued by: | Ryan Chen(Xiaofeng Chen) |
Status: |
|
DOCUMENT INFORMATIONThis document is a summary for windows mobile crash issues handling experience which accumualted from daily work, these technical points explained in this document are applied to windows mobile 5.x 6.x series platform. Hope it helps.
SLOT | The lower address space of WM is split into 32 slots |
VM | Virtual Memory |
RAM | RAM is the physical resource each process consumes to fill memory requests. When the process loads resources and commits memory, RAM is then “consumed” to fill this need. For example, each process starts with a default heap that is created within your virtual memory area. It grows as your application allocates objects and as a result, consumes memory out of the available system RAM and begins to use up your 32MB address space. |
XIP | eXecute in place |
Version | Date | Author | Description |
1 | 2009-02-09 | Ryan Chen | First draft for review |
|
|
|
|
|
|
|
|
1 Introduction...................................................................................................................................................................... 5
2 Background........................................................................................................................................................................ 6
3 Exception handling........................................................................................................................................................ 7
4 Resolve symbols for addresses.......................................................................................................................... 8
4.1 Crash Log.............................................................................................................................................................................. 8
4.2 Map File................................................................................................................................................................................ 9
5 References.......................................................................................................................................................................... 13
1 Introduction
One of the most common problems for windows application is crash, so windows mobile is. Usually the reason is as access violation caused by null or uninitialized or wild pointer. If we have the debug version on hand, and the crash could be easily reproduced then it will not trouble us too much. But if this is reported by a certain released version running on a real productive system, which means it is impossible for programmer to debug then we have to catch the unhandled exceptions for generating crash logs or dump files, and we could use some tools to analyze the crash logs or dump files like windbg. In this article I will not speak of dump files, instead I am trying to explain the way of using map file and crash logs to catch the exact line of codes.
2 Background
First of all, it is quite helpful to introduce a bit the memory management of windows mobile system. We just need to know some basics of VM mechanism. Windows CE 5 (which does the memory management) is the basis for both Windows Mobile 5.x and Windows Mobile 6.x. Windows CE 6 will supposedly be the basis for the future Windows Mobile 7(which is out of scope for this article). For Windows CE 5, only 32 applications can exist, and each can normally only access 32 megabytes of virtual memory. Windows CE 5 keeps all the process’s address spaces available at all times, what it means the lower 1GB (0x4000000) application address space is split into 32 slots.
· Slot 0 is 0x00000000 through 0x01FFFFFF
· Slot 1 is 0x02000000 through 0x03FFFFFF
……
I paste a picture below for a global view.
Figure 1 WindowsCE Virtual Memory Space
Slots 0 & 1 are special slots that aren’t used by processes. The current process is always mapped into slot 0 in addition to having its own unique slot. All DLLs that are stored in ROM (XIP DLLs) are loaded in slot 1.
3 Exception handling
Now we know how Windows Mobile manages memory. This is essential for us to understand well the process addresses. But before we could analyze any practical addresses, we need firstly capture them at the moment of exception happening. This is what exception handling mechanism should do. MS has already provided a structured exception handling mechanism try-except statement for 32-bit target applications.
__try
{
// guarded code
}
__except (expression)
{
// exception handler code
}
And in addition MS also provides some useful APIs for us to take a snapshot of the machine state:
Ø GetExceptionCode -> Retrieves a code that identifies the type of the exception that occurred.
Ø GetExceptionInformation -> This function retrieves a machine-independent description of an exception and information about the machine state that existed for the thread when the exception occurred.
Ø GetThreadCallStack -> This function retrieves the call stack of an arbitrary thread in the system.
Now we get everything for handling an exception, what we should do next is just replace the expression above to be our specific function returns required value. The function could be designed as an exception filter or logger. The following codes demo how the expression works with a logger:
__except( LogStructuredException( GetExceptionInformation() )
// Logger implementation pseudo code
int LogStructuredException( EXCEPTION_POINTERS *pExcept )
{
// open the log file
pFile = OpenLogFile(logpath+filename);
// log the exception info
Dump( pFile, pExcept->ExceptionRecord->ExceptionCode, pExcept->ExceptionRecord->ExceptionAddress, pExcept->ExceptionRecord->ExceptionFlags, pExcept->ExceptionRecord->NumberParameters ); }
// log the call stack info
Dump( GetThreadStack(…))
}
4 Resolve symbols for addresses
Well, if we’ve had the above exception logger in our application already. And if the exception did happen, we definitely could get a crash log sent from support or tester. That is to say we had the addresses information on hand now. However the address is hex value, it is still not easy for us to know what’s wrong with our application. We should use symbol files to map those addresses to source codes.
With Windows Mobile memory basics, crash log and map file, we are finally able to locate exactly the crash code line. I will explain in details with a demo log and map file.
4.1 Crash Log
Here is a demo Crash Log:
Exception c0000005 occured at code_address 00016e00 (flags=00000000, num_params=00000002)
-> except_info[0]=00000000
-> except_info[1]=1e000008
-------------------------------------------
Stacktrace:
-------------------------------------------
dwReturnAddr: 03f69b7c, dwCurProc: bf1cf29a, dwFramePtr: 1e5be2d4, dwParams[0]: 1e5be1ac, dwParams[1]: 00000001, dwParams[2]: 9f270ac0, dwParams[3]: 9ec885ac
dwReturnAddr: 1e0f8e94, dwCurProc: bf1cf29a, dwFramePtr: 1e5be2e8, dwParams[0]: 1e5be1ac, dwParams[1]: 00000001, dwParams[2]: 9f270ac0, dwParams[3]: 9ec885ac
dwReturnAddr: 1e0f96d8, dwCurProc: bf1cf29a, dwFramePtr: 1e5be3ac, dwParams[0]: 1e5be1ac, dwParams[1]: 00000001, dwParams[2]: 9f270ac0, dwParams[3]: 9ec885ac
dwReturnAddr: 1e03a4d4, dwCurProc: bf1cf29a, dwFramePtr: 1e5be438, dwParams[0]: 1e5be1ac, dwParams[1]: 00000001, dwParams[2]: 9f270ac0, dwParams[3]: 9ec885ac
dwReturnAddr: 03f8b924, dwCurProc: bf1cf29a, dwFramePtr: 1e5be440, dwParams[0]: 1e5be1ac, dwParams[1]: 00000001, dwParams[2]: 9f270ac0, dwParams[3]: 9ec885ac
dwReturnAddr: 03f91d60, dwCurProc: bf1cf29a, dwFramePtr: 1e5be464, dwParams[0]: 1e5be1ac, dwParams[1]: 00000001, dwParams[2]: 9f270ac0, dwParams[3]: 9ec885ac
dwReturnAddr: 88037dc4, dwCurProc: bf1cf29a, dwFramePtr: 1e5be48c, dwParams[0]: 1e5be1ac, dwParams[1]: 00000001, dwParams[2]: 9f270ac0, dwParams[3]: 1e5be73c
dwReturnAddr: 88064504, dwCurProc: bf1cf29a, dwFramePtr: 1e5be49c, dwParams[0]: 1e5be1ac, dwParams[1]: 00000001, dwParams[2]: 9f270ac0, dwParams[3]: 1e5be73c
dwReturnAddr: 8803be44, dwCurProc: bf1cf29a, dwFramePtr: 1e5be70c, dwParams[0]: 1e5be1ac, dwParams[1]: 00000001, dwParams[2]: 9f270ac0, dwParams[3]: 1e5be73c
dwReturnAddr: 88037cdc, dwCurProc: bf1cf29a, dwFramePtr: 1e5be7b0, dwParams[0]: 20000010, dwParams[1]: 00000001, dwParams[2]: 9f270ac0, dwParams[3]: 1e5be73c
dwReturnAddr: 1e016e00, dwCurProc: bf1cf29a, dwFramePtr: 1e5be8e4, dwParams[0]: 00000008, dwParams[1]: 00000001, dwParams[2]: 9f270ac0, dwParams[3]: 1e5be73c
dwReturnAddr: 1e016660, dwCurProc: bf1cf29a, dwFramePtr: 1e5be8f4, dwParams[0]: 1e5be918, dwParams[1]: 00000001, dwParams[2]: 9f270ac0, dwParams[3]: 1e5be73c
dwReturnAddr: 1e084ea4, dwCurProc: bf1cf29a, dwFramePtr: 1e5be908, dwParams[0]: 000869d4, dwParams[1]: 00000001, dwParams[2]: 9f270ac0, dwParams[3]: 1e5be73c
dwReturnAddr: 1e0644c8, dwCurProc: bf1cf29a, dwFramePtr: 1e5beac8, dwParams[0]: 0069a1c0, dwParams[1]: 00000110, dwParams[2]: 00000000, dwParams[3]: 00000000
……
The most useful information is exception code address (represents where it crashed) and dwReturnAddr (the return address represents the next line of codes if this exception would not happen).
Ø Exception code address: represents where it crashed;
Ø dwReturnAddr: it is the return address which represents the next line of codes if this exception would not happen;
Ø dwFramePrt: frame pointer, which points to a fixed point in the "user" stack and points to a location in the stack where the arguments and local variables for a called function are located. This pointer is established upon entry to a function and remains constant throughout the execution of the called function.
Ø except_info[0]: for EXCEPTION_ACCESS_VIOLATION only, read/write mode
Ø except_info[1]: for EXCEPTION_ACCESS_VIOLATION only, the memory address that was accessed to cause the problem.
4.2 Map File
Here is part of a corresponding demo Map File:
z7client
Timestamp is 498fe506 (Mon Feb 09 16:10:46 2009)
Preferred load address is 00010000
Start Length Name Class
0001:00000000 00333200H .text CODE
0001:00333200 000058ecH .text$yc CODE
0001:00338aec 000009b0H .text$yd CODE
0002:00000000 00117536H .rdata DATA
0002:00117538 000000abH .rdata$debug DATA
0002:001175e4 000009a0H .xdata DATA
0002:00117f84 00000034H .xdata$x DATA
0002:00117fb8 00000004H ATL$__a DATA
0002:00117fbc 00000004H ATL$__z DATA
0002:00117fc0 000000dcH .idata$2 DATA
0002:0011809c 00000014H .idata$3 DATA
0002:001180b0 000006b0H .idata$4 DATA
0002:00118760 0000043eH .idata$6 DATA
0002:00118b9e 00000000H .edata DATA
0003:00000000 000006b0H .idata$5 DATA
0003:000006b0 00000004H .CRT$XCA DATA
0003:000006b4 00000004H .CRT$XCAA DATA
0003:000006b8 00000008H .CRT$XCL DATA
0003:000006c0 00000040H .CRT$XCU DATA
0003:00000700 00000004H .CRT$XCZ DATA
0003:00000704 00000004H .CRT$XIA DATA
0003:00000708 00000004H .CRT$XIZ DATA
0003:0000070c 00000004H .CRT$XPA DATA
0003:00000710 00000004H .CRT$XPZ DATA
0003:00000714 00000004H .CRT$XTA DATA
0003:00000718 00000004H .CRT$XTZ DATA
0003:00000720 00001aa4H .data DATA
0003:000021c8 000015f5H .bss DATA
0004:00000000 0004c578H .pdata DATA
0005:00000000 00000598H .rsrc$01 DATA
0005:000005a0 00004c80H .rsrc$02 DATA
Address Publics by Value Rva+Base Lib:Object
……
0001:00005d8c