[Bug 7448] MSDN academic alliance downloader hangs

[Wine Bugs]

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

------- Additional Comments From [e-mail]  2007-19-02 18:32 -------
Hello,

thanks for the download.
It seems i tracked the problem down after endless hours of debugging.
Indeed a serious wine bug.

Steps to reproduce:

1. start program using WINEDEBUG=+loaddll and let it load the html stuff in its
ie/gecko container
2. move the mouse out of window focus, activate another window
3. wait for the loaddll debug channel "unloaded module shdocvw" message to
appear on console
4. move mouse into focus again -> immediate crash

Whats the problem?
Well, the download tool periodically calls ole32.CoFreeUnusedLibraries() in its
message pumping loop (using some tick-difference count).
This leads to interesting behaviour in wine:

CoFreeUnusedLibraries() = COMPOBJ_DllList_FreeUnused() in wine

ole32 COMPOBJ_DllList_FreeUnused() iterates thru it's list of loaded dlls (which
contains "shdocvw" module of course) and calls DllCanUnloadNow() if dll export
this function.

Shell document object library refcount implementation:

--- snip ---

LONG SHDOCVW_refCount = 0;

HRESULT WINAPI DllCanUnloadNow(void)
{
    return SHDOCVW_refCount ? S_FALSE : S_OK;
}

--- snip ---

One can say it's not implemented usefully at all (a reference count should be
used [sic!]).
This leads to dangerous behaviour.
Any client which calls CoFreeUnusedLibraries() forces this dll to unload.
Guess ... the dll rundown sequence unregisters ie frame window class while being
used in client.

--- snip ---
  case DLL_PROCESS_DETACH:
        if (SHDOCVW_hshell32) FreeLibrary(SHDOCVW_hshell32);
        unregister_iewindow_class();
        if(wb_typeinfo)
            ITypeInfo_Release(wb_typeinfo);
        break;

--- snip ---

Solution?

- Implement proper reference counting in shdocvw

or as "quick fix"

- Prevent ole32 forced dll unload for shdocvw by making DllCanUnloadNow() always
return S_FALSE.

The ie frame window class unregistration might indicate another bug.
If properly done no dangling window proc pointer should be left in list.
I'm too tired to investigate this further.

Overall this bug might explain some other mysterious bug reports/crashes ...

Regards