From bruen...@google.com on April 25, 2011 15:29:04

in net_unittests:

WARNING: unknown region 0x08560000-0x08561000 marking as defined
set range 0x08560000-0x08561000 => 0x0
replacing shadow special 0x16190200 block for write @0x08560000 0

Error #1: UNADDRESSABLE ACCESS: reading 0x08560000-0x08560001 1 byte(s) within 0x08560000-0x08560004
@0:00:43.776 in thread 6668
0x77bfa195 <ntdll.dll+0x5a195> ntdll.dll!RtlpValidateActivationContextData
??:0
0x77bfa0ad <ntdll.dll+0x5a0ad> ntdll.dll!RtlCreateActivationContext
??:0
0x7679a593 <KERNEL32.dll+0x1a593> KERNEL32.dll!CreateActCtxW
??:0
0x7679b6ad <KERNEL32.dll+0x1b6ad> KERNEL32.dll!BasepProbeForDllManifest
??:0
0x77bdde87 <ntdll.dll+0x3de87> ntdll.dll!LdrpProcessStaticImports
??:0
0x77bdd6bf <ntdll.dll+0x3d6bf> ntdll.dll!LdrpLoadDll
??:0
0x77bdc4e5 <ntdll.dll+0x3c4e5> ntdll.dll!LdrLoadDll
??:0
0x76621d2a <KERNELBASE.dll+0x11d2a> KERNELBASE.dll!LoadLibraryExW
??:0
0x770e8b55 <WS2_32.dll+0x8b55> WS2_32.dll!DPROVIDER::Initialize
??:0
0x770e8972 <WS2_32.dll+0x8972> WS2_32.dll!DCATALOG::LoadProvider
??:0
0x770e8a07 <WS2_32.dll+0x8a07> WS2_32.dll!DCATALOG::GetCountedCatalogItemFromAddressFamily
??:0
0x770e405a <WS2_32.dll+0x405a> WS2_32.dll!WSAAddressToStringW
??:0
0x77bfa195 81 38 41 63 74 78 cmp (%eax) $0x78746341

allocated by csrss via:
system call #0x300a
kernel32!NtWow64CsrBaseCheckRunApp:
called by kernel32!CsrBasepCreateActCtx
called by kernel32!BasepCreateActCtx+0xd3b
called by CreateActCtxW, before it calls RtlCreateActivationContext

what's mapped is typically one page of file-backed non-image data:
BaseAddress: 00200000
RegionSize: 00001000
State: 00001000 MEM_COMMIT
Protect: 00000002 PAGE_READONLY
Type: 00040000 MEM_MAPPED

0:000> dc 00200000
00200000 78746341 00000020 00000001 000002f0 Actx ...........
00200010 00000064 00000000 00000020 00000000 d....... .......

the syscall finds a PHANDLE at its param + 0x7c:
0:000> dd 204e4b4 L20
0204e4b4 00000041 0000000a 00140014 0204e5e4
0204e4c4 00010101 00520050 0204eaf4 00000000
0204e4d4 ffffffff 00000000 6fa36478 00000000
0204e4e4 00000056 00000000 00000000 00640062
0204e4f4 0204e664 00000000 00000000 00000000
0204e504 00000000 00000000 00000000 00000000
0204e514 003a0038 0204e9f4 00000000 00000000
0204e524 5f44ec47 01cbf602 00000002 0204e904
0:000> dd 0204e904
0204e904 00000000 00000000 00000000 00000000
0204e914 00000000 00000000 00000000 00000000

after syscall:
0:000> dd 0204e904
0204e904 00140000 00000000 00000000 00000000
0204e914 00000000 00000000 00000000 00000000
0:000> !vprot 00140000
BaseAddress: 00140000
AllocationBase: 00140000
AllocationProtect: 00000002 PAGE_READONLY
RegionSize: 00001000
State: 00001000 MEM_COMMIT
Protect: 00000002 PAGE_READONLY
Type: 00040000 MEM_MAPPED
0:000> dc 00140000
00140000 78746341 00000020 00000001 000002f0 Actx ...........
00140010 00000064 00000000 00000020 00000000 d....... .......
00140020 00000014 00000001 00000002 00000034 ............4...

looking at XP disassembly, for syscall it's similar except param +
(3e0-378) = 0x68 instead of 0x7c

so NtWow64CsrBasepCreateActCtx has csrss do the mmap and passes the base
back, and caller passes it as 2nd param to RtlCreateActivationContext
and NULL as the first param

RtlCreateActivationContext is a better place to intercept b/c
NtWow64CsrBasepCreateActCtx is not exported, and the unaddr doesn't happen
until inside RtlCreateActivationContext.

4 more args to RtlCreateActivationContext:
NULL, kernel32!BasepSxsActivationContextNotification, NULL, and what looks
like the real PHANDLE as the final arg?

here's what's returned, though, in that 6th and final arg, which becomes
the return value of CreateActCtxW. the base is in there, and the callback,
but other fields as well:

0:000> dc 023daa14
023daa14 00000001 00000000 baadf00d baadf00d ................
023daa24 00140000 767e1f3a 00000000 00000000 ....:.~v........
023daa34 00000000 00000000 00000000 00000000 ................

0:000> U 767e1f3a
kernel32!BasepSxsActivationContextNotification:

looks like the 2nd arg is IN as base of mmap and OUT as NTSTATUS: 0 on
success, else 0xc00*.

the returned data struct has the base written here:
770ca12e 895e10 mov [esi+0x10],ebx
esi is a new heap alloc of size 0x130 + 3rd param (0 here):
770ca0b8 8b4d10 mov ecx,[ebp+0x10]
770ca0bb 64a118000000 mov eax,fs:[00000018]
770ca0c1 8b4030 mov eax,[eax+0x30]
770ca0c4 81c130010000 add ecx,0x130
770ca0ca 51 push ecx
770ca0cb 56 push esi
770ca0cc ff7018 push dword ptr [eax+0x18]
770ca0cf e8723ffdff call ntdll!RtlAllocateHeap (7709e046)

on XP the base is also written to heap data struct + 0x10 so that's more
reliable than syscall param 0x7c vs 0x68, at least based on 2 datapoints

should probably also change -define_unknown_regions to suppress the initial
unaddr as well, at least for MEM_MAPPED/MEM_IMAGE: what I did for PR 464106
of reporting the initial unaddr seems silly given all the crazy Windows
external allocs, so long as the warnings are watched to ensure not missing
heap or other initially-uninit allocs

Original issue: http://code.google.com/p/drmemory/issues/detail?id=352