Printed Exception strings - what do all those flags mean?
Data Abort: Thread=9352cc9c Proc=90876ea0 'shell32.exe'
AKY=00000005 PC=03f74680(coredll.dll+0x00014680) RA=03257104(aygshell.dll+0x00037104) BVA=060000e0 FSR=00000007
AKY à "Access Key"
Process slot bitmask corresponding to the processes the excepting thread has access to. For example, the above exception is 0x00000005, which corresponds to:
(Hint: the following was copied from Platform Builder window: View à Debug Windows à Processes)
Name VMBase AccessKey TrustLevel hProcess
btstereoappui.exe 0x1A000000 0x00001000 Full 0xB30E2766
connmgr.exe 0x16000000 0x00000400 Full 0x5311091E
cprog.exe 0x1C000000 0x00002000 Full 0xF3030772
device.exe 0x0A000000 0x00000010 Full 0xB3CEC78E
filesys.exe 0x04000000 0x00000002 Full 0x13EEE762
gwes.exe 0x0C000000 0x00000020 Full 0x737A498A
nk.exe 0xC2000000 0x00000001 Full 0x13EFF002
pmsnserver.exe 0x10000000 0x00000080 Full 0x5333CD86
poutlook.exe 0x14000000 0x00000200 Full 0xD308FA02
sddaemon.exe 0x12000000 0x00000100 Full 0x7314C62A
services.exe 0x0E000000 0x00000040 Full 0x7352CFAA
shell.exe 0x08000000 0x00000008 Full 0xD3CD7A82
shell32.exe 0x06000000 0x00000004 Full 0xD352CEDE
srvtrust.exe 0x18000000 0x00000800 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 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:00013638 GetWindowLongW 10014638 f coredll_ALL:twinuser.obj
0001:00013648 BeginPaint 10014648 f coredll_ALL:twinuser.obj
0001:000136cc EndPaint 100146cc f coredll_ALL:twinuser.obj
0001:00013750 GetDC 10014750 f coredll_ALL:twinuser.obj
0001:000137d4 ReleaseDC 100147d4 f coredll_ALL:twinuser.obj
0001:00013858 GetParent 10014858 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= 0x03257104 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.)
…
032570FC add r1, sp, #0x30
03257100 bl |BeginPaint (0325aee0)| < Exception caused in here
03257104 ldr lr, [sp, #0x44] < Would have returned here
03257108 ldr r3, [sp, #0x38]
0325710C 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 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.
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 0x08000000 0x00000008 Full 0xD3CD7A82
shell32.exe 0x06000000 0x00000004 Full 0xD352CEDE
srvtrust.exe 0x18000000 0x00000800 Full 0x33105BCA
…
Registers: (Hint: the following was copied from Platform Builder window: View à Debug Windows à Registers)
…
R2 = 0000000F
R3 = 00000000
R4 = 0000000F
…
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
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=00000007
Registers: (Hint: the following was copied from Platform Builder window: View à Debug Windows à Registers)
…
R8 = 00000000 R9 = 00000000
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
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 0x01 |
|
|
#define FSR_PAGE_ERROR 0x02 |
|
|
#define FSR_TRANSLATION 0x05 |
|
|
#define FSR_DOMAIN_ERROR 0x09 |
|
|
#define FSR_PERMISSION 0x0D |
|
So, taking our example above, we have:
FSR=00000007 == FSR_PAGE_ERROR | FSR_TRANSLATION