[Bug 16013] xmllitesetup (subinstaller of IE7) fails to install

Sun Jan 4 13:06:29 CST 2009

http://bugs.winehq.org/show_bug.cgi?id=16013

--- Comment #8 from Anastasius Focht <focht at 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

-- 
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.