Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio
All postings are provided AS IS
with no warranties, and confer no rights. Additionally, views expressed
herein are my own and not those of my employer, Microsoft.
There is a trick I use very often when trying to figure out why an MSI-based setup is failing that I wanted to share with everyone. I believe it is commonly known among setup developers and people who have to troubleshoot failed setups, but I could not find any "official" documentation for it. This trick helps narrow down the root cause of error code 1603, which is a generic catch-all error code that means "fatal error during installation". The 1603 error code is returned when any action fails during an installation, and most commonly it indicates that one of the custom actions in the MSI failed.
When I encounter a failed setup with return code 1603, here are the steps that I follow:
I find that the biggest hurdle to debugging a failed setup is often zeroing in on which part of the setup is actually failing, and this trick of searching for "return value 3" ends up helping speed this process up in nearly all cases. Of course, it does not work in 100% of scenarios. Notably, if you are running setup on a non-English version of Windows, the string "return value 3" is written to the log file in the language of the operating system instead of in English, so string searches will not work.
Also note that there is an MSI verbose log parsing tool in the Windows Installer PSDK that is also very useful in locating errors inside verbose log files. You can read more about this parsing tool (called wilogutl.exe) by clicking here. This tool is more thorough in identifying errors, but most often I end up not using it because it is faster to open the log in notepad and do a string search than it is to load up the parsing tool, browse to the log file, wait for it to parse the whole log and then read the output it produces.
<update date="1/21/2009"> Added a caveat to these instructions indicating that some setups create their own verbose logs and enabling verbose logging using the Windows Installer logging registry keys will not work as expected for those setups. </update>
Hi Lech - You might also want to post a question on the Visual Studio installation forum at social.msdn.microsoft.com/.../threads to see if someone there has some additional suggestions for you to try.
I'm not aware of any hidden switches to cause VS setup to bypass this component. If it is a registry permission issue though, I am afraid the same type of issue might affect other MSIs that you try to install on this computer.
I have problems installing .NET and any MSI files on Windows 2003 SP2 x64. I've created verbose logs (skydrive.live.com/redir.aspx) but can't seem to find the cause.
Thank you and best regards,
Hi Gasper - I took a look at your log files, and it looks like Windows Installer is crashing when it tries to start .NET Framework setup:
MSI (s) (BC:7C) [13:48:05:406]: Internal Exception during install operation: 0xc0000005 at 0x000006427EE83C3F.
I'm not sure if this problem is specific to the .NET Framework or if it is a general problem with Windows Installer. Do you see errors installing other types of MSIs on this machine?
It might help to try to repair/re-install Windows Installer 4.5 on your computer to see if that helps resolve this issue.
Indeed it looks like a problem with Windows Installer 4.5. I've reinstalled Windows Installer 4.5 but it does not seem to work so I'll try to find a solution to repair it.
Thank you very much, now I know in where exactly is my problem.
I'm trying to install 2007 Microsoft Office Suite Service Pack 3 (SP3)...
The installation crashes and in the event log, I find this error 1603.
I have then activated the verbose logging and started the installation again.
The installation has created multiple msi*.log files, but unfortunately, I can't find the return value 3. The operating system and Microsoft Office are both installed in English.
In one of this msi*.log files, I can find the following error message:
DEBUG: Error 2749: Transform 90001F040C000012.0.6213.1000 invalid for package C:\WINDOWS\Installer\7110c.msi. Expected product version == 12.0.6213.1000, found product version 12.0.6425.1000.
1: 2749 2: 90001F040C000012.0.6213.1000 3: C:\WINDOWS\Installer\7110c.msi 4: 12.0.6213.1000 5: 12.0.6425.1000
MSI (c) (80:34) [11:05:43:339]: Skipping validation for patch transform #90001F040C000012.0.6213.1000. Will not apply because previous transform was invalid
Do you have a hint for me, where I can look for the error?
A further problem is, that after each try to install the service pack, around 1GB disk space is used and I can't find where this space ist used.
Thanks a lot for your help!
Hi Rolf - Office setup creates its own verbose logs, and that means you won't see verbose log information for this installer in msi*.log. I'd suggest taking a look at the article at technet.microsoft.com/.../cc179058(v=office.12).aspx to see if it helps you find the relevant log files for this failure. If you'd like, you can zip up your log files, upload them to a file server (such as http://skydrive.live.com), and reply back here and post a link that I can use to download your logs and take a closer look.
Did you get the log files?
I just ask, because I don't see my last message in the forum :-)
Thanks and best regards
If you didn't get the log files, here again the link:
very helpfull, showed me that i had a problem with credentials on sql server during update of WSUS with KB2734608
Thanks for the help located value 3 and stright away saw the issue many thanks
Thanks much!!! The 'return value 3' made my day! I'll add this to my troubleshooting arsenal! Again, thanks!
Thanks for share...........
More info mcafee customer service
I had nightmares reading those long and ugly LOG files. With your tip I speeded up the error locating process by a factor of 1000!
Thank you again, you deserve a medall AND a bronze statue xD