3

I am trying to install a Windows Service on a server and when running command line, as admin, and navigating to my InstalUtil.cmd file, and running it, I get error "msiexec failed: 1603", however the service does get installed and runs perfectly as expected. Any ideas/suggestions to fix the error message?

CRoberts
  • 286
  • 1
  • 6
  • 17
  • 1
    We need more info. Is this a visual studio setup project with Installer classes to install the service? Do you have any custom actions in your setup? 1603 is a generic failure, usually a custom action crash. So, for example, if you customized the install method in the installer class then the code can crash after the service has finished the service install. – PhilDW Jun 20 '18 at 20:11
  • @PhilDW Have just fixed the issue :) It was to do with the Custom Action not being set up correctly! – CRoberts Jun 21 '18 at 14:29
  • Great if you can let us know the exact error code from the log file. You can add your own answer to do so. – Stein Åsmul Jun 22 '18 at 14:18

2 Answers2

5

Reboot Required?: could this be a simple "reboot required issue". 1603 can mean "reboot required" in batch files.

  • Did you run the batch file with admin rights?
  • Does this MSI have any custom actions? If so, where are they located in the InstallExecuteSequence?
  • There are other possibilities (resurrected from WayBack Machine). Inlining the main section here for the future:

From link above: The following is a non-exhaustive list of known causes for this error:

  • Short file name creation is disabled on the target machine.
  • An Install Script custom action is prototyped incorrectly.
  • A file is locked and cannot be overwritten.
  • The Microsoft Windows Installer Service is not installed correctly.
  • The Windows Temp folders are full.
  • The setup was corrupted after installation and, therefore, fails with this error during un-installation.
  • An older version of Install Shield Developer is being used.
  • A general error occurred during the installation.
  • Print and File sharing is not installed or enabled when installing MSDE 2000.

Proposed solutions in linked document above: 1) Make sure short file name creation is enabled on the target machine, 2) Make sure Windows Installer is properly installed, 3) Empty all temporary folders, 4) Close all running applications and utilities, and launch the installation again - especially antivirus tools, and 5) a couple more options.

You need to gather more information - which leads to checking for logs:

Standard debugging:

  • Event Logs: What does the event logs say? (Windows + Tap R. type eventvwr and press OK). Check the different logs.

  • MSI Log File: Did you create an MSI log file?

  • There could be policies in effect to automatically create one. Check in the TMP folder, sort by date and check recent files for any *.log files.

  • Also check in the batch file if it hard codes a location for the MSI log file.

If you find an MSI log file, try searching for "value 3" (without the quotes) to find any actions that failed.

How to create an MSI log file:

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
  • Thank you for your help :) I found the error was arising due to my Custom Action not being set up correctly. I have fixed this now and the service installs with no issues. – CRoberts Jun 21 '18 at 14:31
  • Great, can we ask what you needed to change? Curiosity has killed many MSI specialists - little known fact :-). If you had an **immediate mode custom action** after **`InstallFinalize`** there might be further problems that should be resolved. – Stein Åsmul Jun 21 '18 at 14:51
  • Of course :) So I was using another pre existing project and copied over the Custom Action file, but didn't realise that CA was set up as a class library not a C# Custom Action Project. So two options were to either create a new CA project and copy over the code, or right open up the XML of the class library and add in these two lines of code `$(MSBuildExtensionsPath)\Microsoft\WiX\v3.x\Wix.CA.targets` in-between the `` tag, and `` between the `` tags. – CRoberts Jun 21 '18 at 15:03
  • 1
    Oh, managed code. Functionality I do not use. Just to mention that there are many challenges with managed code not immediately apparent (runtime dependencies, erroneous loading of runtimes, GAC issues, etc...). This is especially true for large scale distributions targeting diverse computers in many unpredictable states. Chris Painter (MSI export) uses managed code effectively, so don't take my word for it, but here is [my ad-hoc writeup of concerns with managed code custom actions](https://stackoverflow.com/a/48465731/129130). It is a messy "answer", but might be worth a skim. – Stein Åsmul Jun 21 '18 at 15:50
  • For in-house corporate deployment with predictable, standardized target computers (SOEs), you can probably successfully use managed code once you know how to avoid the worst bear traps. Those are my two cents - not necessarily the prevailing prejudice in the field. And [here is my propaganda against custom actions overall](https://stackoverflow.com/a/46179779/129130) (any type). There is widespread agreement in the field that custom actions are the leading cause of deployment failure and should be avoided whenever possible. Sorry for the speech :-). Good luck. – Stein Åsmul Jun 21 '18 at 15:52
0

While installing on windows sometimes get 1603 error because Visual C++ RunTime Library and Microsoft .Net problems.

Try reinstall Microsoft Visual studio redistributable package or uninstall original installed versions.

X zheng
  • 1,731
  • 1
  • 17
  • 25