I'm using a Visual Studio Deployment project in VS2010 to install/upgrade my application, and on Windows 2003 and older it seems like it refuses to stop the service before attempting the upgrade. As a result, it requires a reboot after the installation finishes. Here's a snip from the msiexec log where I have program.exe running under the old service and I'm trying to install program.exe as part of the upgrade:
MSI (s) (70:64) [12:00:34:448]: Note: 1: 2727 2:
MSI (s) (70:64) [12:00:34:682]: 1 application(s) had been reported to have files in use.
Info 1603. The file C:\Program Files\company\program.exe is being held in use by the following process: Name: program, Id: 712, Window Title: '(not determined yet)'. Close that application and retry.
MSI (c) (60:BC) [12:00:34:682]: File In Use: -program- Window could not be found. Process ID: 712
MSI (c) (60:BC) [12:00:34:682]: No window with title could be found for FilesInUse
MSI (s) (70:64) [12:00:34:682]: Note: 1: 2727 2:
MSI (s) (70:64) [12:00:34:682]: Doing action: InstallInitialize
Action ended 12:00:34: InstallValidate. Return value 1.
On reboot the software appears to be installed but the files that were in use previously were not re-installed, and the service has not been installed. The shortcut I drop on the Desktop acts as an advertised shortcut - double-clicking it will force MSI to see that the installation is incomplete and it repairs successfully.
BUT, some users may be doing this upgrade without logging back in (to a web server for instance), and I'd like to either:
Complete the installation without requiring a reboot, or
Reboot and complete the installation automatically prior to user login.
Here's what I've tried:
Running msiexec /i <pkg.msi> /norestart - this doesn't help, and if I try to use the shortcut prior to restarting, it attempts to repair the install and fails.
Disabling advertised shortcuts by setting the property DISABLEADVTSHORTCUTS=1 - this doesn't work either, because then the target opens but the install still isn't complete so it won't run properly. The msiexec /f <pkg.msi> can still be used to repair the install.
Adding a RunOnce key to the registry at HKLM\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce to invoke the repair operation to finish the install - this didn't seem to run, but it worked if I ran it at the command line so I'm not sure what the issue is here. The value of the string I added to RunServicesOnce using the installer is [SystemFolder]\msiexec.exe /f [ProductCode] /qn, which seems to evaluate correctly to C:\Windows\system32\msiexec.exe /f {my code} /qn.
Editing the .msi with Orca to stop the service (via the ServiceControl table) so that the file is not in use - this doesn't work because it doesn't seem to stop the service until after it has evaluated whether or not the file is held.
I think I'm lost and I hope I'm missing something obvious. Set me straight. Thanks in advance!
Related
I have an msi project created using installshield. This works good when installed using GUI window. But when I am going through silent installation, I am getting an error with a CustomAction that I have created, which will simply generate a log file. Since it is working correctly during GUI installation I feel pretty sure, the CustomAction is not an issue.
Command I have used for silent installation
msiexec /i "Setup.msi" /qn /l*v C:\msilog.txt
Is there something that I must do to suppress the next buttons in the GUI mode during silent installation?
I currently have an application out in the field that was distributed as a .msi installer (Built with Wix). I've just finished porting this application over to Electron to take advantage of all of the latest and greatest features including using Electron Builder and Auto Updates.
Any wix/msi gurus know the best way I could uninstall the old msi and run the new installer? The solutions I have found involve searching through the Windows Registry to find the msi UUID then using msiexec.
Is it possible to just create a new version of the .msi that cleans up everything?
If I understand correctly you want to migrate from MSI to NSIS format?
There is an article on this here:
https://nsis.sourceforge.io/Uninstalling_a_previous_MSI.
I would suggest, however, that you find the product code for the MSI and invoke msiexec.exe with the product code and your own uninstall string (not the one gotten from the registry as shown in the above documentation). This way you can add a few constructs to prevent spontaneous reboot and to enforce proper silent running. This approach is described below.
Uninstall MSI: You can uninstall the previous MSI version by running an uninstall command in any number of ways: Uninstalling an MSI file from the command line without using msiexec.
Find Product Code: You can find the product GUID of the MSI as follows: How can I find the product GUID of an installed MSI setup?
Command Line: Combining approach 3.5 from first link above and the product code found using the information in the second link, you can use a command line like this to invoke from your NSIS installer:
msiexec.exe /x {11111111-1111-1111-1111-11111111111X} /QN /L*V "C:\msilog.log" REBOOT=ReallySuppress
Quick Parameter Explanation:
/X = run uninstall sequence
{11111111-1111-1111-1111-11111111111X} = product guid of app to uninstall
/QN = run completely silently
/L*V "C:\msilog.log"= verbose logging at path specified
REBOOT=ReallySuppress = prevent unexpected reboot of computer
ExecWait: NSIS requires its own peculiar command format: Running MSIEXEC in a NSIS script with installer switches. Haven't tested this yet, but a suggestion:
StrCpy $R0 "{11111111-1111-1111-1111-11111111111X}"; the MSI's ProductID of my package
ExecWait '"msiexec.exe" /x $R0 /QN REBOOT=ReallySuppress'
Check here for fine-tuning the command line: https://nsis.sourceforge.io/Uninstalling_a_previous_MSI.
Links:
https://nsis.sourceforge.io/Uninstalling_a_previous_MSI
https://nsis.sourceforge.io/Auto-uninstall_old_before_installing_new
How do I require user to uninstall previous version with NSIS
https://nsis.sourceforge.io/Removing_MSI_packages_with_MSI_related_functions
I am trying to install the Visual Studio 2015 Update 3, but I am receiving an error each time. I have tried both the web installer and the ISO, and I have also tried going into Control Panel/Programs and modifying the 2015 install. All of these result in the same error: "Setup Engine - The parameter is incorrect". I've read about some of the other issues with the installer, but I'm hoping somebody else might have seen this one or something similar. The logs always have the following error in them:
[1B10:1DA0][2016-07-18T11:39:28]e000: Error 0x80070057: Failed to convert version: to DWORD64 for ProductCode: {284FA9A0-CEDD-81D3-5A19-5858E95FD0C4}
[1B10:1DA0][2016-07-18T11:39:28]e151: Detect failed for package: Win10_Universal_CRT_SDK_Extension_SDK, error: 0x80070057
I have even tried to download the full installer for VS2015, but all installers seem to run through the same error. Any ideas on how I might repair this particular component so the installs will succeed?
Additional information, this is happening on a VM of Windows 10 running in Parallels 11.
Screen shot of installer failing
I found a similar issue hereļ¼ https://connect.microsoft.com/VisualStudio/feedback/details/974081/visual-studio-update-3-installation-keeps-failing-error-message-setup-engine-the-parameter-is-incorrect
The reply from Heath[MSFT]:
The logs confirm that some of your Windows Installer product
registration is corrupt. For the first issue, open a command prompt
(preferably elevated to avoid multiple UAC prompts later) and run the
following:
start /wait msiexec /fomus {284FA9A0-CEDD-81D3-5A19-5858E95FD0C4} REINSTALL=ALL
That should get
you past the first problem. If it does not, manually remove the
product like so and re-install it from the package cache:
start /wait msiexec /x {284FA9A0-CEDD-81D3-5A19-5858E95FD0C4} IGNOREDEPENDENCIES=ALL
start /wait msiexec /i "C:\ProgramData\Package Cache\{A79F6653-6AF1-4AF2-BC15-F5D6C05E1E6A}v2.0.40326.0\packages\sptoolsDependencies\enu\WorkflowManagerTools_x64.msi" ADDLOCAL=ALL NOVSUI=1
(change the above file
WorkflowManagerTools_x64.msi according to your log file record) After
this, installing VS Update 3 should work.
I had a very similar problem which at its root exhibited the same issue identified above in the Visual Studio 2015 Update 3 setup error (I couldn't install SSMS 17.1 which uses the Visual Studio 2015 Isolated Shell). I tried the solution above which unfortunately did not work for me. I did some more digging through the vs_isoshell.exe log file and found lines similar to those below.
[6BE0:36E0][2017-07-13T13:05:36]i000: Error 0x80070057: Failed to convert version: to DWORD64 for ProductCode: {9A7E3828-17FB-3E0C-9B28-48493E01937A}
The ProductCode refers to the "Microsoft Visual C++ 15 x86 Debug Runtime - 14.10.24269".
A perusal of my installed programs showed I did not have this installed, and I was unable to install it again due to a later version being present (it turns out it was upgraded, or removed, when I installed Visual Studio 2017).
I did some more searching and came across this page which had steps I adapted to my situation. I performed the same registry profiling of the installer with Process Monitor and the same key was missing. I added a key called DisplayVersion (string - REG_SZ) to the path below with a value of 14.10.24629 and that worked.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\8283E7A9BF71C0E3B9828494E31039A7\InstallProperties]
Adding the key/value pair allowed the installation of the VS 2015 Update 3 Isolated Shell to finish successfully which in turn allowed the SSMS 17.1 installation to complete successfully.
I was installing Visual Studio-Community 2015, and I got the error (0x80070643), also known as Team Explorer Fails. The installer runs for a while, and then outputs this: (Screenshot) I have used microsoft repair tools, reinstalled the redistributables, checked the hash, (fine) and run a SFC scan, (fine). I have been searching everywhere, yet I am to have found a solution. Here is the log, (shortened, because it is massive): (Error Log)
That error code is generic in that it just means "Fatal error during installation"
You need the installation log of the particular MSI that failed.
Do you have that already? Look in your temporary directory (i.e. just type in %TEMP% in the windows explorer address bar and hit enter) for something like "dd_vs_version info_vs_teamExplorerCore.log"
If that's not there, you might be able to manually execute the MSI yourself and capture a log:
From a command prompt (ideally elevated) you could run the command:
msiexec /l*v "%TEMP%\teamexplorer.log" /i "*full installer path*packages\TeamExplorer\Core\vs_teamExplorerCore.msi" MSIFASTINSTALL="7" USING_EXUIH="1"
You need to update that command so that the path to the MSI is correct. If you've downloaded the ISO, then it will be in there; otherwise, while you're running the installer, you can probably find it under the package cache, e.g. C:\ProgramData\Package Cache{48992F68-BEE6-35D8-89AC-6A81406F1096}v14.0.24712 looking at the log.
Using a tool like Void Tools Everything will make it easy to find the MSI and logs amongst a sea of temporary folders and caches.
Brief
I have an installation package (MSI based) which attempts to register a dll file for use as a Windows Explorer Bar (Internet Explorer Toolbar).
The custom action is defined as follows:
[SystemFolder]\regsvr32.exe /s "pathtodllhere"
The error
The regsvr32 custom action does not work on Windows XP 64-bit.
Output from MSI log:
CustomAction SystemFolder_2 returned actual error code 5. Error
1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Action SystemFolder_2,
location: C:\Windows\SysWOW64\, command: regsvr32.exe /s "C:\Program
Files (x86)\Test Install\test.dll"
MSI (s) (10:F4): Product: Test Install -- Error 1722. There is a
problem with this Windows Installer package. A program run as part of
the setup did not finish as expected. Action SystemFolder_2, location:
C:\Windows\SysWOW64\, command: regsvr32.exe /s "C:\Program Files
(x86)\Test Install\test.dll"
A brief run-down of my tests/thoughts thus-far:
Custom action is in the "InstallFinalize" section, it is therefore run ONLY when the files have been dropped onto the hard drive.
Dll file is not corrupt and is valid.
Regsvr32 custom action works fine (and MSI installation) on: Windows 7 32-bit and Windows XP 32-bit.
Regsvr32 32-bit version is executed during 64-bit install (as it should).
Regsvr32 fails with error code 5, i.e. ERROR_ACCESS_DENIED.
Solutions and Musings
Self-registration - Not using regsvr32 and manually place the registry keys using my MSI Installer.
The dll is a Delphi COM dll which uses the TRegistry component to register itself. Again, I can't think of a reason why this wouldn't work as it is merely a wrapper, but just a thought.
Hopefully I have shown my research here and don't waste anyone's time!
The best practise solution (as you've alluded to) is to extract the registry entries from the component and write them to the registry using the msi.
Background
Regsvr32 requires admin rights and elevated privilege confirmation to register COM components under 64-bit Windows 7 but msiexec doesn't know to request elevated privileges for the custom action.
You can test this requirement by using "Open with..." to run C:\Windows\SysWOW64\regsvr32.exe on the component (which will fail). Whereas if you create a batch file for the registration and then "Run as Administrator" the component will register successfully.