Crash Dump Analysis Patterns (Part 76)

Most of the time Data Alignment manifests itself on Intel platforms from performance perspective and GP faults for some instructions that require natural boundary for their qword operands. There are no exceptions generally if we move a dword value from or to an odd memory location address when the whole operand fits into one page. However we need to take the possibility of page boundary spans into account when checking memory addresses for their validity. Consider this exception:

0: kd> .trap 0xffffffffa38df520
ErrCode = 00000002
eax=b6d9220f ebx=b6ab4ffb ecx=00000304 edx=eaf2fdea esi=b6d9214c edi=b6ab8189
eip=bfa10e6e esp=a38df594 ebp=a38df5ac iopl=0 nv up ei ng nz ac po cy
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000  efl=00010293
driver+0x2ae6e:
bfa10e6e 895304  mov    dword ptr [ebx+4],edx ds:0023:b6ab4fff=????????

The address seems to be valid:

0: kd> !pte b6ab4fff
               VA b6ab4fff
PDE at   C0300B68        PTE at C02DAAD0
contains 7F0DD863      contains 426B0863
pfn 7f0dd —DA–KWEV    pfn 426b0 —DA–KWEV

But careful examination of the instruction reveals that it writes 32 bit value so we need to inspect the next byte too because it is on another page:

0: kd> !pte b6ab4fff+1
               VA b6ab5000
PDE at   C0300B68        PTE at C02DAAD4
contains 7F0DD863      contains 00000080
pfn 7f0dd —DA–KWEV                           not valid
                       DemandZero
                       Protect: 4 - ReadWrite

Although the page is demand zero and this should have been satisfied by creating a new page filled with zeroes, my point here that the page could have been completely invalid or paged out in the case of IRQL >= 2. 

- Dmitry Vostokov @ DumpAnalysis.org -

Leave a Reply