http://bugs.winehq.org/show_bug.cgi?id=16013
Summary: xmllitesetup (subinstaller of IE7) fails to install Product: Wine Version: 1.1.8 Platform: Other URL: http://support.microsoft.com/kb/915865 OS/Version: other Status: NEW Keywords: download Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: m.b.lankhorst@gmail.com
I'm trying to get the IE7 installer to work, but getting a part of it to work is proving difficult too.
So far I've gotten it sort of to work, by using hacks, and a native pidgen dll.
The xmllitesetup can be installed from the url.
The tree I used for installing is http://repo.or.cz/w/wine/multimedia.git
WINEPREFIX/drive_c/windows/KB915865.log is used by the installer for minimalistic logging
The failing lines seem to be
15.344: GetCatVersion: Failed to retrieve version information from C:\windows\system32\CatRoot{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\Tmp.0.KB915865.cat with error 0x57 15.372: InstallSingleCatalogFile: MyInstallCatalog failed for Tmp.0.KB915865.cat; error=0x000004c7. 15.373: DoInstallation:MyInstallCatalogFiles failed:STR_CATALOG_INSTALL_FAILED 15.378: CleanupTrustedInfFile: GetFileAttributes for C:\windows\system32\CatRoot{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\update_SP2GDR.cat failed: 0x2
http://bugs.winehq.org/show_bug.cgi?id=16013
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |juan_lang@yahoo.com
--- Comment #1 from Juan Lang juan_lang@yahoo.com 2008-11-12 19:45:56 --- Do you know which function is failing with ERROR_INVALID_PARAMETER (0x57)?
http://bugs.winehq.org/show_bug.cgi?id=16013
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hans@meelstraat.net
--- Comment #2 from Hans Leidekker hans@meelstraat.net 2008-12-16 13:17:16 ---
Do you know which function is failing with ERROR_INVALID_PARAMETER (0x57)?
This one can be ignored, it fails in the same way on Windows.
http://bugs.winehq.org/show_bug.cgi?id=16013
--- Comment #3 from Hans Leidekker hans@meelstraat.net 2008-12-16 13:52:08 --- I submitted patches to reduce the number of workarounds needed to reproduce this bug. What's left is a rebase of Maartens work on top of tomorrows winehq as well as a patch to have this directory created:
[..]/windows/system32/catroot/{f750e6c3-38ee-11d1-85e5-00c04fc295ee}
http://bugs.winehq.org/show_bug.cgi?id=16013
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #4 from Anastasius Focht focht@gmx.net 2009-01-03 18:35:50 --- Hello,
what is the current state of this bug? What hacks/workarounds are currently needed/what unofficial patches exist that didn't make it into GIT? What are you blocking on?
I encountered similar issues for .NET Framework 3.x (sub)installers and fixed some of them without having seen this bug. There are larger ones, requiring more work but I don't want to duplicate stuff when some fixes are already in the works here...
Regards
http://bugs.winehq.org/show_bug.cgi?id=16013
--- Comment #5 from Hans Leidekker hans@meelstraat.net 2009-01-04 06:25:51 ---
what is the current state of this bug? What hacks/workarounds are currently needed/what unofficial patches exist that didn't make it into GIT? What are you blocking on?
The catroot<GUID> subdirectory is now created on the first call to CryptCATAdminAcquireContext. I'm not sure if we still need an oem0.cat in there but if we do it should probably be a real catalog file because we're now opening them.
Next problem is a crash in SetupGetLineCount that looks like a corrupted memory problem.
The other unsubmitted patch in my tree is a fix for sfc. With these two patches the msi 3.1 installer (bug 10698) claims success, but they are not sufficient for the xmllite installer that this bug deals with.
I'll attach the patches here.
http://bugs.winehq.org/show_bug.cgi?id=16013
--- Comment #6 from Hans Leidekker hans@meelstraat.net 2009-01-04 06:29:00 --- Created an attachment (id=18461) --> (http://bugs.winehq.org/attachment.cgi?id=18461) Always return failure for section "DevicesToUpgrade" in SetupGetLineCount.
http://bugs.winehq.org/show_bug.cgi?id=16013
--- Comment #7 from Hans Leidekker hans@meelstraat.net 2009-01-04 06:30:38 --- Created an attachment (id=18462) --> (http://bugs.winehq.org/attachment.cgi?id=18462) Correct sfc exports and stub ordinal 3.
http://bugs.winehq.org/show_bug.cgi?id=16013
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
http://bugs.winehq.org/show_bug.cgi?id=16013
--- Comment #8 from Anastasius Focht focht@gmx.net 2009-01-04 13:06:21 --- Hello,
--- quote --- The catroot<GUID> subdirectory is now created on the first call to CryptCATAdminAcquireContext. I'm not sure if we still need an oem0.cat in there but if we do it should probably be a real catalog file because we're now opening them. --- quote ---
The folder and at least one initial (valid) catalog needs to be present in clean WINEPREFIX. Magic though CryptCATAdminAcquireContext() is not enough because several M$ installers have hard coded checks for catalogs (file enumerations) before crypt stuff is even executed.
Taking "xmllitesetup.exe" as example, this also applies to various sub-installer/component updates and main installer of course. Xmllitesetup.exe will unpack "update.exe" into c:\<hash>\update\update.exe".
The sub installer will quickly run into unhandled exception while trying to look for catalogs present on system. In a clean WINEPREFIX this will always happen because neither catroot/guid folder nor catalog is found:
--- snip --- ... 002b:Call KERNEL32.FindFirstFileW(00680608 L"C:\windows\system32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\*.cat",0033b348) ret=01085767 002b:Ret KERNEL32.FindFirstFileW() retval=ffffffff ret=01085767 002b:Call KERNEL32.GetLastError() ret=0108577a 002b:Ret KERNEL32.GetLastError() retval=00000003 ret=0108577a 002b:Call KERNEL32.GetLastError() ret=01085780 002b:Ret KERNEL32.GetLastError() retval=00000003 ret=01085780 002b:Call KERNEL32.RaiseException(e00bffff,00000000,00000000,00000000) ret=010857a6 ... 002b:trace:seh:_except_handler3 filter returned CONTINUE_SEARCH 002b:trace:seh:_except_handler3 reached TRYLEVEL_END, returning ExceptionContinueSearch 002b:Ret msvcrt._except_handler3() retval=00000001 ret=7bc72969 002b:trace:seh:call_stack_handlers handler at 0x1066099 returned 1 002b:trace:seh:call_stack_handlers calling handler at 0x7b87ec80 code=e00bffff flags=0 wine: Unhandled exception 0xe00bffff at address 0x7b844f78 (thread 002b), starting debugger... 002b:trace:seh:start_debugger Starting debugger "winedbg --auto 42 28" 002b:trace:seh:call_stack_handlers handler at 0x7b87ec80 returned 1 Unhandled exception: 0xe00bffff in 32-bit code (0x7b844ffb). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7b844ffb ESP:0033b234 EBP:0033b298 EFLAGS:00000246( - 00 - IZP1) EAX:7b82ccb1 EBX:7b8c3940 ECX:00000000 EDX:00000010 ESI:0033b330 EDI:0033b2b0 Stack dump: 0x0033b234 krb5_timestamp_to_sfstring+0x74: 00112668 0033b268 7bc34899 7bcb6645 0x0033b244 krb5_timestamp_to_sfstring+0x84: e00bffff 00000000 00000000 7b844f78 0x0033b254 krb5_timestamp_to_sfstring+0x94: 00000000 00112668 7bc34d08 7bcb6608 0x0033b264 krb5_timestamp_to_sfstring+0xa4: 7bcb665c 00000000 0033b2c4 7bcb6200 0x0033b274 krb5_timestamp_to_sfstring+0xb4: 0000000f 0000000f 7bcb6608 60147044 0x0033b284 krb5_timestamp_to_sfstring+0xc4: 7b8c9954 0033b2b8 60027701 7bc94c38 Backtrace: =>0 0x7b844ffb RaiseException+0x83() in kernel32 (0x0033b298) 1 0x7bc5e4a0 call_entry_point+0x20() in ntdll (0x0033b2b8) 2 0x7bc5e618 relay_call+0x171() in ntdll (0x0033b308) 3 0x7b82a98d in kernel32 (+0xa98d) (0x0033b5b4) 4 0x0108613c in update (+0x8613c) (0x0033b5f0) 5 0x01033585 in update (+0x33585) (0x0033b61c) 6 0x01038348 in update (+0x38348) (0x0033b6ac) 7 0x00000000 (0x01c6a75d) 8 0x00000000 (0x00000000) ... --- snip ---
There are four app SEHs installed in the SEH chain at this point which just short circuit to Wine msvcrt _except_handler3 and no one handles the exception which looks suspicious. Winedbg attaches, dumps info and the code *continues* run where RaiseException() left off. This is clearly not intended ... I suspect a problem with _except_handler3 and scope tables. There are valid filter and handler (__finally) prepared on stack frame but they don't seem to be executed. In all cases TRYLEVEL_END is reached immediately, resulting in ExceptionContinueSearch -- needs further investigation.
--- snip --- ... 002b:Ret KERNEL32.RaiseException() retval=7b82ccb1 ret=010857a6 002b:Call ntdll.wcscpy(0068068e,0033b374 L"\b5383\b3b83\70fb\6002\3e91\7bca\7281\6014\0004") ret=010857b0 002b:Ret ntdll.wcscpy() retval=0068068e ret=010857b0 002b:Call wintrust.CryptCATOpen(00680608 L"C:\windows\system32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\\b5383\b3b83\70fb\6002\3e91\7bca\7281\6014\0004",00000004,00000000,00000000,00000000) ret=010854b9 002b:Call KERNEL32.CreateFileW(00680608 L"C:\windows\system32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\\b5383\b3b83\70fb\6002\3e91\7bca\7281\6014\0004",80000000,00000001,00000000,00000003,00000000,00000000) ret=611dc982 002b:Ret KERNEL32.CreateFileW() retval=ffffffff ret=611dc982 002b:Ret wintrust.CryptCATOpen() retval=ffffffff ret=010854b9 ... --- snip ---
Some garbage is happening due to code which should not be executed after RaiseException() ... The catroot<GUID> problem funnily "heals" itself due to this erroneous behaviour - but again this is not correct and needs to be fixed.
Wine should create catroot\F750E6C3-38EE-11D1-85E5-00C04FC295EE by default (using .inf script) and not relying on the first caller of CryptCATAdminAcquireContext(). As already told, a single (valid) .cat is needed and all will be fine.
For the other issues, extra posts will follow (tomorrow). SetupGetLineCount(A) is not memory corruption but M$ brain damage ;-)
Regards
http://bugs.winehq.org/show_bug.cgi?id=16013
--- Comment #9 from Anastasius Focht focht@gmx.net 2009-01-05 03:39:28 --- Hello,
after the catroot<GUID> problem is solved by precreating "C:\windows\system32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}" and placing a dummy .cat file, the installer proceeds and crashes again:
--- snip --- 0043:Call KERNEL32.GetProcAddress(795a0000,0108c97a "SetupGetLineCountA") ret=01065cf4 0043:Ret KERNEL32.GetProcAddress() retval=795b4b68 ret=01065cf4 0043:Call setupapi.SetupGetLineCountA(0014fa70,0101fb98 "DevicesToUpgrade") ret=0105f240 0043:Call ntdll.RtlCreateUnicodeStringFromAsciiz(7eb49688,0101fb98 "DevicesToUpgrade") ret=795d144a 0043:Ret ntdll.RtlCreateUnicodeStringFromAsciiz() retval=00000001 ret=795d144a 0043:trace:seh:raise_exception code=c0000005 flags=0 addr=0x795ce86d 0043:trace:seh:raise_exception info[0]=00000000 0043:trace:seh:raise_exception info[1]=00000824 0043:trace:seh:raise_exception eax=00000824 ebx=795ea7c4 ecx=00000000 edx=00163c98 esi=7eb49720 edi=7eb496a8 0043:trace:seh:raise_exception ebp=7eb49618 esp=7eb495f0 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010246 0043:trace:seh:call_stack_handlers calling handler at 0x1066099 code=c0000005 flags=0 0043:Call msvcrt._except_handler3(7eb49598,7eb499f8,7eb492cc,7eb49134) ret=7bc72a5d 0043:trace:seh:_except_handler3 exception c0000005 flags=0 at 0x795ce86d handler=0x1066099 0x7eb492cc 0x7eb49134 semi-stub 0043:trace:seh:_except_handler3 reached TRYLEVEL_END, returning ExceptionContinueSearch 0043:Ret msvcrt._except_handler3() retval=00000001 ret=7bc72a5d 0043:trace:seh:call_stack_handlers handler at 0x1066099 returned 1 0043:trace:seh:call_stack_handlers calling handler at 0x7bc79a28 code=c0000005 flags=0 0043:Call KERNEL32.UnhandledExceptionFilter(7eb490a0) ret=7bc79a64 wine: Unhandled page fault on read access to 0x00000824 at address 0x795ce86d (thread 0043), starting debugger... 0043:trace:seh:start_debugger Starting debugger "winedbg --auto 59 172" 0043:Ret KERNEL32.UnhandledExceptionFilter() retval=00000000 ret=7bc79a64 0043:trace:seh:call_stack_handlers handler at 0x7bc79a28 returned 1 Unhandled exception: page fault on read access to 0x00000824 in 32-bit code (0x795ce86d). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:795ce86d ESP:7eb495f0 EBP:7eb49618 EFLAGS:00010246( - 00 -RIZP1) EAX:00000824 EBX:795ea7c4 ECX:00000000 EDX:00163c98 ESI:7eb49720 EDI:7eb496a8 Stack dump: 0x7eb495f0: 7eb49688 0101fb98 7eb49f1c 7eb49614 0x7eb49600: 0000001e 7bc9b990 7eb49658 7bc5e7db 0x7eb49610: 00000000 795ea7c4 7eb49668 795d14cb 0x7eb49620: 0014fa70 0015a098 795ee750 00148a38 0x7eb49630: 00000001 0015a098 7eb49fc3 02020175 0x7eb49640: 001103e8 00110fc0 7eb49680 795ea7c4 Backtrace: =>0 0x795ce86d find_section+0x2c() in setupapi (0x7eb49618) 1 0x795d14cb SetupGetLineCountW+0x39() in setupapi (0x7eb49668) 2 0x795d1474 SetupGetLineCountA+0x55() in setupapi (0x7eb49698) 3 0x7bc5e594 call_entry_point+0x20() in ntdll (0x7eb496b0) 4 0x7bc5e70c relay_call+0x171() in ntdll (0x7eb49700) 5 0x795b4b7d in setupapi (+0x14b7d) (0x7eb497a8) 6 0x7eb49fb5 (0x7eb4a393) ---- snip ---
The crash also happens in other installers (.NET 3.x Framework, WIC, ..) - a general problem which needs to be solved.
First, lets look how the parameters to SetupGetLineCountA() are actually constructed. If you do the usual +relay trace you might be surprised ... There is only one RtlAllocateHeap()/RtlReAllocateHeap pair which actually refers to this handle (and the structure behind).
Fortunately, +snoop comes to help:
--- snip --- .. 003c:CALL UPDSPAPI.UpdSpOpenInfFileA(010bd080,00000000,00000002,00000000) ret=0104a430 003c:Call ntdll.RtlAllocateHeap(00110000,00000000,00000037) ret=004689d6 003c:Ret ntdll.RtlAllocateHeap() retval=0014b260 ret=004689d6 003c:Call KERNEL32.lstrlenA(0014b260 "c:\44cbd7a5c10fb3180b6fa80dec\update\update_SP2GDR.inf") ret=00468b20 003c:Ret KERNEL32.lstrlenA() retval=00000036 ret=00468b20 ... 003c:Call ntdll.RtlReAllocateHeap(00110000,00000000,0014b460,0000006e) ret=00468a08 003c:Ret ntdll.RtlReAllocateHeap() retval=0014b460 ret=00468a08 ... 003c:RET UPDSPAPI.UpdSpOpenInfFileA() retval=0014fa70 ret=0104a430 --- snip ---
Ok, the installer seems to use its own method/API from UPDSPAPI (discussed later) to create the HINF handle which is opaque datatype for internal inf file structure. This handle gets used in various calls (selection):
--- snip --- ... 003c:CALL UPDSPAPI.UpdSpGetLineCountA(0014fa70,0100b3c8) ret=010529c8 ... 0043:CALL UPDSPAPI.UpdSpGetSourceInfoA(0014fa70,00000001,00000003,7eb49794,00000104,00000000) ret=0103e7bf ... 0043:RET UPDSPAPI.UpdSpInstallFilesFromInfSectionA(0014fa70,00000000,0014b460,0100f558,010bcd20,00000006) retval=00000001 ret=0103e80c ... 0043:RET UPDSPAPI.UpdSpGetSourceFileLocationA(0014fa70,00000000,001636b0,7eb4978c,00000000,00000000,7eb49790) retval=00000000 ret=0103e846 ... 0043:CALL UPDSPAPI.UpdSpInstallFilesFromInfSectionA(0014fa70,00000000,0014b460,01012148,010bcd20,00000004) ret=0103ed87 ... 0043:CALL UPDSPAPI.UpdSpFindFirstLineA(0014fa70,0101656c,00000000,7eb49784) ret=01031ce8 ... --- snip ---
And finally ends up calling SetupGetLineCountA() with the same HINF, see first trace snippet. What's that UPDSPAPI?
Extracting the version info resource from that PE reveals:
--- snip --- $ strings -e l updspapi.dll
... VS_VERSION_INFO StringFileInfo 040904B0 CompanyName Microsoft Corporation FileDescription Windows Servicing Setup API FileVersion 6.2.0029.0 (SRV03_QFE.031113-0918) InternalName SETUPAPI.DLL LegalCopyright Microsoft Corporation. All rights reserved. OriginalFilename SETUPAPI.DLL ProductName Microsoft Windows Operating System ProductVersion 6.2.0029.0 VarFileInfo ... --- snip ---
Just to be sure an exports snippet:
--- snip --- $ winedump -j export updspapi.dll Contents of updspapi.dll: 371424 bytes
Exports table:
Name: UPDSPAPI.dll Characteristics: 00000000 TimeDateStamp: 42C17F9B Tue Jun 28 18:49:31 2005 Version: 0.00 Ordinal base: 1 # of functions: 70 # of Names: 70 Addresses of functions: 0001FE88 Addresses of name ordinals: 000200B8 Addresses of names: 0001FFA0
Entry Pt Ordn Name 00007434 1 UpdSpCloseFileQueue 00012883 2 UpdSpCloseInfFile 0000A17B 3 UpdSpCommitFileQueueA 0000A195 4 UpdSpCommitFileQueueW 00017266 5 UpdSpCopyErrorA 00016E6A 6 UpdSpCopyErrorW ... --- snip ---
This looks like some kind of stripped down setupapi, shipped with installers. The number of exported functions is reduced to a subset as compared to Wine's and M$ setupapi.dll.
The real problem is that OS internal data structures (opaque handles) are passed between this installer shipped dll and OS (Wine) dlls. Because we have no knowledge about the layout of OS internal (undocumented) structures we have a problem.
There would be no problem at all if M$ would just consistently use APIs! Either their own installer supplied APIs for the inf stuff because UPDSPAPI.dll also contains:
Winedump export snippet:
--- snip --- 0000F82C 25 UpdSpGetLineCountA 0000F62D 26 UpdSpGetLineCountW --- snip ---
or just OS (Wine) setupapi for all inf stuff!
This mixup is cleanly brain damage ... They still tend to keep this Internet explorer/installers tightly bound to OS.
The "best" solution to cope with this problem is unfortunately: SEH Any page fault caused by "foreign created" data structures passed into API will be caught and failure is returned.
This is probably something that AJ would find acceptable. Just guard SetupGetLineCountA() or SetupGetLineCountW() (to cover both cases) with SEH, e.g.
__TRY { ... <might use foreign data structures> } __EXCEPT_PAGE_FAULT { .. <set return failure (-1)> } __ENDTRY
and add some comment to state the reason (M$ installers). As already pointed out, failure of this API doesn't harm the installer at all.
Regards
http://bugs.winehq.org/show_bug.cgi?id=16013
--- Comment #10 from Anastasius Focht focht@gmx.net 2009-01-05 05:30:57 --- Hello again,
for the sfc part there is not much to say - the ordinals are simply undocumented. One has to guess the parameter types and return values by +snoop or debugging the installer. Your patch to add exported undocumented ordinals and the stub looks correct. We have to live with this information deficiency so I think it should be accepted as it is.
After applying the sfc patch:
From "c:\windows\KB915865.log":
--- snip --- 6.792: PFE2: Failed to connect to server; error=0x0 --- snip ---
This is most likely due to undocumentd sfc ordinal 3 returning 0, but harmless. The installer looks at return value >0 and might actually do more sfc stuff if connection to "server" succeeds (whatever this means).
--- snip --- 6.795: GetCatVersion: Failed to retrieve version information from C:\windows\system32\CatRoot{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\Tmp.0.KB915865.cat with error 0x57 6.796: GetCatVersion: Failed to retrieve version information from C:\windows\Tmp.0.KB915865.cat with error 0x80092004 6.835: InstallSingleCatalogFile: MyInstallCatalog failed for Tmp.0.KB915865.cat; error=0x000004c7. 6.836: DoInstallation:MyInstallCatalogFiles failed:STR_CATALOG_INSTALL_FAILED 6.836: CleanupTrustedInfFile: GetFileAttributes for C:\windows\system32\CatRoot{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\oem0.cat failed: 0x2 6.859: DeRegistering the Uninstall Program -> KB915865, 0 6.859: Failed to install catalog files. 9.117: Message displayed to the user: Failed to install catalog files. 9.117: User Input: OK 9.118: Update.exe extended error code = 0xf01e 9.118: Update.exe return code was masked to 0x643 for MSI custom action compliance. --- snip ---
So this is essentially the same as in first post from bug report.
The first failure is correct due to KB915865.cat already present in catroot, a temp .cat is created in "C:\windows\Tmp.0.KB915865.cat" on not in "C:\windows\system32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\Tmp.0.KB915865.cat" where the first try goes.
The second try:
--- snip --- 0035:Call crypt32.CryptSIPRetrieveSubjectGuid(001e84f0 L"C:\windows\Tmp.0.KB915865.cat",00000000,001cad9c) ret=71a7de2c 0035:Call KERNEL32.CreateFileW(001e84f0 L"C:\windows\Tmp.0.KB915865.cat",80000000,00000001,00000000,00000003,00000080,00000000) ret=606b3ae1 0035:Ret KERNEL32.CreateFileW() retval=00000104 ret=606b3ae1 ... 0035:Ret crypt32.CryptSIPRetrieveSubjectGuid() retval=00000001 ret=71a7de2c 0035:Ret wintrust.CryptCATOpen() retval=001cad88 ret=010710c4 0035:Call wintrust.CryptCATGetCatAttrInfo(001cad88,01025430 L"SPAttr") ret=010710f2 0035:fixme:wintrust:CryptCATGetCatAttrInfo 0x1cad88, L"SPAttr" 0035:Call KERNEL32.SetLastError(80092004) ret=71a7ca2e 0035:Ret KERNEL32.SetLastError() retval=80092004 ret=71a7ca2e 0035:Ret wintrust.CryptCATGetCatAttrInfo() retval=00000000 ret=010710f2 ... 0035:Call KERNEL32.MultiByteToWideChar(00000000,00000000,01025388 "GetCatVersion: Failed to retrieve version information from %S with error 0x%lx",ffffffff,00000000,00000000) ret=6c516e1c ... 0035:Call crypt32.CryptSIPRetrieveSubjectGuid(001e84f0 L"C:\windows\Tmp.0.KB915865.cat",00000000,001cad9c) ret=71a7de2c 0035:Call KERNEL32.CreateFileW(001e84f0 L"C:\windows\Tmp.0.KB915865.cat",80000000,00000001,00000000,00000003,00000080,00000000) ret=606b3ae1 0035:Ret KERNEL32.CreateFileW() retval=00000104 ret=606b3ae1 ... 0035:Ret crypt32.CryptSIPRetrieveSubjectGuid() retval=00000001 ret=71a7de2c 0035:Ret wintrust.CryptCATOpen() retval=001cad88 ret=010711c7 0035:Call wintrust.CryptCATGetCatAttrInfo(001cad88,01025440 L"SPLevel") ret=010711ef 0035:fixme:wintrust:CryptCATGetCatAttrInfo 0x1cad88, L"SPLevel" 0035:Call KERNEL32.SetLastError(80092004) ret=71a7ca2e 0035:Ret KERNEL32.SetLastError() retval=80092004 ret=71a7ca2e 0035:Ret wintrust.CryptCATGetCatAttrInfo() retval=00000000 ret=010711ef ... 0035:Call msvcrt._vsnprintf(0033a94b,000007f7,01026ef0 "InstallSingleCatalogFile: MyInstallCatalog failed for %s; error=0x%08lx.",0033b17c) ret=0106b900
--- snip ---
The installer tries to retrieve the catalog version by CryptCATGetCatAttrInfo( .. "SPAttr") and then SP (=service pack version?) by CryptCATGetCatAttrInfo( ... "SPLevel") on both locations. This missing functionality is most likely harmless but might be added one day by crypt component maintainers ;-)
The real problem becomes only visible when on one debugs the installer itself and looks again at trace logs.
From "c:\windows\KB915865.log":
--- snip --- 6.835: InstallSingleCatalogFile: MyInstallCatalog failed for Tmp.0.KB915865.cat; error=0x000004c7. --- snip ---
This error code is set internally, not using any API. At the point of this failure, a function pointer is evaluated (!= NULL). The corresponding function pointer (table) is initialized in very early installer startup phase. Armed with the information gathered from debugging, the trace log reveals:
--- snip --- 0035:Call KERNEL32.LoadLibraryA(0100955c "SetupApi.DLL") ret=01072120 0035:Call PE DLL (proc=0x7c0c89c4,module=0x7c090000 L"setupapi.dll",reason=PROCESS_ATTACH,res=(nil)) ... 0035:Ret PE DLL (proc=0x7c0c89c4,module=0x7c090000 L"setupapi.dll",reason=PROCESS_ATTACH,res=(nil)) retval=1 0035:Ret KERNEL32.LoadLibraryA() retval=7c090000 ret=01072120 0035:Call KERNEL32.GetProcAddress(7c090000,01025de0 "pSetupVerifyCatalogFile") ret=01072150 0035:Ret KERNEL32.GetProcAddress() retval=00000000 ret=01072150 0035:Call KERNEL32.GetProcAddress(7c090000,01025dc8 "pSetupInstallCatalog") ret=01072162 0035:Ret KERNEL32.GetProcAddress() retval=00000000 ret=01072162 0035:Call KERNEL32.GetProcAddress(7c090000,01025db0 "pSetupStringTableEnum") ret=01072174 0035:Ret KERNEL32.GetProcAddress() retval=7c09defc ret=01072174 0035:Call KERNEL32.GetProcAddress(7c090000,01025d94 "pSetupStringTableDestroy") ret=01072186 0035:Ret KERNEL32.GetProcAddress() retval=7c09f508 ret=01072186 ... --- snip ---
The problem is actually "pSetupInstallCatalog" not implemented and to be called later.
Looking at MSDN: http://msdn.microsoft.com/en-us/library/bb432395.aspx
"[This function is no longer supported by Microsoft. Developers should use CryptCATAdminAddCatalog.]"
The prototype puzzles me: there is no separate ansi (A) and unicode (W) version but the params are LPCTSTR which indicates that setupapi.dll itself might be built as ansi or unicode version (Win9x vs NT)?
"This function has no associated import library or header file; you must call it using the LoadLibrary and GetProcAddress functions."
The installer seems the use the API as unicode as the MultiByteToWideChar() calls indicate before (NT). There is also a OS version check and if not NT, InstallCatalog() (ansi) is used.
After adding a simple stub with unicode type params for "pSetupInstallCatalog" to setupapi which just pretends success like InstallCatalog(), one gets further:
--- snip --- 001c:Call setupapi.pSetupInstallCatalog(0033b1a8 L"C:\windows\Tmp.0.KB915865.cat",001b1140 L"Tmp.0.KB915865.cat",00000000) ret=010768d2 001c:fixme:setupapi:pSetupInstallCatalog L"C:\windows\Tmp.0.KB915865.cat", L"Tmp.0.KB915865.cat", (nil) 001c:Ret setupapi.pSetupInstallCatalog() retval=00000000 ret=010768d2 ... --- snip ---
The Xmllite installer finishes successfully (at least it says so) and the log file reveals now:
--- snip --- 5.490: PFE2: Failed to connect to server; error=0x0 5.497: GetCatVersion: Failed to retrieve version information from C:\windows\system32\CatRoot{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\Tmp.0.KB915865.cat with error 0x57 5.504: GetCatVersion: Failed to retrieve version information from C:\windows\Tmp.0.KB915865.cat with error 0x80092004 5.719: ProcessSetupContentSection: PROCESS_SETUP_CONTENT_OP_INSTALL: Copied c:\4dd855c1bd3013aefe8e90e5bf20\update\update_SP2QFE.inf -> c:\windows$hf_mig$\KB915865\update\update_SP2QFE.inf. 5.722: ProcessSetupContentSection: PROCESS_SETUP_CONTENT_OP_INSTALL: Copied c:\4dd855c1bd3013aefe8e90e5bf20\spuninst.exe -> c:\windows$hf_mig$\KB915865\spuninst.exe. 5.723: ProcessSetupContentSection: PROCESS_SETUP_CONTENT_OP_INSTALL: Copied c:\4dd855c1bd3013aefe8e90e5bf20\spmsg.dll -> c:\windows$hf_mig$\KB915865\spmsg.dll. 5.725: ProcessSetupContentSection: PROCESS_SETUP_CONTENT_OP_INSTALL: Copied c:\4dd855c1bd3013aefe8e90e5bf20\update\spcustom.dll -> c:\windows$hf_mig$\KB915865\update\spcustom.dll. 5.727: ProcessSetupContentSection: PROCESS_SETUP_CONTENT_OP_INSTALL: Copied c:\4dd855c1bd3013aefe8e90e5bf20\update\KB915865.CAT -> c:\windows$hf_mig$\KB915865\update\KB915865.CAT. 5.730: ProcessSetupContentSection: PROCESS_SETUP_CONTENT_OP_INSTALL: Copied c:\4dd855c1bd3013aefe8e90e5bf20\update\update.exe -> c:\windows$hf_mig$\KB915865\update\update.exe. 5.733: ProcessSetupContentSection: PROCESS_SETUP_CONTENT_OP_INSTALL: Copied c:\4dd855c1bd3013aefe8e90e5bf20\update\updspapi.dll -> c:\windows$hf_mig$\KB915865\update\updspapi.dll. 5.734: ProcessSetupContentSection: PROCESS_SETUP_CONTENT_OP_INSTALL: Copied c:\4dd855c1bd3013aefe8e90e5bf20\update\update.ver -> c:\windows$hf_mig$\KB915865\update\update.ver. 5.736: ProcessSetupContentSection: PROCESS_SETUP_CONTENT_OP_INSTALL: Copied c:\4dd855c1bd3013aefe8e90e5bf20\update\updatebr.inf -> c:\windows$hf_mig$\KB915865\update\updatebr.inf. 5.738: ProcessSetupContentSection: PROCESS_SETUP_CONTENT_OP_INSTALL: Copied c:\4dd855c1bd3013aefe8e90e5bf20\update\eula.txt -> c:\windows$hf_mig$\KB915865\update\eula.txt. 5.739: ProcessSetupContentSection: PROCESS_SETUP_CONTENT_OP_INSTALL: Copied c:\4dd855c1bd3013aefe8e90e5bf20\update\branches.inf -> c:\windows$hf_mig$\KB915865\update\branches.inf. 5.744: Copied file: C:\windows\system32\xmllite.dll 5.758: Copied file: c:\windows$hf_mig$\KB915865\SP2QFE\xmllite.dll 5.770: DoInstallation: Installing assemblies with source root path: c:\4dd855c1bd3013aefe8e90e5bf20\ 5.770: Num Ticks for Copying files : 702 5.795: Num Ticks for Reg update and deleting 0 size files : 25 5.835: GetCatVersion: Failed to retrieve version information from C:\windows\system32\CatRoot{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\KB915865.cat with error 0x80092004 5.843: GetCatVersion: Failed to retrieve version information from C:\windows\KB915865.cat with error 0x80092004 6.062: DeleteCatalogFile Tmp.0.KB915865.cat failed with ERROR 2 6.064: ---- Old Information In The Registry ------ 6.065: Source:C:\windows$NtUninstallKB915865$\spuninst_000009_.tmp.dll 6.066: Destination: 6.066: Source:C:\windows$NtUninstallKB915865$\spuninst 6.067: Destination: 6.069: Source:C:\windows$NtUninstallKB915865$ 6.070: Destination: 6.072: Source:C:\windows$NtUninstallKB915865$\spuninst_000008_.tmp.dll 6.072: Destination: 6.073: Source:C:\windows$NtUninstallKB915865$\spuninst 6.074: Destination: 6.075: Source:C:\windows$NtUninstallKB915865$ 6.075: Destination: 6.076: ---- New Information In The Registry ------ 6.076: Source:C:\windows$NtUninstallKB915865$\spuninst_000009_.tmp.dll 6.077: Destination: 6.078: Source:C:\windows$NtUninstallKB915865$\spuninst 6.078: Destination: 6.079: Source:C:\windows$NtUninstallKB915865$ 6.080: Destination: 6.082: Source:C:\windows$NtUninstallKB915865$\spuninst_000008_.tmp.dll 6.082: Destination: 6.083: Source:C:\windows$NtUninstallKB915865$\spuninst 6.084: Destination: 6.084: Source:C:\windows$NtUninstallKB915865$ 6.085: Destination: 6.089: UpdateSpUpdSvcInf: Source [ProcessesToRunAfterReboot] section is empty; nothing to do. 6.092: CleanupTrustedInfFile: GetFileAttributes for C:\windows\system32\CatRoot{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\oem0.cat failed: 0x2 --- snip ---
All necessary files seem to get installed. I tested only for Xmllite installer.
Though the installation of IE7 seems questionable .. a lot of native crap might get installed which might cause problems for other stuff (say broken WINEPREFIX).
Regards
http://bugs.winehq.org/show_bug.cgi?id=16013
--- Comment #11 from Anastasius Focht focht@gmx.net 2009-01-06 14:54:00 --- Hello,
now that's some progress ;-) With sfc corrected and AJ's addition of updspapi.dll is looks a lot better.
Actually I didn't even think about adding updspapi.dll to Wine because it's neither documented in MSDN nor part of any (P)SDK hence my initial suggestion to leave that private M$ stuff alone (SEH)... Now I see the elegance of the solution but this also requires more work on setupapi. I'm sure you are already busy fixing setupapi :-)
In the meantime I provide another bugfix. In my analysis of the missing catroot folder/file problem (comment #8) I was a bit puzzled of that unusual exception handling (see the first trace log there).
It actually turns out the be a bug in Wine msvcrt._except_handler3().
To keep the story short: while looping through the scope table looking for filter/handlers, the new trylevel index must be taken from previousTryLevel of the current scope table entry. This also applies to the call_finally_block case.
E.g. pScopeTable->previousTryLevel should be corrected to pScopeTable[trylevel].previousTryLevel to have next try block filter/handler properly evaluated ...
Following shows the trace log with my correction (compare with comment #8 trace):
--- snip ---- 001f:Call KERNEL32.FindFirstFileW(006005d0 L"C:\windows\system32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\*.cat",0032b348) ret=01085767 001f:Ret KERNEL32.FindFirstFileW() retval=ffffffff ret=01085767 001f:Call KERNEL32.GetLastError() ret=0108577a 001f:Ret KERNEL32.GetLastError() retval=00000003 ret=0108577a 001f:Call KERNEL32.GetLastError() ret=01085780 001f:Ret KERNEL32.GetLastError() retval=00000003 ret=01085780 001f:Call KERNEL32.RaiseException(e00bffff,00000000,00000000,00000000) ret=010857a6 001f:trace:seh:raise_exception code=e00bffff flags=0 addr=0x7b844f58 001f:trace:seh:raise_exception eax=7b82cc91 ebx=7b8c3940 ecx=00000000 edx=00000010 esi=0032b330 edi=0032b2b0 001f:trace:seh:raise_exception ebp=0032b298 esp=0032b234 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00000246 001f:trace:seh:call_stack_handlers calling handler at 0x1066099 code=e00bffff flags=0 001f:Call msvcrt._except_handler3(0032b244,0032b5a4,0032aed0,0032ad70) ret=7bc729a5 001f:trace:seh:_except_handler3 exception e00bffff flags=0 at 0x7b844f58 handler=0x1066099 0x32aed0 0x32ad70 semi-stub 001f:trace:seh:_except_handler3 reached TRYLEVEL_END, returning ExceptionContinueSearch 001f:Ret msvcrt._except_handler3() retval=00000001 ret=7bc729a5 001f:trace:seh:call_stack_handlers handler at 0x1066099 returned 1 001f:trace:seh:call_stack_handlers calling handler at 0x1066099 code=e00bffff flags=0 001f:Call msvcrt._except_handler3(0032b244,0032b5e0,0032aed0,0032ad70) ret=7bc729a5 001f:trace:seh:_except_handler3 exception e00bffff flags=0 at 0x7b844f58 handler=0x1066099 0x32aed0 0x32ad70 semi-stub 001f:trace:seh:_except_handler3 filter = 0x1086156 001f:trace:seh:_except_handler3 filter returned EXECUTE_HANDLER 001f:trace:seh:_global_unwind2 (0x32b5e0) 001f:Call ntdll.RtlUnwind(0032b5e0,00000000,00000000,00000000) ret=60660ffa 001f: eax=606586dd ebx=6068b808 ecx=00000000 edx=7bcb6648 esi=e00bffff edi=01066099 ebp=0032abc8 esp=0032abb0 ds=002b es=002b fs=0063 gs=006b flags=00000202 001f:trace:seh:__regs_RtlUnwind code=c0000027 flags=2 001f:trace:seh:__regs_RtlUnwind calling handler at 0x7bc3b2a8 code=c0000027 flags=2 001f:trace:seh:__regs_RtlUnwind handler at 0x7bc3b2a8 returned 1 001f:trace:seh:__regs_RtlUnwind calling handler at 0x1066099 code=c0000027 flags=2 001f:Call msvcrt._except_handler3(0032a600,0032b5a4,0032a830,0032a5ac) ret=7bc729a5 001f:trace:seh:_except_handler3 exception c0000027 flags=2 at 0x60660ffa handler=0x1066099 0x32a830 0x32a5ac semi-stub 001f:trace:seh:msvcrt_local_unwind2 (0x32b5a4,0,-1) 001f:Call ntdll.NtCurrentTeb() ret=60660d8c 001f:Ret ntdll.NtCurrentTeb() retval=7ffd8000 ret=60660d8c 001f:trace:seh:msvcrt_local_unwind2 __try block cleanup level 0 handler 0x10857f0 ebp 0x32b5b4 001f:Call KERNEL32.GetLastError() ret=01085198 001f:Ret KERNEL32.GetLastError() retval=00000003 ret=01085198 001f:Call ntdll.RtlFreeHeap(005c0000,00000000,006005d0) ret=010851a9 001f:Ret ntdll.RtlFreeHeap() retval=00000001 ret=010851a9 001f:Call KERNEL32.SetLastError(00000003) ret=010851b0 001f:Ret KERNEL32.SetLastError() retval=00000003 ret=010851b0 001f:trace:seh:msvcrt_local_unwind2 unwound OK 001f:trace:seh:_except_handler3 unwound current frame, returning ExceptionContinueSearch 001f:Ret msvcrt._except_handler3() retval=00000001 ret=7bc729a5 001f:trace:seh:__regs_RtlUnwind handler at 0x1066099 returned 1 001f:Ret ntdll.RtlUnwind() retval=00000000 ret=60660ffa 001f: eax=00000000 ebx=6068b808 ecx=00000000 edx=7bcb6648 esi=e00bffff edi=01066099 ebp=0032abc8 esp=0032abb0 ds=002b es=002b fs=0063 gs=006b flags=00000202 001f:trace:seh:msvcrt_local_unwind2 (0x32b5e0,1,0) 001f:Call ntdll.NtCurrentTeb() ret=60660d8c 001f:Ret ntdll.NtCurrentTeb() retval=7ffd8000 ret=60660d8c 001f:trace:seh:msvcrt_local_unwind2 __try block cleanup level 1 handler 0x1086149 ebp 0x32b5f0 001f:Call KERNEL32.HeapDestroy(005c0000) ret=01085c10 001f:Ret KERNEL32.HeapDestroy() retval=00000001 ret=01085c10 ... 001f:Call user32.MessageBoxA(00000000,010fd640 "Path not found\r\n",010b42e0 " Setup Error",00011010) ret=0106e226 --- snip ----
The handler now gets properly picked up and the exception is handled fine (message box). Unfortunately this means that the accidental "self-healing" of missing catroot folder/file is gone now. :-| The xmllite installer will display the message box and abort (which is correct).
If an addition to Wine install script is not feasible, a winetricks step might be a way to overcome this problem.
Regards
http://bugs.winehq.org/show_bug.cgi?id=16013
--- Comment #12 from Hans Leidekker hans@meelstraat.net 2009-01-06 15:50:57 ---
now that's some progress ;-)
;-) The best thing is that it's not just this installer that benefits, MSI 3.1 and WIC now claim success, and .NET 3 progressed nicely as well. This is because they all employ these so called 'Hotfix' installers.
Next up is update.exe.
If an addition to Wine install script is not feasible, a winetricks step might be a way to overcome this problem.
Yes, it may take a while before we have a way to generate catalog files. I can do a patch for winetricks along the lines of l_intl.nls.
http://bugs.winehq.org/show_bug.cgi?id=16013
--- Comment #13 from Juan Lang juan_lang@yahoo.com 2009-01-06 16:03:46 --- (In reply to comment #12)
Yes, it may take a while before we have a way to generate catalog files.
What's missing?
http://bugs.winehq.org/show_bug.cgi?id=16013
--- Comment #14 from Hans Leidekker hans@meelstraat.net 2009-01-07 03:08:14 --- Juan Lang wrote:
What's missing?
Catalogs are described by .cdf files which are parsed by the CryptCATCDF* family of functions. They look like plain .inf files to me, so implementing these functions might be as simple as wrapping the inf parser in setupapi.
I'll let you judge what's needed to create a catalog file ;-)
http://bugs.winehq.org/show_bug.cgi?id=16013
--- Comment #15 from Juan Lang juan_lang@yahoo.com 2009-01-07 09:33:37 --- (In reply to comment #14)
Catalogs are described by .cdf files which are parsed by the CryptCATCDF* family of functions.
Interesting that the return value from CryptCATCDFOpen is a struct rather than the usual opaque handle.
I'll let you judge what's needed to create a catalog file ;-)
That's the thing, I don't know. A cat file is just a signed CTL, as far as I can tell. Those are mostly implemented. There are unimplemented bits, of course, but which are relevant I can't guess. Can you use native mscat32 or wintrust with makecat and see if it succeeds with builtin crypt32? If not, a +crypt log would tell me what's missing.
http://bugs.winehq.org/show_bug.cgi?id=16013
--- Comment #16 from Hans Leidekker hans@meelstraat.net 2009-01-07 10:20:05 --- Created an attachment (id=18558) --> (http://bugs.winehq.org/attachment.cgi?id=18558) +crypt log
Here's a +crypt log from running 'makecat /cat winetest.cdf'. Contents of this file can be found in dlls/wintrust/tests/crypt.c.
I used native wintrust + builtin mscat32 with one more function forwarded to wintrust: CryptCATCDFEnumMembersByCDFTag.
http://bugs.winehq.org/show_bug.cgi?id=16013
--- Comment #17 from Juan Lang juan_lang@yahoo.com 2009-01-07 11:37:32 --- (In reply to comment #16)
Here's a +crypt log from running 'makecat /cat winetest.cdf'. Contents of this file can be found in dlls/wintrust/tests/crypt.c.
I used native wintrust + builtin mscat32 with one more function forwarded to wintrust: CryptCATCDFEnumMembersByCDFTag.
Thanks. I forgot that native wintrust doesn't work with builtin crypt32 when encoding/decoding asn.1, because builtin crypt32 doesn't use msasn1. Sigh. Still, a few clues: trace:crypt:CryptSIPRetrieveSubjectGuid (L".\winetest.cdf" (nil) 0x32fe38) (snip) trace:crypt:CryptSIPLoad ({de351a42-8e59-11d0-8c47-00c04fc295ee} 0 0x32f9e4) How the heck did that succeed? Perhaps native wintrust has a fallback if CryptSIPRetrieveSubjectGuid fails. crypt32 needs some tests added to see if it should identify CDF files or not.
trace:crypt:CryptSIPCreateIndirectData (0x32f994 0x32fe4c (nil)) That's currently a stub in wintrust. Bug 16420 needs this too, though the implementation will likely differ for PE files and CDF files.
trace:crypt:CryptMsgEncodeAndSignCTL (00010001, 0x32fe18, 0x32fe60, 00000000, (nil), 0x32fe90) I just added an implementation of that.
So, at a quick glance, the crypt32 message stuff looks okay, it's mainly wintrust that needs work to create cat files. What happens with builtin wintrust and native mscat32?
http://bugs.winehq.org/show_bug.cgi?id=16013
--- Comment #18 from Hans Leidekker hans@meelstraat.net 2009-01-07 13:07:56 ---
What happens with builtin wintrust and native mscat32?
Native mscat32 also forwards to wintrust, so that crashes immediately on a call to unimplemented wintrust.dll.CryptCATCDFOpen.
http://bugs.winehq.org/show_bug.cgi?id=16013
Paul Vriens Paul.Vriens.Wine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Vriens.Wine@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=16013
--- Comment #19 from Paul Vriens Paul.Vriens.Wine@gmail.com 2009-01-09 07:47:33 --- Doing the following creates a correct cat file out of the cdf file mentioned by Hans:
CryptCATCDFOpen Loop through the header with CryptCATCDFEnumCatAttributes Loop through the catalog files with CryptCATCDFEnumMembersByCDFTagEx CryptCATCDFClose
All tested with a modified and crosscompiled wintrust/crypt test on W2K3.
http://bugs.winehq.org/show_bug.cgi?id=16013
WindowsHater gaab_rs@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gaab_rs@hotmail.com
http://bugs.winehq.org/show_bug.cgi?id=16013
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|patch | Component|-unknown |wintrust
--- Comment #20 from Juan Lang juan_lang@yahoo.com 2009-10-06 12:18:59 --- Removing patch keyword, as the patch doesn't fix the bug. Also moving component to wintrust, since it seems to depend being able to create catalog files, which is a wintrust bug.
http://bugs.winehq.org/show_bug.cgi?id=16013
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #21 from Dan Kegel dank@kegel.com 2010-08-22 12:19:15 --- This might be fixed - I used 'winetricks ie7' to install ie7, xmllite.dll got installed into system32, and I'm typing this comment in the resulting ie7.
Mind you, it doesn't always work - I've seen crashes in the installer while loading wintrust.dll, and various other doesn't-work-at-all kind of things, but retrying a couple times got me to a somewhat usable and even speedy ie7. (Although it seems to be showing that it will set this bug to NEW FIXED when I submit, which is kind of strange; guess its javascript is still funky.)
http://bugs.winehq.org/show_bug.cgi?id=16013
--- Comment #22 from Dan Kegel dank@kegel.com 2010-08-22 12:37:56 --- 'winetricks ie7' worked for me even when I disabled the workaround for this bug in winetricks, i.e. I commented out the lines mkdir -p "$WINDIR"/system32/catroot/{f750e6c3-38ee-11d1-85e5-00c04fc295ee} try cp -f "$WINETRICKS_CACHE"/winetest.cat "$WINDIR"/system32/catroot/{f750e6c3-38ee-11d1-85e5-00c04fc295ee}/oem0.cat
I did have to run it twice (removing .wine between runs), so it's not reliable.
http://bugs.winehq.org/show_bug.cgi?id=16013
--- Comment #23 from Dan Kegel dank@kegel.com 2010-12-15 15:00:38 CST --- I added an xmllite verb to winetricks. The fake .cat file workaround is still needed. (The darn installer hangs at the end in interactive mode.) Haven't verified that the dll is registered properly, etc.
http://bugs.winehq.org/show_bug.cgi?id=16013
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
--- Comment #24 from Austin English austinenglish@gmail.com 2011-04-15 14:42:40 CDT --- *** Bug 26790 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=16013
A Wine user RandomAccountName@mail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |RandomAccountName@mail.com
http://bugs.winehq.org/show_bug.cgi?id=16013
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |kennybobs@o2.co.uk Resolution| |FIXED
--- Comment #25 from Ken Sharp kennybobs@o2.co.uk 2012-09-10 20:06:04 CDT --- Works fine here in wine-1.5.12-194-g688aa1f with no overrides.
http://bugs.winehq.org/show_bug.cgi?id=16013
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #26 from Alexandre Julliard julliard@winehq.org 2012-09-14 13:33:57 CDT --- Closing bugs fixed in 1.5.13.
-
wine-bugs＠winehq.org