Another error 1721 question
Here's another situation where the WiseDll.DLL is getting lost, but it's a bit different than Question about error 1721 so I'm hoping someone might have cleverer ideas than me.
Here's the error from the log:
Action start 15:34:59: DN_WS_CheckFileVersReboot.F24CDE6F_EC9B_46B0_90B4_4C3A38E8D18E.
MSI (s) (44:68) [15:34:59:313]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSIF.tmp, Entrypoint: g0
Info 2835.The control ErrorIcon was not found on dialog SetupError.
Error 1721.There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor. Action: , location: WiseCustomCall, command: g0
The MSI in question installs just fine on a clean system -- the failure only occurs when the MSI is being installed as an upgrade to an earlier version.
The reply to the question above points to KB Article 1723 but in this case the WiseDll.DLL (version 7.3.0.250 - the same version as in my WIS 7) is correctly in the package, and in fact IS PRESENT as C:\Windows\Installer\MSIF.tmp when the error dialog is displayed. (And looks ok internally, using Depends.exe!)
There's a possible wrinkle in that the failing custom action is from my WIS-created merge module, but the final MSI has been made by (cough, not me) InstallShield. I don't see why that would make any difference though -- I can image IS stripping out WIS dlls, but the dll isn't missing.
Is this something that Wise should be asked (paid) look into?
I guess the alternative would be to write our own DLL, instead of using WiseScript.
ANY hints, clues or suggestions will be much appreciated.
Comments
What is the CA supposed to be doing when it fails? Any hits in filemon or regmon when it fails?
Also, which operating system are you testing on?
If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.
The CA is supposed to run a bit of WiseScript that compares the version of an installed file with the version of a file in the package (to determine if a reboot will be needed.) It's between InstallInitialize and AllocateRegistrySPace, as immediate CA type 1.
I haven't looked at reg or file hits -- maybe I'd better go do that.
Fwiw here's the WiseScript
Get Windows Installer Property DN_INSTALLED_FILE_NAME into IFileName
Get System Information into IFILEVER
Set Windows Installer Property DN_INSTALLED_FILE_VERSION to %IFILEVER%
Get Windows Installer Property DN_PACKAGE_FILE_VER into MFILEVER
Rem split up versions into MAX, MIN and REV, dropping BLD
Parse String "%IFILEVER%" into IVERMAX and IVERREST
Parse String "%IVERREST%" into IVERMIN and IVERREST
Parse String "%IVERREST%" into IVERREV and IVERBLD
Parse String "%MFILEVER%" into MVERMAX and MVERREST
Parse String "%MVERREST%" into MVERMIN and MVERREST
Parse String "%MVERREST%" into MVERREV and MVERBLD
Rem show inst and pkg versions: maxs, mins & revs
Rem if installed ver is HIGHER than pkg ver then msiexec will not overwrite it
Rem and if equal then no problem either
Rem so reboot only rqd if iver is LESS than mver
If IVERMAX Less Than "%MVERMAX%" then
Display Message "DNWS IMax LT MMax"
Set Windows Installer Property DN_FILEVER_MISMATCH to 1
ElseIf IVERMAX Equals "%MVERMAX%" then
If IVERMIN Less Than "%MVERMIN%" then
Set Windows Installer Property DN_FILEVER_MISMATCH to 1
ElseIf IVERMIN Equals "%MVERMIN%" then
If IVERREV Less Than "%MVERREV%" then
Set Windows Installer Property DN_FILEVER_MISMATCH to 1
End
End
End
Rem DN_FILEVER_MISMATCH is used as condition for VBS CA setting RebootAtEnd
Tested on XP and on WinServer 2003 -- happens on both.
Is the CA running in system context or user context?
If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.
User context (in the CA table, Type = 1) (I think immediate CAs can only be run as user?)
Can you try it in deferred, as a system context CA ?
If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.
Run deferred in system context (type 3073) it fails the same way :-(
(Slow response from me due to sev 1 BSOD on my plate today)
The wisescript gets the version of an existing file on the target machine, gets a couple of properties from the MSI, compares values, and sets a property in the MSI (hence is run immediate, for access to properties.)
I couldn't spot anything in the regmon/filemon logs that looked wrong. The logs are huge, though, so I might have missed something -- is there anything you'd suggest to keep an eye for? The write of the DLL as a tmp file was OK.
Use Process Monitor (ProcMon) instead.
Action start 15:34:59: DN_WS_CheckFileVersReboot.F24CDE6F_EC9B_46B0_90B4_4C3A38E8D18E.
MSI (s) (44:68) [15:34:59:313]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSIF.tmp, Entrypoint: g0
After "DN_WS_CheckFileVersReboot.F24CDE6F_EC9B_46B0_90B4_4C3A38E8D18E" action has failed do a search for (in the above case) "C:\WINDOWS\Installer\MSIF.tmp" in ProcMon. There will be a lot of writefile operations as the custom action binary is first extracted and when you find the load image operation the CA binary (MSIF.tmp) performs its "magic".
You could then filter on either the TID (thread id) or something else that will minimize the ProcMon output.
For the record I gave up on using WiseScript for this and wrote a C++ dll to do the file version check instead. That's working for the customer now.
Thanks all for the help.
Any chance of a peek at your C++ source code?
If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.
OK. (There may be a better way to show code in the forum but I've put it in quotes so the html doesn't break the post.) It's embarrassing to expose my coding but here's the relevant part:
Thanks.
The most reliable way to submit code is to ZIP it first then upload and attach to your posting.
If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.
Would you like to reply?
Login or Register to post your comment.