[Bug 10365] Nero 7 essentials fails to install (NeroAg_Init custom action fails because CA dll instance data is not reset/unloaded due to binary dll resource reference kept from main msi thread)

[wine-bugs at winehq.org]

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

Anastasius Focht <focht at gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|-unknown                    |msi
            Summary|Nero 7 essentials fails to  |Nero 7 essentials fails to
                   |install                     |install (NeroAg_Init custom
                   |                            |action fails because CA dll
                   |                            |instance data is not
                   |                            |reset/unloaded due to
                   |                            |binary dll resource
                   |                            |reference kept from main
                   |                            |msi thread)

--- Comment #21 from Anastasius Focht <focht at gmx.net> 2011-06-29 15:17:59 CDT ---
Hello again,

while debugging "NeroAg_Init" custom action I noticed it validated some dll
instance data, something that looked like msi database handle.
At the point of calling custom action entry point, the value "2" (db handle
passed to CA) was already in data area and the entry doesn't like this.

The custom action dll was mapped earlier:

1. as part of temporary binary resource extraction (main msi thread 44) ->
keeps reference

2. in custom action "NeroAg_CheckMinBuild" -> reference count neutral

--- snip ---
0044:trace:msi:ACTION_CustomAction Handling custom action
L"NeroAg_CheckMinBuild" (101 L"NCADll" L"NeroAg_CheckMinBuild") 
...
0044:Call KERNEL32.LoadLibraryW(0033f064
L"C:\\users\\focht\\Temp\\msi9e12.tmp") ret=73a564ba 
...
0044:Ret  KERNEL32.LoadLibraryW() retval=10000000 ret=73a564ba 
...
0044:trace:msi:HANDLE_CustomType1 Calling function L"NeroAg_CheckMinBuild" from
L"C:\\users\\focht\\Temp\\msi9e12.tmp"
...
0045:trace:msi:DllThread custom action (45) started 
...
0045:Call KERNEL32.LoadLibraryW(00197c4c
L"C:\\users\\focht\\Temp\\msi9e12.tmp") ret=73a56f36
0045:Ret  KERNEL32.LoadLibraryW() retval=10000000 ret=73a56f36 
...
0045:Call KERNEL32.GetProcAddress(10000000,001599b8 "NeroAg_CheckMinBuild")
ret=73a56fd7
0045:Ret  KERNEL32.GetProcAddress() retval=100106f0 ret=73a56fd7
...
0045:trace:msi:ACTION_CallDllFunction calling L"NeroAg_CheckMinBuild" 
...
0045:Call KERNEL32.FreeLibrary(10000000) ret=73a5725d
0045:Ret  KERNEL32.FreeLibrary() retval=00000001 ret=73a5725d 
...
0045:trace:msi:DllThread custom action (45) returned 0 
...
0015:trace:msi:DllThread custom action (15) started 
...
0015:Call PE DLL (proc=0x10094b05,module=0x10000000
L"msi9e12.tmp",reason=THREAD_ATTACH,res=(nil)) 
...
0015:Call KERNEL32.LoadLibraryW(001d3e3c
L"C:\\users\\focht\\Temp\\msi9e12.tmp") ret=73a56f36
0015:Ret  KERNEL32.LoadLibraryW() retval=10000000 ret=73a56f36 
...
0015:Call KERNEL32.GetProcAddress(10000000,001d3d70 "NeroAg_Init") ret=73a56fd7
0015:Ret  KERNEL32.GetProcAddress() retval=10010770 ret=73a56fd7
0015:Call ntdll.RtlFreeHeap(00110000,00000000,001d3d70) ret=73a55777
0015:Ret  ntdll.RtlFreeHeap() retval=00000001 ret=73a55777
0015:trace:msi:alloc_msi_remote_handle 0x1d3e88 -> 2
0015:trace:msi:ACTION_CallDllFunction calling L"NeroAg_Init" 
...
0015:Call KERNEL32.FreeLibrary(10000000) ret=73a5725d
0015:Ret  KERNEL32.FreeLibrary() retval=00000001 ret=73a5725d 
...
0015:trace:msi:DllThread custom action (15) returned 1603 
...
--- snip ---

The mapping from main msi thread (44) keeps the reference count and prevents
the dll from being completely unloaded when the custom action/thread ends.

Code:
http://source.winehq.org/git/wine.git/blob/5ca2277cc5ee5722de1b62c051890c8db950bacf:/dlls/msi/custom.c#l207

Binary resource unloading happens as part of package cleanup
(free_package_structures).
I'm not sure why this module reference is needed here and kept until the very
last end...
Maybe it could be done without this "outside" reference...
Temp binary resource deletion of course still as part of package cleanup.

A remote custom action server might solve this problem too (bug 18070).

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.