[Bug 8159] New: Native ie6sp1 install crashes/broken, possibly affects other apps using OLE too

[Wine Bugs]

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

           Summary: Native ie6sp1 install crashes/broken, possibly affects
                    other apps using OLE too
           Product: Wine
           Version: 0.9.35.
          Platform: All
               URL: http://download.microsoft.com/download/ie6sp1/finrel/6_s
                    p1/W98NT42KMeXP/DE/ie6setup.exe
        OS/Version: other
            Status: UNCONFIRMED
          Severity: critical
          Priority: P2
         Component: wine-ole
        AssignedTo: wine-bugs at winehq.org
        ReportedBy: focht at gmx.net


Hello,

while playing with some application, i needed to install native ie6sp1 (not just
fake with winetricks).
Doesnt work, now crashes in installer (ie6wzd.exe).
I remember this has worked before?

Some debugging revealed that modules are unloaded due to CoUninitialize.
COM interface method calls cause access violations because the inproc server is
already unloaded/dead.
In this specific case: native install engine, inseng.dll, IID_IInstall

Explicit wine dll override of inseng.dll produces same result.
All tested on clean install (rm -rf .wine)
wine-0.9.35-140-g452f728

Following are explicit and implicit ole/com init/uninit calls, extracted from
log (i paired them for betting reading):

--- snip ---
0009:trace:ole:CoInitializeEx ((nil), 2)
0009:trace:ole:CoInitializeEx () - Initializing the COM libraries

000d:trace:ole:OleInitialize ((nil))
000d:trace:ole:CoInitializeEx ((nil), 2)

000d:trace:ole:OleInitialize ((nil))
000d:trace:ole:CoInitializeEx ((nil), 2)
000d:trace:ole:OleUninitialize ()
000d:trace:ole:CoUninitialize ()

000d:trace:ole:OleUninitialize ()
000d:trace:ole:OleUninitialize () - Freeing the last reference count
000d:trace:ole:CoUninitialize ()

000d:trace:ole:OleInitialize ((nil))
000d:trace:ole:CoInitializeEx ((nil), 2)
000d:trace:ole:OleUninitialize ()
000d:trace:ole:OleUninitialize () - Freeing the last reference count
000d:trace:ole:CoUninitialize ()

000d:trace:ole:CoInitializeEx ((nil), 2)
000d:trace:ole:CoUninitialize ()
000d:trace:ole:apartment_release 80000000d: after = 0
000d:trace:ole:apartment_release destroying apartment 0x16f708, oxid 80000000d
000d:trace:ole:COMPOBJ_DllList_ReleaseRef freeing 0x50060000
000d:trace:ole:DllMain (0x68f30000,0,(nil))
000d:trace:loaddll:free_modref Unloaded module
L"C:\\windows\\temp\\xxx\\inseng.dll" : native
000d:trace:loaddll:free_modref Unloaded module
L"c:\\windows\\system32\\oleaut32.dll" : builtin
--- snip ---

You might argue that all Ole Init and Uninit calls are apartment-wise balanced,
therefore the unload of installer engine due to apartment release in
CoUninitialize() is valid.
This is not the way windows handles inproc server/module refcounts...

The global COM reference count is still > 1 (due to first CoInitializeEx() call,
see tid=0009) (independent of apartments).

For proof i wrote a small test client which shows same behaviour as the ie6
installer.
Will follow in next attachment.
Such code is not that uncommon...

The ol32 maintainer might consider COMPOBJ_DllList_ReleaseRef()
(apartment_release, ...) honour s_COMLockCount... 
Though this change might require more testing :) 

Regards

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.