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