[Bug 10134] New: regtlib.exe from .NET 1.1's dotnetfx. exe installer crashes with heap problem
http://bugs.winehq.org/show_bug.cgi?id=10134 Summary: regtlib.exe from .NET 1.1's dotnetfx.exe installer crashes with heap problem Product: Wine Version: CVS/GIT Platform: Other URL: http://www.microsoft.com/downloads/details.aspx?displayl ang=en&FamilyID=262D25E3-F589-4842-8157-034D1E7CF3A3 OS/Version: other Status: NEW Keywords: download, Installer Severity: normal Priority: P2 Component: wine-ole AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com This one was mentioned at the end of bug 5358, but I only just now got around to isolating it. I ran into this in the context of bug 5358 (Microsoft Dynamics GP Trial). That app comes with dotnetfx.exe, which fails to install. The problem is a heap corruption or something in our COM implementation, as it fails slightly faster and cleaner with WINEDEBUG=warn+heap, and succeeds with native dcom98. The problem can be reproduced with the .net 1.1 installer downloadable from Microsoft. This has the same md5 signature as the one on the cdrom. Oddly, when I first hit this it took ten seconds, the second time it took half an hour, no idea why the speed difference. I think it might be WINEDEBUG=warn+heap makes it run slow, that's another sign of an uninitialized variable. Here's the script I used to demonstrate the bug. I'll attach fail.log. set -x wineserver -k rm -rf .wine export WINE=$HOME/wine-git/wine export WINEPREFIXCREATE=$HOME/wine-git/tools/wineprefixcreate sh ~/bin/winetricks fakeie6 # install .net 1.1 test -f dotnetfx.exe || wget http://download.microsoft.com/download/a/a/c/aac39226-8825-44ce-90e3-bf8203e... # fwiw, md5sum dotnetfx.exe is 52456ac39bbb4640930d155c15160556 # WINEDEBUG=warn+heap,+process $WINE dotnetfx.exe # Here's how it fails: #trace:process:CreateProcessW app L"c:\\windows\\system32\\URTTEMP\\regtlib.exe" cmdline L"\"c:\\windows\\system32\\URTTEMP\\regtlib.exe\" \"c:\\windows\\Microsoft.NET\\Framework\\v1.1.4322\\mscorlib.tlb\"" #warn:heap:HEAP_ValidateInUseArena Heap 0x110000: invalid in-use arena magic for 0x11a1a8 #wine: Unhandled page fault on read access to 0xaaaaaaba at address 0x7ec89683 (thread 0023), starting debugger... # OK, so run just the failing command: WINEDEBUG=warn+heap,+ole $WINE c:\\windows\\system32\\URTTEMP\\regtlib.exe c:\\windows\\Microsoft.NET\\Framework\\v1.1.4322\\mscorlib.tlb > fail.log 2>&1 # Yep, that fails very nicely -- but passes with native dcom98! sh ~/bin/winetricks dcom98 WINEDEBUG=warn+heap,+process $WINE c:\\windows\\system32\\URTTEMP\\regtlib.exe c:\\windows\\Microsoft.NET\\Framework\\v1.1.4322\\mscorlib.tlb > ok.log 2>&1 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10134 --- Comment #1 from Dan Kegel <dank(a)kegel.com> 2007-10-22 07:28:38 --- gaah, the microsoft dynamics gp trial bug is bug 8178. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10134 --- Comment #2 from Dan Kegel <dank(a)kegel.com> 2007-10-22 07:34:36 --- Created an attachment (id=8710) --> (http://bugs.winehq.org/attachment.cgi?id=8710) warn+heap,+ole of regtlib.exe c:\\w indows\\Microsoft.NET\\Framework\\v1.1.4322\\mscorlib.tlb -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10134 --- Comment #3 from Dan Kegel <dank(a)kegel.com> 2007-10-22 07:35:29 --- The slowdown might also have been because of a runaway Installer.exe from a previous run. Watch out for that. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10134 James McKenzie <jjmckenzie51(a)sprintpcs.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jjmckenzie51(a)sprintpcs.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10134 --- Comment #4 from James McKenzie <jjmckenzie51(a)sprintpcs.com> 2007-11-22 09:47:00 --- Dan: When I attempt to run this on a Mac PowerBookPro with MacOSX 10.4.10 installed I get a very interesting dump. Attached is the WINEDEBUG=warn+heap,+process $WINE dotnetfx.exe log file. James -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10134 --- Comment #5 from James McKenzie <jjmckenzie51(a)sprintpcs.com> 2007-11-22 09:50:21 --- Created an attachment (id=9286) --> (http://bugs.winehq.org/attachment.cgi?id=9286) warn+heap,+process dotnetfx.exe log file with crashdump on regtlib.exe execution -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10134 --- Comment #6 from James McKenzie <jjmckenzie51(a)sprintpcs.com> 2007-11-22 10:36:08 --- Dan: I duplicated what you did and yes, dcom98 does work. Now to see if .NET 1.1 fully installed. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10134 --- Comment #7 from James McKenzie <jjmckenzie51(a)sprintpcs.com> 2007-11-22 21:10:07 --- *** Bug 10126 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10134 Dan Kegel <dank(a)kegel.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |1.0.0 --- Comment #8 from Dan Kegel <dank(a)kegel.com> 2007-11-22 23:32:30 --- Seems important enough for 1.0. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10134 --- Comment #9 from Rob Shearman <rob(a)codeweavers.com> 2007-11-27 13:17:41 --- Created an attachment (id=9372) --> (http://bugs.winehq.org/attachment.cgi?id=9372) Fix multiple frees of the same piece of data Should fix the crash Dan reported. Also sent to wine-patches. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10134 --- Comment #10 from James McKenzie <jjmckenzie51(a)sprintpcs.com> 2007-12-04 07:57:23 --- Bug fixed in 0.9.50, but regsvcs.exe crashes instead now on a clean .wine. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10134 --- Comment #11 from James McKenzie <jjmckenzie51(a)sprintpcs.com> 2007-12-04 07:59:34 --- Created an attachment (id=9485) --> (http://bugs.winehq.org/attachment.cgi?id=9485) zipped log of running regsvcs.exe /bootstrapi WINEDEBUG=+file,+relay wine 'C:\Windows\Microsoft.NET\Framework\v1.1.4322\RegSvcs.exe' /bootstrapi zipped log file -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10134 --- Comment #12 from James McKenzie <jjmckenzie51(a)sprintpcs.com> 2007-12-15 10:41:42 --- With 0.9.51 I managed to get to the Install completed message. I had to stop the install at c:\windows\Microsoft.NET\Framework\v1.1.4322\RegSvcs.exe /bootstrapi and run this command separately, which successfully completed. Started installation a second time and it stopped again at this point, killed process and it went through to: c:\windows\Microsoft.NET\Framework\v1.1.4322\migpolwin.exe -migrate 1.1.4322 1.0.375 Killed off install and ran this separately and it finished successfully. Running the install a third time resulted in a 'Install finished sucessfully' after killing off both the regsvcs and migpolwin processes. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10134 --- Comment #13 from Dan Kegel <dank(a)kegel.com> 2008-01-09 17:42:12 --- regsvcs crashes for me even if I run it standalone :-( -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10134 --- Comment #14 from James McKenzie <jjmckenzie51(a)sprintpcs.com> 2008-01-09 18:18:47 --- I will recheck if this still works with 0.9.52, it was working with 0.9.50. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10134 --- Comment #15 from James McKenzie <jjmckenzie51(a)sprintpcs.com> 2008-01-09 18:49:14 --- Confirmed. Regsvcs.exe does not run now :-( -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10134 --- Comment #16 from James McKenzie <jjmckenzie51(a)sprintpcs.com> 2008-01-09 18:51:26 --- Created an attachment (id=10145) --> (http://bugs.winehq.org/attachment.cgi?id=10145) Error log for DotNet 1.1 installation. Log file from .Net 1.1 installation with builtin rcprt4.dll -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10134 Ralph Prichard <rprichard(a)freedomforum.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rprichard(a)freedomforum.org -- 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=10134 --- Comment #17 from Anastasius Focht <focht(a)gmx.net> 2008-01-19 16:13:24 --- Created an attachment (id=10372) --> (http://bugs.winehq.org/attachment.cgi?id=10372) patch which fixes .net 1.1 ActivationContextBasicInformation query crash Hello, well the crash seems to be related to undocumented behavior when querying for activation context basic info class. --- snip --- ... 0022:trace:actctx:RtlFindActivationContextSectionString 00000001 (null) 2 L"rsaenh.dll" 0x34f0d0 0022:trace:actctx:RtlFindActivationContextSectionString 00000001 (null) 2 L"crypt32.dll" 0x34e740 0022:trace:actctx:RtlQueryInformationActivationContext 00000000 (nil) (nil) 2 0x34f90c 48 0x34f948 0022:trace:actctx:RtlQueryInformationActivationContext 00000000 (nil) (nil) 2 0x34f928 48 0x34f95c 0022:trace:actctx:RtlQueryInformationActivationContext 00000000 (nil) (nil) 1 0x34f9b0 8 0x34f9c0 0022:trace:seh:raise_exception code=c0000005 flags=0 addr=0x7bc24531 0022:trace:seh:raise_exception info[0]=00000000 0022:trace:seh:raise_exception info[1]=c07e3e11 0022:trace:seh:raise_exception eax=c07e3e10 ebx=00000000 ecx=00000000 edx=c07e3e11 esi=006d3a20 edi=7bc30c80 0022:trace:seh:raise_exception ebp=0034f928 esp=0034f928 cs=0073 ds=007b es=007b fs=0033 gs=003b flags=00210293 ... Backtrace: =>1 0x7bc24531 check_actctx+0x11(h=0xc07e3e11) [/usr/local/src/wine-git/dlls/ntdll/actctx.c:574] in ntdll (0x0034f928) 2 0x7bc2495b RtlAddRefActivationContext+0xb(handle=0xc07e3e11) [/usr/local/src/wine-git/dlls/ntdll/actctx.c:2292] in ntdll (0x0034f930) 3 0x7b830c01 AddRefActCtx+0x11(hActCtx=0xc07e3e11) [/usr/local/src/wine-git/dlls/kernel32/actctx.c:187] in kernel32 (0x0034f940) 4 0x790598c5 in fusion (+0x198c5) (0x0034f988) 5 0x792487fb in mscorwks (+0x987fb) (0x0034f9c4) 6 0x7923d769 in mscorwks (+0x8d769) (0x0034fca8) 7 0x791c6e73 in mscorwks (+0x16e73) (0x0034fee8) 8 0x791c6ef3 in mscorwks (+0x16ef3) (0x0034ff08) ... --- snip ---
From what I've seen while debugging the crash wine actually returns the default process activation context when it shouldn't (dlls/ntdll/actctx.c:RtlQueryInformationActivationContext() -> find_query_actctx()).
.NET crashes while doing some operations on the returned context. The culprit seems to be calls like this: QueryActCtxW -> RtlQueryInformationActivationContext( dwFlags = 0, hActCtx = NULL, pvSubInstance = NULL, ulInfoClass = ActivationContextBasicInformation, buf, sizeof(buf), &required_size); Unfortunately MSDN doesn't tell anything about this case, ActivationContextBasicInformation class isn't documented at all. I wrote some tests which call this function with ActivationContextBasicInformation class and permutated args. The function succeeds in Windows XP Sp2 (returns TRUE) and initializes the ACTIVATION_CONTEXT_BASIC_INFORMATION structure members to zero (preinit magic numbers for each struct member to detect any explicit init by internal API) and sets required size to sizeof(ACTIVATION_CONTEXT_BASIC_INFORMATION) == 8. Attached patch fixes the problem by not returning default activation context for ActivationContextBasicInformation info class when none of dwFlags bits are set or input handle is NULL. Although the patch fixes the crash, the calls with ActivationContextBasicInformation class need some test cases to qualify for GIT ... I leave this as exercise to someone else - as usual ;-) 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=10134 --- Comment #18 from Anastasius Focht <focht(a)gmx.net> 2008-01-30 15:21:08 --- Created an attachment (id=10535) --> (http://bugs.winehq.org/attachment.cgi?id=10535) patch which fixes another .net 1.1 crash by adding CoGetContextToken stub Hello again, well I tracked down the remaining major .NET 1.1 installation crashes, preventing the installer from finishing successfully. Enjoy. After applying previous activation context patch (http://bugs.winehq.org/attachment.cgi?id=10372) there is another crash happening when the regsvcs.exe tool is spawned from installer. You can provoke the crash by manually running the tool after killing the installer. --- snip --- .. Microsoft (R) .NET Framework Services Installation Utility Version 1.1.4322.573 Copyright (C) Microsoft Corporation 1998-2002. All rights reserved. fixme:shell:URL_ParseUrl failed to parse L"x" The following installation error occurred: 1: Assembly not found: 'x'. wine: Unhandled privileged instruction at address 0x75ece7c5 (thread 0014), starting debugger... Unhandled exception: privileged instruction in 32-bit code (0x75ece7c5). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:75ece7c5 ESP:0034f998 EBP:0034f9d0 EFLAGS:00210216( - 00 -RIAP1) EAX:75ece72e EBX:00000000 ECX:0013e8d0 EDX:0034f9cc ESI:80004005 EDI:00009c40 Stack dump: 0x0034f998: 00009c40 80004005 0034f9d0 0034f9b8 0x0034f9a8: 00000000 0034f9cc 0013e8d0 75ece72e 0x0034f9b8: 791dc5f7 75ece7b8 791f0fc4 0034f9cc 0x0034f9c8: 001322d0 001322d0 0034fe1c 791dc685 0x0034f9d8: 0034f9e8 00009c40 001322d0 001322d0 0x0034f9e8: 00000001 001322d0 00000002 791b3ce4 Backtrace: =>1 0x75ece7c5 dll_cs_debug+0x5() in ole32 (0x0034f9d0) 2 0x791dc685 in mscorwks (+0x2c685) (0x0034fe1c) 3 0x791f9208 in mscorwks (+0x49208) (0x0034fe2c) 4 0x7921d1fb in mscorwks (+0x6d1fb) (0x0034feb8) 5 0x7921d2b6 in mscorwks (+0x6d2b6) (0x0034fee8) 6 0x791c6f1a in mscorwks (+0x16f1a) (0x0034ff08) 7 0x7b87195e start_process+0xee(arg=0x0) [/usr/local/src/wine-git/dlls/kernel32/process.c:883] in kernel32 (0x0034ffe8) 8 0x60024567 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000) 0x75ece7c5 dll_cs_debug+0x5 in ole32: outl %eax,$0xec --- snip --- This was a bit nasty to track down due to usage of undocumented windows structures. The crash happens because .NET code peeks into undocumented (?) areas of OLE Apartment structure and happily uses the data found there in ways not intended. I condensed the relevant app code and added some comments --- snip app code #1 --- .. mov eax, large fs:18h ; get the TEB address mov eax, [eax+0F80h] ; offset of COM TLS structure -> OLE apartment test eax, eax jz short _ole_not_initialized cmp dword ptr [eax+38h], 0 ; pApartment->some_member == NULL ? jz short _some_member_null mov eax, large fs:18h mov eax, [eax+0F80h] mov eax, [eax+38h] .. --- snip app code #1 --- My guess is wine's OLE apartment structure layout defined in "dlls/ole32/compobj_privare.h" most likely does not match windows layout. Due to that mismatch, pApartment+0x38h is referenced as "valid" data (ptr) and used in an interface call manner, leading to crash: --- snip app code #2 --- .. mov ecx, [eax] ; eax = pApartment->some_member (from previous snippet #1) lea edx, [ebp-4] ; var push edx push offset _some_data push eax call dword ptr [ecx] ; looks like iface/vtable->member( ...) --- snip app code #2 --- *boom* at first instructions pointed by ecx ... obviously. One way to fix this nasty code would be to adjust wine's "apartment" struct in a way that it contains NULL at that specific offset, preventing further usage. Fortunately I found another much cleaner way to get out of this brain damage without guessing/mimicking windows data structure offsets. It seems .NET devs used a second method for retrieving the data, which works in newer windows versions (according to MSDN from win2K up). This second method was not obvious because only a simple flag was checked at the time the shutdown code ran. This flag had the special meaning that a specific API was available: CoGetContextToken() - exported by ole32. This "newer api available" flag was initialized at app startup when it checked for the export. If that export exists (flag), this function is called instead of above code (app code #1). CoGetContextToken is documented here: http://msdn2.microsoft.com/en-us/library/ms679665(VS.85).aspx I added a simple stub to ole32 (returning E_NOTIMPL) and it worked. No crash ;-) With the attached "CoGetContextToken" stub patch applied the installation proceeds and finishes Near the end of installation there is another (rather harmless) crash in installer when registering ASP.NET (IIS) helper components. --- snip --- wine: Unhandled exception 0xc06d007e at address 0x7b8414e0 (thread 003f), starting debugger... Unhandled exception: 0xc06d007e in 32-bit code (0x7b841558). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:7b841558 ESP:0034f888 EBP:0034f8ec EFLAGS:00200212( - 00 - -IA1) EAX:7b82c201 EBX:7b8ae084 ECX:00000000 EDX:79e90e60 ESI:79e90e60 EDI:00000000 Stack dump: 0x0034f888: 0034f960 00000004 0034f8a8 7ffd8c00 0x0034f898: c06d007e 00000000 00000000 7b8414e0 0x0034f8a8: 00000001 0034f910 79e90e60 00000000 0x0034f8b8: 0034f8d8 7b863163 7ffd8c00 00000000 0x0034f8c8: 00000000 00000000 7b863129 7b8ae084 0x0034f8d8: 0034f8f8 7b86319d 79e61310 00000000 Backtrace: =>1 0x7b841558 RaiseException+0x78(code=0xc06d007e, flags=0x0, nbargs=0x79e90e60, args=0x34f960) [/usr/local/src/wine-git/dlls/kernel32/except.c:85] in kernel32 (0x0034f8ec) 2 0x79e9082c in aspnet_isapi (+0x3082c) (0x0034f954) 3 0x79e8fd99 in aspnet_isapi (+0x2fd99) (0x0034fa04) 4 0x00000000 (0x00000000) --- snip --- You can fix this by placing native "loadperf.dll" from windows install into your wine system32 directory. Though not perfect (some issues left) the installer now finishes successfully. 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=10134 Alan Jackson <ajackson(a)bcs.org.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ajackson(a)bcs.org.uk -- 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=10134 Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |xerox_xerox2000(a)yahoo.co.uk --- Comment #19 from Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> 2008-02-03 07:04:58 ---
Though not perfect (some issues left) the installer now finishes successfully.
Yip , that's true, but while trying to run a simple .net app (i used fastmd5 again) it pops up a messagebox, that it failed to find some resources. So maybe the install is still screwed up? -- 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=10134 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |focht(a)gmx.net --- Comment #20 from Anastasius Focht <focht(a)gmx.net> 2008-02-03 12:44:41 --- Hello, --- quote --- Yip , that's true, but while trying to run a simple .net app (i used fastmd5 again) it pops up a messagebox, that it failed to find some resources. So maybe the install is still screwed up? --- quote --- That's why I said "some issues left" :-) Registering assemblies into GAC and pre JIT-ing (ngen tool) doesn't work right now due to a bug in shlwapi's UrlCombineW(). Because of this bug, .NET 1.x fusion loader won't find any referenced assemblies on app startup, leading to rather cryptic "resource not found" error message. --- snip trace --- .. 001f:Call shlwapi.UrlCombineW(005436d8 L"C:\\windows\\Microsoft.NET\\Framework\\v1.1.4322/",0053b590 L"C:\\windows\\Microsoft.NET\\Framework\\v1.1.4322\\System.dll",00544728 L"hS\0108S",0033e320,00000000) ret=7904e23d .. 001f:Ret shlwapi.UrlCombineW() retval=00000000 ret=7904e23d 001f:Call shlwapi.UrlIsW(00544728 L"file:///C:/windows/Microsoft.NET/Framework/v1.1.4322/System.dll/",00000003) ret=7904e250 001f:Ret shlwapi.UrlIsW() retval=00000001 ret=7904e250 001f:Call shlwapi.UrlUnescapeW(00544728 L"file:///C:/windows/Microsoft.NET/Framework/v1.1.4322/System.dll/",00542688,0033e35c,00000000) ret=7904e267 001f:Ret shlwapi.UrlUnescapeW() retval=00000000 ret=7904e267 .. --- snip trace --- The returned combined URL/path is invalid. Fusion internally re-verifies paths before mapping dlls and rejects it. reduced: "c:\\test/" + "c:\\test\\mylib.dll" wine -> "file:///c:\\test\\mylib.dll/" (wrong) windows -> "file:///c:\\test\\mylib.dll" (correct, I wrote a small test case and tested with Windows XP SP2). So get that bug fixed and apps/fusion will find the requested assemblies. -- For trace/logging purposes you can enable fusion's verbose logging: --- snip --- [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion] "ForceLog"=dword:00000001 "LogResourceBinds"=dword:00000001 "LogFailures"=dword:00000001 "LogPath"="C:\\Temp\\FusionLogs" --- snip --- That will get you detailed CLR assembly search and loader logs. Handy for diagnosing assembly loading problems. 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=10134 --- Comment #21 from Dan Kegel <dank(a)kegel.com> 2008-02-22 00:02:07 --- *** Bug 10772 has been marked as a duplicate of this bug. *** -- 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=10134 --- Comment #22 from Dan Kegel <dank(a)kegel.com> 2008-02-25 16:46:45 --- Alexandre says he just committed http://winehq.org/pipermail/wine-cvs/2008-February/040705.html which should obsolete the patch you gave in #17? -- 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=10134 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #10372|0 |1 is obsolete| | --- Comment #23 from Anastasius Focht <focht(a)gmx.net> 2008-02-25 18:02:39 --- (From update of attachment 10372) Hello, @dank --- quote --- Alexandre says he just committed http://winehq.org/pipermail/wine-cvs/2008-February/040705.html which should obsolete the patch you gave in #17? --- quote --- Sure. Thats works too. But if you allow to express my personal opinion ... That commit might "cure" that specific bug but in overall it seems a bit problematic to me. Although ntdll.check_actctx is a wine internal helper, guarding it with SEH hides bugs/gaps in ntdll activation context api which could be detected by crashes otherwise (like the ActivationContextBasicInformation one). Additionally it adds a good amount of access violations/exceptions (in case of .NET) to logs/traces which makes it more difficult to track down the real problems. When I analyze traces/debug stuff I usually hunt for exceptions first... but well. 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=10134 --- Comment #24 from Alexandre Julliard <julliard(a)winehq.org> 2008-02-26 03:36:18 --- The bug is that the app is accessing the internals of the activation context, and passing the magic number as a pointer. It looks like it's confusing an activation context stack frame with the actual context. Of course never returning a context at all from QueryActCtx would fix it, but I have a hard time believing that it's the correct fix. -- 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=10134 Dan Kegel <dank(a)kegel.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |8178 Status|NEW |RESOLVED Resolution| |FIXED --- Comment #25 from Dan Kegel <dank(a)kegel.com> 2008-02-26 13:07:19 --- This is, I think, the same as bug 11678, which is now fixed. Microsoft Dynamics GP now installs .net 1.1 successfully. I moved the issues from #19 and #20 into a new bug, 11742. -- 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=10134 --- Comment #26 from Anastasius Focht <focht(a)gmx.net> 2008-02-26 15:06:32 --- Hello, --- snip --- The bug is that the app is accessing the internals of the activation context, and passing the magic number as a pointer. It looks like it's confusing an activation context stack frame with the actual context. Of course never returning a context at all from QueryActCtx would fix it, but I have a hard time believing that it's the correct fix. --- snip --- What kind of information do you need for a better fix? As I said in comment #17, the culprit seems to be the following call to KERNEL32.QueryActCtxW() from app: --- snip wine trace --- .. 0043:Call KERNEL32.LoadLibraryExW(791bd8f8 L"kernel32.dll",00000000,00000000) ret=791b7b63 0043:Ret KERNEL32.LoadLibraryExW() retval=7b820000 ret=791b7b63 0043:Call KERNEL32.GetProcAddress(7b820000,792405fc "QueryActCtxW") ret=792405e1 0043:Ret KERNEL32.GetProcAddress() retval=7b829fac ret=792405e1 0043:Call KERNEL32.QueryActCtxW(00000000,00000000,00000000,00000001,0034f9b0,00000008,0034f9c0) ret=7924064e 0043:trace:actctx:RtlQueryInformationActivationContext 00000000 (nil) (nil) 1 0x34f9b0 8 0x34f9c0 0043:Ret KERNEL32.QueryActCtxW() retval=00000001 ret=7924064e 0043:Call shlwapi.StrCmpW(790413f8 L"SXS_ACTIVATION_CONTEXT",79248834 L"SXS_ACTIVATION_CONTEXT") ret=7904136c .. --- snip wine trace --- The parameters of the call are hard coded (commented for you pleasure) --- snip app call parameter setup --- .. xor ebx, ebx .. push 8 pop edi .. lea eax, [ebp-4] ; pcbLen push eax push edi ; cbBuff = 8 = sizeof(ACTIVATION_CONTEXT_BASIC_INFORMATION) lea eax, [ebp-14h] ; pvBuff push eax push 1 ; ulClass = 1 = ActivationContextBasicInformation push ebx ; pvSubInst = NULL push ebx ; hActCtx = NULL push ebx ; dwFlags = 0 call QueryActCtxW .. --- snip app call parameter setup --- I wrote a test client calling the same function on XP with same parameters. There is no activation context handle returned back in basic info structure (both members are cleared). Though I admit that I don't understand why this query is actually done when no info is returned. Wine instead returns default process actctx with catastrophic result ... Later the code goes as follows (only relevant parts) : --- snip app evaluation of returned data --- .. mov eax, [ebp-8] ; pvBuff (PACTIVATION_CONTEXT_BASIC_INFORMATION) mov eax, [eax] ; pvBuff->hActCtx cmp eax, ebx ; hActCtx == NULL ? jz no_actctx_handle .. push 4 ; sizeof(HANDLE) push eax ; hActCtx .. call some_sub_xxx .. no_actctx_handle: .. ret --- snip app evaluation of returned data --- --- snip app uses context handle --- some_sub_xxx: .. mov eax, [ebp+10h] ; hActCtx (from previous snippet) mov eax, [eax] ; whoops ... probably not intended (ActCtx->magic) cmp eax, 0FFFFFFFFh jz go_home push eax call AddRefActCtx ; *boom* .. --- snip app uses context handle --- --- snip dlls/ntdll/actctx.c --- typedef struct _ACTIVATION_CONTEXT { ULONG magic; int ref_count; struct file_info config; struct file_info appdir; struct assembly *assemblies; unsigned int num_assemblies; unsigned int allocated_assemblies; } ACTIVATION_CONTEXT; --- snip dlls/ntdll/actctx.c --- Maybe there is one indirection missing, like you said (handle -> &actctx vs. handle -> frame ptr -> acttcx). I've never seen queries with such parameters in regular apps. Maybe this is just a special thing to .NET framework/apps and maybe other OS components. I don't like the road .NET sometimes takes either (directly accessing/peeking into internal/undocumented windows structures) ... it makes it a somewhat tedious task to get fully working .NET support into wine. Though in the long run it will actually help/boost wine. Anyway I still think fixing QueryActCtxW() (and not using SEH) would be the better solution regardless what kind of brain damage is present ... But in the end you are the boss. 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=10134 --- Comment #27 from Dan Kegel <dank(a)kegel.com> 2008-02-26 23:56:57 --- Please do not post disassembled sections of microsoft code for any reason ever. -- 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=10134 --- Comment #28 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2008-02-27 01:55:03 --- (In reply to comment #27)
Please do not post disassembled sections of microsoft code for any reason ever.
Even if that's the failing application code and not the OS one? -- 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=10134 --- Comment #29 from Anastasius Focht <focht(a)gmx.net> 2008-02-27 04:06:00 --- Hello, @Dmitry Timoshkov --- quote ---
Please do not post disassembled sections of microsoft code for any reason ever.
Even if that's the failing application code and not the OS one? --- quote --- Dan Kegel probably considers debugging *any* Microsoft produced code (installers, apps) potentially hostile/harmful - that far extends the wine restriction of not touching/looking at OS code. My snippets are *application* layer snippets - I don't consider .NET Framework a part of OS. I mainly post short app traces/assembly/pseudo code snippets for following reasons: - document/show interesting problems to readers - proof/evidence for people how stuff is accessed to justify my conclusions/writings/patches/input for patches - document my own work flow (bugzilla = "notepad") to be archived by google/mailing lists People aren't actually believing if I only write prose (good example from recent times: "the PEB loader lock needs to be exposed"). In fact some .NET patches would never made possible .. not mentioning countless analysis/patches from previous times. Anyway if you really take your policy to that extent then you should also disallow posting/attaching *any* backtraces and crashes from Microsoft related products (installers, apps) because technically they contain disassembly (although only a few opcode sequences from crash location). If you really persist this way then you have lost another supporter. I won't change my way of documenting bugs/supplying information. Period. 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=10134 Ralph Prichard <rprichard(a)freedomforum.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|rprichard(a)freedomforum.org | -- 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=10134 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #30 from Alexandre Julliard <julliard(a)winehq.org> 2008-03-07 11:28:29 --- Closing bugs fixed in 0.9.57. -- 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=10134 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|CVS/GIT |unspecified -- 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=10134 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |dotnet Fixed by SHA1| |198a00bc9eeb2d2fcf5122fa8b7 | |de38bb4fb526d Component|ole |ntdll Hardware|Other |x86 Version|unspecified |0.9.47. OS|other |Linux -- 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=10134 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- URL|http://www.microsoft.com/do |https://web.archive.org/web |wnloads/details.aspx?displa |/20090202091626/http://down |ylang=en&FamilyID=262D25E3- |load.microsoft.com/download |F589-4842-8157-034D1E7CF3A3 |/a/a/c/aac39226-8825-44ce-9 | |0e3-bf8203e74006/dotnetfx.e | |xe -- 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