[Bug 16626] New: NBC Direct installer requires installation of Windows Installer 3.1 redist
http://bugs.winehq.org/show_bug.cgi?id=16626 Summary: NBC Direct installer requires installation of Windows Installer 3.1 redist Product: Wine Version: 1.1.11 Platform: PC URL: http://www.nbc.com/Video/NBCDirectInstaller.exe OS/Version: Linux Status: NEW Keywords: dotnet, download, Installer Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: austinenglish(a)gmail.com CC: focht(a)gmx.net, yolande(a)haneder.biz Created an attachment (id=18188) --> (http://bugs.winehq.org/attachment.cgi?id=18188) terminal output in git Continuing from bug 12477, NBC installer doesn't yet work. Prereq's: $ rm -rf ~/.wine $ winetricks -q wmp10 dotnet20 mdac28 $ wine NBCDirectInstaller.exe Fails with an error box: SetupManager Error '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 OK Anastasius suggested to file the bug, saying it probably affects more dotnet apps. Terminal output attached. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16626 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|NBC Direct installer |NBC Direct installer can't |requires installation of |find resources |Windows Installer 3.1 redist| -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16626 --- Comment #1 from Anastasius Focht <focht(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16626 --- Comment #2 from Alexandre Julliard <julliard(a)winehq.org> 2009-01-05 04:12:20 --- Most likely we just need to trigger the page fault manually in ReadFile like we already do in WriteFile. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16626 --- Comment #3 from Alexandre Julliard <julliard(a)winehq.org> 2009-01-05 05:16:12 --- Created an attachment (id=18494) --> (http://bugs.winehq.org/attachment.cgi?id=18494) Trigger page fault in ReadFile Something like this... -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16626 --- Comment #4 from Anastasius Focht <focht(a)gmx.net> 2009-01-05 06:41:18 --- Hello, --- quote --- Something like this... --- quote --- yes it helps to overcome the general problem by in-place updating page protection but there is a problem with this approach. The problem is there might cases where file i/o buffers are partly accessible, e.g. have correct protection on initial pages while the rest is not accessible. If posix read calls manage to partially read file contents into buffer until hitting EFAULT due to incorrect protection the file pointer has already advanced. The second "try" after adjusting page protection will incorrectly update buffer with already advanced file ptr when requested again with full length. Example (buffer partly accessible, file pointer advanced on second try): --- snip --- ... 0033:Call KERNEL32.VirtualAlloc(01852000,0006a000,00001000,00000004) ret=79e74a2b 0033:Ret KERNEL32.VirtualAlloc() retval=01852000 ret=79e74a2b 0033:Call KERNEL32.InterlockedCompareExchange(009372a8,00000008,00000004) ret=79ef5742 0033:Ret KERNEL32.InterlockedCompareExchange() retval=00000004 ret=79ef5742 0033:Call KERNEL32.ReadFile(00000250,018492ba,000720ec,0033f05c,00000000) ret=007fa8bb 0033:trace:ntdll:NtReadFile (0x250,(nil),(nil),(nil),0x33ef28,0x18492ba,0x000720ec,(nil),(nil)),partial stub! 0033:trace:ntdll:NtReadFile = 0xc00000e8 0033:trace:ntdll:NtReadFile (0x250,(nil),(nil),(nil),0x33ef28,0x18492ba,0x000720ec,(nil),(nil)),partial stub! 0033:trace:ntdll:NtReadFile = SUCCESS (467180) 0033:fixme:file:ReadFile Could not access memory (0x18492ba,467180) at first, now OK. Protected by DIBSection code? 0033:Ret KERNEL32.ReadFile() retval=00000001 ret=007fa8bb ... 0033:Call KERNEL32.RaiseException(e0434f4d,00000001,00000001,0033f03c) ret=79f97065 0033:trace:seh:raise_exception code=e0434f4d flags=1 addr=0x7b844f78 0033:trace:seh:raise_exception info[0]=8013150c 0033:trace:seh:raise_exception eax=7b82ccb1 ebx=7b8c3940 ecx=00000000 edx=0033f01c esi=0033f01c edi=0033ef90 0033:trace:seh:raise_exception ebp=0033ef78 esp=0033ef14 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00000246 0033:trace:seh:call_stack_handlers calling handler at 0x79f9a3c8 code=e0434f4d flags=1 0033:CALL MSVCR80._except_handler4_common(7a381240,79e717fb,0033ef24,0033f054,0033ebb4,0033ea50) ret=79f9a3e7 0033:RET MSVCR80._except_handler4_common() retval=00000001 ret=79f9a3e7 0033:trace:seh:call_stack_handlers handler at 0x79f9a3c8 returned 1 0033:trace:seh:call_stack_handlers calling handler at 0x7a3197d4 code=e0434f4d flags=1 ... 0033:Call user32.MessageBoxW(00000000,0094985c 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: Binary stream '98' does not contain a valid BinaryHeader. Possible causes are invalid stream or object version change"...,00935a38 L"SetupManager Error",00000010) ret=03fe14b3 ... --- snip --- The partial success (file ptr advanced) on first try needs to be taken into account when making the second try. I tested a quick fix for myself, taking that information into account and it seems to solve problem ;-) Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16626 --- Comment #5 from Alexandre Julliard <julliard(a)winehq.org> 2009-01-05 06:54:20 --- Well, the right way would be to fix this directly in NtReadFile. Also it needs some test cases to find out the correct behavior on partial reads. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16626 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16626 --- Comment #6 from Anastasius Focht <focht(a)gmx.net> 2009-01-15 15:12:02 --- Hello, fixed by commit 63bff0937f949379193b6d3b87b03edeaaf77d52 There are other issues with the installer, file separate bug reports for them. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16626 Juan Lang <juan_lang(a)yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #7 from Juan Lang <juan_lang(a)yahoo.com> 2009-01-16 10:39:49 --- Confirming the resource error dialog doesn't come up anymore, it just crashes instead. That's bug 16946, I think. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16626 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #8 from Alexandre Julliard <julliard(a)winehq.org> 2009-01-30 11:04:46 --- Closing bugs fixed in 1.1.14. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16626 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |63bff0937f949379193b6d3b87b | |03edeaaf77d52 Component|-unknown |ntdll -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=16626 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- URL|http://www.nbc.com/Video/NB |https://web.archive.org/web |CDirectInstaller.exe |/20080423004530/http://www. | |nbc.com/Video/NBCDirectInst | |aller.exe -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla