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.
Definitions
Abbreviations
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
|
Document History
Version
|
Date
|
Author
|
Description
|
1
|
2009-02-09
|
Ryan Chen
|
First draft for review
|
|
|
|
|
|
|
|
|
Contents List
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
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(…))
}
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.
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.
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
分享到:
相关推荐
本文全面深入的阐述了windows mobile平台上程序异常处理的几个关键问题:1. windows mobile平台的内存管理机制2. 如何使自己的应用程序具备结构化的异常处理能力3. 如何在客户现场发生异常且不可复现的情况下,迅速...
介绍WindowsMobile应用程序开发的流程。
Windows Mobile应用程序开发 培训基础
Windows Mobile应用程序开发介绍 .Windows Mobile平台 .Windows Mobile开发环境搭建 .Windows Mobile开发技术和资源 .Demo
MSDN Webcast Windows Mobile GPS应用开发指南 Video
Windows Mobile开发实验,wince操作系统定制。
MSDN Webcast 创建能在各式设备上运行的Windows Mobile应用程序 Video
Windows Mobile应用程序界面设计指导
Windows mobile应用开发流程
WindowsMobile应用程序开发.ppt 很好的培训材料
开发省电的windows mobile 应用程序 webcast,微软高级讲师讲解
MSDN Webcast 创建能在各式设备上运行的Windows Mobile应用程序 Code
设计友好的WindowsMobile应用程序
windows mobile 应用程序开发实践 提供了书中的部分代码
使用加密技术提高Windows Mobile应用程序的安全性.rar使用加密技术提高Windows Mobile应用程序的安全性.rar
主要议程: 屏幕的方位性 分辨率 界面布局 软键和菜单 输入
本文结合作者自学过程,从一个完全没接触过移动平台开发的新手的角度讲解基于Windows Mobile 5.0平台的GPS应用程序的开发过程.体验使用Visual C#开发移动应用程序的高效率.
MSDN Webcast Windows Mobile GPS应用开发指南 PPT
《windows mobile程序应用开发》的源码