Printed Exception strings - what do all

Transcription

1 Printed Exception strings - what do all those flags mean? Data Abort: Thread=9352cc9c Proc=90876ea0 'shell32.exe' AKY= PC=03f74680(coredll.dll+0x ) RA= (aygshell.dll+0x ) BVA=060000e0 FSR= AKY "Access Key" Process slot bitmask corresponding to the processes the excepting thread has access to. For example, the above exception is 0x , which corresponds to: (Hint: the following was copied from Platform Builder window: View Debug Windows Processes) Name VMBase AccessKey TrustLevel hprocess btstereoappui.exe 0x1A x Full 0xB30E2766 connmgr.exe 0x x Full 0x E cprog.exe 0x1C x Full 0xF device.exe 0x0A x Full 0xB3CEC78E filesys.exe 0x x Full 0x13EEE762 gwes.exe 0x0C x Full 0x737A498A nk.exe 0xC x Full 0x13EFF002 pmsnserver.exe 0x x Full 0x5333CD86 poutlook.exe 0x x Full 0xD308FA02 sddaemon.exe 0x x Full 0x7314C62A services.exe 0x0E x Full 0x7352CFAA shell.exe 0x x Full 0xD3CD7A82 shell32.exe 0x x Full 0xD352CEDE srvtrust.exe 0x x Full 0x33105BCA PC "Program Counter" Represents the current line of instruction. On ARM platforms, this is the current value of the PC register and EIP (Instruction Pointer) on x86 platforms. If symbols are available, the exception handler will attempt to provide an offset line into the DLL that caused the exception. In the

2 example above we can find the (fixed up, closest instruction but not over) instruction offset 0x14680 in the coredll.map for the offending instruction. In this case: (Hint: the following was copied and pasted from the coredll.map text file found in the image release directory.) 0001: GetWindowLongW f coredll_all:twinuser.obj 0001: BeginPaint f coredll_all:twinuser.obj 0001:000136cc EndPaint cc f coredll_all:twinuser.obj 0001: GetDC f coredll_all:twinuser.obj 0001:000137d4 ReleaseDC d4 f coredll_all:twinuser.obj 0001: GetParent f coredll_all:twinuser.obj Subtract the function base address above from the remainder reported in the exception handler to find the exact instruction that caused the exception. RA "Return Address" Pointer to the instruction address of the function that called the current function. Had the current function NOT caused an exception, this is where we would return to. The same symbol logic used to resolve function addresses in PC can be used to resolve RA. ARM platforms store this value in LR register and since our example above has a RA= 0x It should have jumped here: (Hint: the following disassembler output was copied and pasted from the Platform Builder disassembly window found either by right-clicking on the current source file or Window Disassembly.) FC add r1, sp, #0x bl BeginPaint (0325aee0) < Exception caused in here ldr lr, [sp, #0x44] < Would have returned here ldr r3, [sp, #0x38] C ldr r2, [sp, #0x3C] ARM, like most platforms manages function Return Addresses on the local stack which allows for nested functions and recursion. Unfortunately this can also lead to problems if the stack somehow gets corrupted not only do you lose the values stored in the stack, but you are at

3 risk of losing your place and the processor won t know where to resume execution. A good indicator this has happened is when your PC == LR.

4 BVA "Base Virtual Address" The contents of BVA depend on the type of exception found. If the exception is a Prefetch Abort, the value points directly to the PC register (execution point). If the exception is a Data Abort, then this value points to why the exception was caused. It is a combination of the Virtual Memory base of the module found plus the value that caused the exception. This is easiest to explain through some examples, starting with our original exception BVA=060000e0 which represents: Processes: (Hint: the following was copied from Platform Builder window: View Debug Windows Processes) Name VMBase AccessKey TrustLevel hprocess shell.exe 0x x Full 0xD3CD7A82 shell32.exe 0x x Full 0xD352CEDE srvtrust.exe 0x x Full 0x33105BCA Registers: (Hint: the following was copied from Platform Builder window: View Debug Windows Registers) R2 = F R3 = R4 = F Disassembly: (Hint: the following disassembler output was copied and pasted from the Platform Builder disassembly window found either by right-clicking on the current source file or Window Disassembly.) 03F7467C ldr r3, [r3] 03F74680 ldr r3, [r3, #0xE0] <<< Exception here, invalid pointer. 03F74684 mov lr, pc 03F74688 bx r3 This line of execution is trying to store the contents of Register 3 into the memory address located at Register 3 + 0xE0 in the context of Shell32.exe (invalid in this case): R3 + 0xE0 + VMBase(shell32.exe) == 0x060000E0

5 An additional BVA example in ossvcs.dll: (Hint: the following was copied from Platform Builder Output window) Data Abort: Thread=92f44574 Proc=90876ea0 'shell32.exe' AKY=ffffffff PC=02e320c8(ossvcs.dll+0x000320c8) RA=02e0f524(ossvcs.dll+0x0000f524) BVA=07ece200 FSR= Registers: (Hint: the following was copied from Platform Builder window: View Debug Windows Registers) R8 = R9 = R10 = 01F31AD0 R11 = 1C05E918 R12 = 01ECE200 Sp = 1C05E500 Lr = 02E0F524 Pc = 02E320C8 Disassembly: (Hint: the following disassembler output was copied and pasted from the Platform Builder disassembly window found either by right-clicking on the current source file or Window Disassembly.) CeGetCurrentTrust: 02E320C4 ldr r12, [pc, #4] 02E320C8 ldr r12, [r12] <<< Exception here, invalid pointer. 02E320CC bx r12 02E320D0??? The line of execution is trying to store Register 12 at the value pointed at in Register 12 in the context of Shell32 (which happens to be invalid). R12 + VMBase(shell32.exe) == 0x07ece200

6 FSR "Fault Status Register" The FSR represents several flags that will help you understand the nature of your exception. For ARM devices the following flags can be set: #define FSR_ALIGNMENT #define FSR_PAGE_ERROR #define FSR_TRANSLATION #define FSR_DOMAIN_ERROR #define FSR_PERMISSION 0x01 0x02 0x05 0x09 0x0D So, taking our example above, we have: FSR= == FSR_PAGE_ERROR FSR_TRANSLATION