http://bugs.winehq.org/show_bug.cgi?id=6189
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #22 from Anastasius Focht focht@gmx.net 2010-06-10 14:58:10 --- Hello,
there is a custom action "SetupWizard" that refers to "SOURCEDIR" property which is empty at the point the custom action is run, resulting in failure.
This property is normally not available unless the standard "ResolveSource" action has been executed.
---snip --- 0015:Ret PE DLL (proc=0x10007f67,module=0x10000000 L"msibc96.tmp",reason=PROCESS_ATTACH,res=(nil)) retval=1 0015:Ret KERNEL32.LoadLibraryW() retval=10000000 ret=6c07b7f0 ... 0015:Call KERNEL32.GetProcAddress(10000000,00e4a050 "SetupWizard") ret=6c07b8d2 0015:Ret KERNEL32.GetProcAddress() retval=10005340 ret=6c07b8d2 ... 0015:trace:msi:ACTION_CallDllFunction calling L"SetupWizard" ... --- snip ---
The installer tries to load some gui resource dll and fails in first place.
--- snip --- 0015:Call KERNEL32.LoadLibraryW(00b5e3a8 L"C:\windows\Installer\{5783F2D7-5001-0409-0002-0060B0CE6BBA}\INSTBASICUI.DLL") ret=10001013 0015:Ret KERNEL32.LoadLibraryW() retval=00000000 ret=10001013 ... --- snip ---
The path "C:\windows\Installer\{5783F2D7-5001-0409-0002-0060B0CE6BBA}\INSTBASICUI.DLL" is actually only valid on reinstall (product already installed), hence the failure is correct (5783F2D7-5001-0409-0002-0060B0CE6BBA = product code).
The installer then tries to load the resource dll from different path, using the "SOURCEDIR" property:
--- snip --- 0015:Call msi.MsiGetSourcePathW(00000002,100152b8 L"SOURCEDIR",00b5e3a8,00b5e3a4) ret=10001180 0015:trace:msi:MsiGetSourcePathW L"SOURCEDIR" 0xb5e3a8 0xb5e3a4 ... 0015:trace:msi:resolve_folder Working to resolve L"SOURCEDIR" ... 0015:trace:msi:MSI_GetSourcePath path = (null) ... 0015:Ret msi.MsiGetSourcePathW() retval=0000010b ret=10001180 ... 0015:Call KERNEL32.GetLastError() ret=1000901d 0015:Ret KERNEL32.GetLastError() retval=0000007e ret=1000901d --- snip ---
If "SOURCEDIR" property would exist at this point, the installer constructs a path like this:
"SOURCEDIR" property -> "c:\install\Autodesk\AutoCAD2007TrialInstallImage\Bin\acadFeui"
append:
"ACAD_INST_RESDLL_PATH" property -> "windows\installer"
Resulting in final path:
"c:\install\Autodesk\AutoCAD2007TrialInstallImage\Bin\acadFeui\windows\installer"
--- snip --- $ pwd /home/focht/.wine/drive_c/install/Autodesk/AutoCAD2007TrialInstallImage/Bin/acadFeui/Windows/Installer ...
$ ls -la total 596 drwxrwxr-x. 2 focht focht 4096 2010-06-10 20:10 . drwxrwxr-x. 9 focht focht 4096 2010-06-10 20:10 .. -rw-rw-r--. 1 focht focht 23656 2006-03-05 04:58 CustomRes.dll -rw-rw-r--. 1 focht focht 267880 2006-03-05 04:58 InstBasicUI.dll -rw-rw-r--. 1 focht focht 304744 2006-03-05 04:58 InstRes.dll --- snip ---
The installer would then LoadLibrary() the "INSTBASICUI.DLL" resource dll (ideally succeeding) and resolve the export "WelcomeDlg" correctly.
Due to failure to resolve the dll path it tries to resolve the export with NULL module handle resulting in custom action failure:
--- snip --- 0015:Call KERNEL32.GetProcAddress(00000000,00e4f540 "WelcomeDlg") ret=10005531 0015:Ret KERNEL32.GetProcAddress() retval=00000000 ret=10005531 ... 0015:Ret PE DLL (proc=0x10007f67,module=0x10000000 L"msibc96.tmp",reason=PROCESS_DETACH,res=(nil)) retval=1 0015:Ret KERNEL32.FreeLibrary() retval=00000001 ret=6c07b93b ... 0015:trace:msi:DllThread custom action (15) returned 1603 ... 002e:err:msi:ITERATE_Actions Execution halted, action L"SetupWizard" returned 1603 --- snip ---
As already said, the "SOURCEDIR" property is normally set using the "ResolveSource" action.
Using ORCA one can see that the "ResolveSource" standard action is only contained in "InstallExecuteSequence" table in "acad.msi":
--- snip "InstallExecuteSequence" table --- ResolveSource NOT Installed 910 --- snip "InstallExecuteSequence" table ---
Unfortunately after "CostFinalize" action the "InstallUISequence" table is populated first (UILevel > 0)
1. InstallUISequence (everything up to ExecuteAction) 2. ExecuteAction in InstallUISequence calls InstallExecuteSequence 3. after all actions in InstallExecuteSequence are done -> any action scheduled after ExecuteAction in InstallUISequence
--- snip --- 002e:trace:msi:msi_get_property returning L"5" for property L"UILevel" 002e:trace:msi:ACTION_PerformUIAction Performing action (L"MigrateFeatureStates") ... --- snip ---
"SetupWizard" (id=1200) < "ExecuteAction" (id=1300)
--- snip "InstallUISequence" table --- SetupWizard 1200 ... ExecuteAction 1300 --- snip "InstallUISequence" table ---
This post from James Hawkins also indicates that "ResolveSource" must be somehow treated specially:
http://www.winehq.org/pipermail/wine-patches/2006-October/031700.html
--- quote --- MSI installers usually have at least two install sequencing tables, InstallExecuteSequence and InstallUISequence. If the install is run at the Full UI level, then the installer executes the actions in the InstallUISequence table in order, up to the ExecuteAction sequence. At this point, the installer starts running through the actions in the InstallExecuteSequence table. On the other hand, this test shows that some actions in the InstallExecuteSequence are run before certain actions in the InstallUISequence table. I don't know if the installer has a set list of standard actions that are run in the InstallExecuteSequence before the InstallUISequence, or what, but this test at least shows that there is at least one action, ResolevSource, that is run in the InstallExecuteSequence before other actions in the InstallUISequence. --- quote ---
Regards