http://bugs.winehq.org/show_bug.cgi?id=16626
--- Comment #1 from Anastasius Focht focht@gmx.net 2009-01-03 11:46:44 --- Hello,
--- quote --- Anastasius suggested to file the bug, saying it probably affects more dotnet apps. --- quote ---
yes it affects lots of .NET apps since AJ introduced virtual write watch implementation.
Relevant trace parts ...
--- snip --- .. 006e:Call KERNEL32.CreateFileW(008f7130 L"C:\All Users\Application Data\TEMP\SetupManagerExtRes.resources",80000000,00000001,00000000,00000003,00100000,00000000) ret=007ba657 006e:Ret KERNEL32.CreateFileW() retval=00000a4c ret=007ba657 ... 006e:Call KERNEL32.ReadFile(00000a4c,018092ba,000720ec,0033f05c,00000000) ret=007ba8bb 006e:Ret KERNEL32.ReadFile() retval=00000000 ret=007ba8bb 006e:Call KERNEL32.GetLastError() ret=007ba8c1 006e:Ret KERNEL32.GetLastError() retval=000003e6 ret=007ba8c1 ... 006e:Call KERNEL32.RaiseException(e0434f4d,00000001,00000001,0033ef38) ret=79f97065 006e:trace:seh:raise_exception code=e0434f4d flags=1 addr=0x7b844f78 006e:trace:seh:raise_exception info[0]=800703e6 006e:trace:seh:raise_exception eax=7b82ccb1 ebx=7b8c3940 ecx=00000000 edx=0033ef18 esi=0033ef18 edi=0033ee90 006e:trace:seh:raise_exception ebp=0033ee78 esp=0033ee14 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00000246 006e:trace:seh:call_stack_handlers calling handler at 0x79f9a3c8 code=e0434f4d flags=1 006e:trace:seh:call_stack_handlers handler at 0x79f9a3c8 returned 1 006e:trace:seh:call_stack_handlers calling handler at 0x7a3197d4 code=e0434f4d flags=1 ... 006e:Call user32.MessageBoxW(00000000,008fc7ac L"Failed to update Select Dialog resources from an external resource file. Please verify that the SetupManagerResource.resx files resides beside executable and is valid. Error details: No access to memory location\n",008f5a38 L"SetupManager Error",00000010) ret=04f71577 ... --- snip ---
The buffer supplied to ReadFile() is not (completely) accessible. Last commit immediately before the ReadFile() call just to illustrate the state of Wine's virtual views (1):
--- snip --- ... 006e:Call KERNEL32.VirtualAlloc(01812000,0006a000,00001000,00000004) ret=79e74a2b 006e:trace:virtual:NtAllocateVirtualMemory 0xffffffff 0x1812000 0006a000 1000 00000004 006e:trace:virtual:VIRTUAL_SetProt 0x1812000-0x187bfff c-rw- 006e:trace:virtual:VIRTUAL_DumpView View: 0x800000 - 0x27fffff (valloc) 006e:trace:virtual:VIRTUAL_DumpView 0x800000 - 0x8fbfff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x8fc000 - 0x901fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x902000 - 0x17fffff --rw- 006e:trace:virtual:VIRTUAL_DumpView 0x1800000 - 0x1808fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x1809000 - 0x187bfff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x187c000 - 0x27fffff --rw- 006e:Ret KERNEL32.VirtualAlloc() retval=01812000 ret=79e74a2b 006e:trace:virtual:VIRTUAL_SetProt 0x187b000-0x187bfff c-rw- 006e:trace:virtual:VIRTUAL_DumpView View: 0x800000 - 0x27fffff (valloc) 006e:trace:virtual:VIRTUAL_DumpView 0x800000 - 0x8fbfff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x8fc000 - 0x901fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x902000 - 0x17fffff --rw- 006e:trace:virtual:VIRTUAL_DumpView 0x1800000 - 0x1808fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x1809000 - 0x187afff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x187b000 - 0x187bfff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x187c000 - 0x27fffff --rw- 006e:trace:virtual:VIRTUAL_SetProt 0x1809000-0x1809fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView View: 0x800000 - 0x27fffff (valloc) 006e:trace:virtual:VIRTUAL_DumpView 0x800000 - 0x8fbfff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x8fc000 - 0x901fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x902000 - 0x17fffff --rw- 006e:trace:virtual:VIRTUAL_DumpView 0x1800000 - 0x1809fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x180a000 - 0x187afff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x187b000 - 0x187bfff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x187c000 - 0x27fffff --rw- ... --- snip ---
Range covered, access is "c-rw".
Now down to the metal...
From the initialization phase of .NET runtime:
--- snip --- ... 006e:Call KERNEL32.VirtualAlloc(00000000,02000000,00202000,00000004) ret=79e74a2b 006e:trace:virtual:NtAllocateVirtualMemory 0xffffffff (nil) 02000000 202000 00000004 006e:trace:virtual:map_view got mem in reserved area 0x800000-0x2800000 006e:trace:virtual:VIRTUAL_DumpView View: 0x800000 - 0x27fffff (valloc) 006e:trace:virtual:VIRTUAL_DumpView 0x800000 - 0x27fffff --rw- 006e:Ret KERNEL32.VirtualAlloc() retval=00800000 ret=79e74a2b 006e:Call KERNEL32.VirtualAlloc(00000000,000a0000,00203000,00000004) ret=79e74a2b ... --- snip ---
At startup, the .NET runtime reserves a large chunk of uncommitted memory, with write watch set (MEM_RESERVE|MEM_WRITE_WATCH), protection attribute PAGE_READWRITE.
This is the heap the .NET runtime will work on. After initialization phase, subsequent chunks from this reserved .NET heap get committed to be used from managed code:
(alloc type MEM_COMMIT and protection PAGE_READWRITE)
--- snip --- ... 006e:Call KERNEL32.VirtualAlloc(01800000,00002000,00001000,00000004) ret=79e74a2b 006e:trace:virtual:NtAllocateVirtualMemory 0xffffffff 0x1800000 00002000 1000 00000004 006e:trace:virtual:VIRTUAL_SetProt 0x1800000-0x1801fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView View: 0x800000 - 0x27fffff (valloc) 006e:trace:virtual:VIRTUAL_DumpView 0x800000 - 0x800fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x801000 - 0x801fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x802000 - 0x17fffff --rw- 006e:trace:virtual:VIRTUAL_DumpView 0x1800000 - 0x1801fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x1802000 - 0x27fffff --rw- 006e:Ret KERNEL32.VirtualAlloc() retval=01800000 ret=79e74a2b 006e:trace:virtual:VIRTUAL_SetProt 0x1800000-0x1800fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView View: 0x800000 - 0x27fffff (valloc) 006e:trace:virtual:VIRTUAL_DumpView 0x800000 - 0x800fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x801000 - 0x801fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x802000 - 0x17fffff --rw- 006e:trace:virtual:VIRTUAL_DumpView 0x1800000 - 0x1800fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x1801000 - 0x1801fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x1802000 - 0x27fffff --rw- 006e:trace:virtual:VIRTUAL_SetProt 0x801000-0x801fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView View: 0x800000 - 0x27fffff (valloc) 006e:trace:virtual:VIRTUAL_DumpView 0x800000 - 0x801fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x802000 - 0x17fffff --rw- 006e:trace:virtual:VIRTUAL_DumpView 0x1800000 - 0x1800fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x1801000 - 0x1801fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x1802000 - 0x27fffff --rw- 006e:trace:virtual:VIRTUAL_SetProt 0x1801000-0x1801fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView View: 0x800000 - 0x27fffff (valloc) 006e:trace:virtual:VIRTUAL_DumpView 0x800000 - 0x801fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x802000 - 0x17fffff --rw- 006e:trace:virtual:VIRTUAL_DumpView 0x1800000 - 0x1801fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x1802000 - 0x27fffff --rw- ... 006e:Call KERNEL32.VirtualAlloc(01802000,00010000,00001000,00000004) ret=79e74a2b 006e:trace:virtual:NtAllocateVirtualMemory 0xffffffff 0x1802000 00010000 1000 00000004 006e:trace:virtual:VIRTUAL_SetProt 0x1802000-0x1811fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView View: 0x800000 - 0x27fffff (valloc) 006e:trace:virtual:VIRTUAL_DumpView 0x800000 - 0x801fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x802000 - 0x17fffff --rw- 006e:trace:virtual:VIRTUAL_DumpView 0x1800000 - 0x1801fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x1802000 - 0x1811fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x1812000 - 0x27fffff --rw- 006e:Ret KERNEL32.VirtualAlloc() retval=01802000 ret=79e74a2b 006e:trace:virtual:VIRTUAL_SetProt 0x2850000-0x2850fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView View: 0x2800000 - 0x289ffff (valloc) 006e:trace:virtual:VIRTUAL_DumpView 0x2800000 - 0x2800fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x2801000 - 0x284ffff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x2850000 - 0x2850fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x2851000 - 0x289ffff c-rw- 006e:trace:virtual:VIRTUAL_SetProt 0x1802000-0x1802fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView View: 0x800000 - 0x27fffff (valloc) 006e:trace:virtual:VIRTUAL_DumpView 0x800000 - 0x801fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x802000 - 0x17fffff --rw- 006e:trace:virtual:VIRTUAL_DumpView 0x1800000 - 0x1802fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x1803000 - 0x1811fff c-rw- 006e:trace:virtual:VIRTUAL_DumpView 0x1812000 - 0x27fffff --rw- ... 01812000,0006a000 chunk covered by (1) trace ... --- snip ---
Grmbl ... never trust Wine's virtual views alone - lets get heavier weapons ;-)
Dumping Linux kernel /proc/<pid>/maps relevant data...
After the first large chunk reserve VirtualAlloc(00000000,02000000,00202000,00000004):
--- snip --- ... 007bb000-02800000 ---p 007bb000 00:00 0 ... --- snip ---
Number of chunk commits following ... Immediately before the last commit, with Wine's virtual views and proc maps already inconsistent:
--- snip --- ... 00800000-008fe000 rw-p 00800000 00:00 0 008fe000-00902000 r--p 008fe000 00:00 0 00902000-01800000 ---p 00902000 00:00 0 01800000-01809000 rw-p 01800000 00:00 0 01809000-01812000 r--p 01809000 00:00 0 01812000-02800000 ---p 01812000 00:00 0 ... --- snip ---
After last commit, see (1), before failing ReadFile():
--- snip --- ... 00800000-008fe000 rw-p 00800000 00:00 0 008fe000-00902000 r--p 008fe000 00:00 0 00902000-01800000 ---p 00902000 00:00 0 01800000-01809000 rw-p 01800000 00:00 0 01809000-0187c000 r--p 01809000 00:00 0 0187c000-02800000 ---p 0187c000 00:00 0 ... --- snip ---
The problem is most likely dlls/ntdll/virtual.c:VIRTUAL_SetProt() which adjusts page protection for individual pages when write watch is present. For quick proof, comment out the code block in which handles VPROT_WRITEWATCH for individual pages, falling back to original behaviour. That should get .NET apps running again which suffer from resource loader failures.
There are several other bugs with the installer, don't bother with them here.
Regards