http://bugs.winehq.org/show_bug.cgi?id=10365
Anastasius Focht focht@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@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/5ca2277cc5ee5722de1b62c051890c8db...
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