学步园

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

 

Published Wednesday, June 29, 2005 4:58 PM by shende