What's the significance of the App Verifier error pattern `fafa`?

Question

My program is crashing in app verifier and I don't fully understand the crash. I have a buffer which is dynamically allocated thus from the number of bytes in a file:

DWORD dwSizeBytes = (DWORD)liSize.QuadPart+2;
TCHAR* JSONBufferW = new TCHAR [dwSizeBytes/sizeof(TCHAR)];
memset(JSONBufferW, 0, dwSizeBytes);

Where dwSizeBytes (I can see this in the crash dump) is 38. After this I read some data from a file:

if(!ReadFile(hFile, JSONBufferW, dwSizeBytes, &dwSizeBytes, NULL))
{
    status = GetLastError();
    TRACE_ERROR(g_hTrace, "ReadFile() failed for %S, error code=%d", strCompletePath, status);
}

This assigns 36 to dwSizeBytes leaving the last two bytes in the buffer NULL so that the buffer is NULL terminated. However under app verifier this later causes a crash when I attempt to construct a std::wstring from the buffer.

When I look at the buffer's allocation block in windbg I see that it looks like this:

0:022> dd 0x00000000`07560fd0-0x48 0x00000000`07560fd0
00000000`07560f88  00001000 00000000 abcdbbbb 00000000
00000000`07560f98  07191000 00000000 00000026 00000000
00000000`07560fa8  00001000 00000000 00000000 00000000
00000000`07560fb8  00000000 00000000 0025a230 00000000
00000000`07560fc8  00001000 dcbabbbb 0022007b

Note the 0x26 which shows my buffer is supposed to be 38 in size. Now I look at the buffer it's self and see:

0:022> dc 0x00000000`07560fd0
00000000`07560fd0  0022007b 006f006d 00650064 003a0022  {.".m.o.d.e.".:.
00000000`07560fe0  006d0022 006e0061 00610075 0022006c  ".m.a.n.u.a.l.".
00000000`07560ff0  000a007d d0d0fafa d0d0d0d0 d0d0d0d0  }...............

This shows that my buffer has been filled by ReadFile but where the NULL should have been left at buf[36] and buf[37] (remember the memset) there is an app verifier fill code fafa (remember the unicode bytes are flipped so d0d0 is actually after fafa.

I've looked here: which has shown me how app verifier leaves these fill codes after allocations. But fafa is not listed, so what does it mean? And why is it in the place where memset should have cleared?

Answer 1

I don't have a source for this at the moment, but one of the features AppVerifier does is completely fills your buffer with a pattern prior to invoking ReadFile. You request to read 38 bytes, AppVerifier fills your buffer with 38 bytes of pattern, and ReadFile only reads 36 bytes from the file. Thus your last 2 bytes are fill pattern rather than the expected NULL characters.