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.
What's the significance of the App Verifier error pattern `fafa`?
-
11-03-2022 - |
Domanda
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?
Soluzione