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.
I've gotten some email questions from customers about setup failures that they've seen on their computers. Some of them are 1935 errors that match some of the previous blog posts I've written, some are .NET Framework errors, and some are general problems getting some program installed.
I cannot guarantee that I will be able to help solve all setup-related problems you may encounter, but I can guarantee that I will take a look and try to help if I can. In order to do so I would like to ask that you try to gather some detailed information and send it to me if you contact me via email to aid in troubleshooting and debugging:
Most setups are Windows Installer MSIs. For those products, you can enable verbose logging by setting a couple of registry values and then reproducing the problem. Here are a set of steps you can use to gather a Windows Installer verbose log file:
Important note - some MSI-based setups, including the .NET Framework 2.0, 3.0, 3.5 and higher, will not create log files named %temp%\msi*.log even if using the instructions listed below. Please see this blog post for more details about why that is the case and also for a list of some products that I know of that use different log file creation logic and the locations of the log files that they create.
<update date="3/27/2007"> Changed steps to enable/disable verbose logging to not require downloading .reg files from my file server </update>
<update date="2/27/2008"> Added a link to a new blog post with information about some products that create their own verbose log files and therefore do not create %temp%\msi*.log, even when the verbose logging policy is enabled on the system. </update>
<update date="12/2/2010"> Added information about uploading log files to http://skydrive.live.com. </update>
<update date="11/17/2011"> Added clarifications to steps 2 and 3 to indicate that the commands need to be run separately, not as a single command. Also added a note about running as administrator on Windows Vista or later. </update>
Hi MikeMio - Yes, I'd suggest trying to download and run the System Update Readiness Tool as a next step here. In some cases, that tool will be able to automatically fix this type of issue. In other cases, it will report the root cause of the problem but may not be able to fix it, and you may need to try to manually fix things by using the log file that this tool creates (located at %windir%\logs\cbs\checksur.log).
As far as I know, Windows Update will not automatically offer the System Update Readiness Tool if it detects a problem that requires it, so it will have to be downloaded manually. In fact, some of the cases I've seen where this tool is needed can cause Windows Update to not offer any updates at all on a system.
Step 3 in the blog post at http://blogs.msdn.com/astebner/archive/2009/01/09/9303167.aspx describes some steps I've used in the past to manually find and fix errors reported by the System Update Readiness Tool, so hopefully this might be helpful to you as well.
Hi Aaron - I posted this a few days ago but it's not showing up so I am trying again - no need to post it twice of course.
Mike
----------------------------
Hey Aaron, Success!!!
The system readiness tool appears to have done the job. After running it, the installation worked correctly.
To recap the problem:
After running the installation, this error appears:
An error occurred during the installation of assembly
'policy.8.0 Microsoft.VC80.MFC,type="win32-policy",version="8.0.50727.4053" ,publicKey
Token="1fc8b3b9a1e18e3b" ,processorArchitecture="x86" . Please refer to Help and Support for more information.
Checking the installation log and the corresponding section of the cbs log we see that the assembly failure returned an HRESULT of 0x8007371B.
The 0x8007371B result is on the list of errors the System Update Readiness Tool can potentially address so we run the readiness tool.
It finds and corrects some problems and the installation work now.
Very simple once you know how;)
Just for your information, I don’t know if this is typical but the readiness tools found a fixed a *lot* of problems. It apparently failed to replace some 3,630 missing Payload Files
This is the System Update Readiness Tool Summary:
Seconds executed: 25272
Found 117971 errors
Fixed 114337 errors
CSI Missing Component Key Total count: 19270
Fixed: CSI Missing Component Key. Total count: 19270
CSI Missing Pinned Component Key Total count: 6084
Fixed: CSI Missing Pinned Component Key. Total count: 6084
CSI Missing Identity Total count: 25354
Fixed: CSI Missing Identity. Total count: 25354
CSI Missing C Mark Total count: 30413
Fixed: CSI Missing C Mark. Total count: 30413
CSI Payload File Missing Total count: 5192
Fixed: CSI Payload File Missing. Total count: 1562
CSI F Mark Missing Total count: 37175
Fixed: CSI F Mark Missing. Total count: 37175
CBS Watchlist Component Missing Total count: 4
CSI Store Directory Missing Total count: 563
Fixed: CSI Store Directory Missing. Total count: 563
Also, you had said: “As far as I know, Windows Update will not automatically offer the System Update Readiness Tool if it detects a problem that requires it.
The reason I thought otherwise is a statement on the ‘Description of the System Update Readiness Tool’ page which said “You do not have to manually run this tool. This tool is offered automatically through Windows Update to computers that have a condition that the tool could resolve”. I may be misunderstanding that. In any case, for the above scenario it was not offered automatically.
So… thanks once again for your generous help with this. I really appreciate it. I may never have solved it this problem without it.
Cheers,
We have a program installer made using Wix 3.0 and have recently run into an error on one particular end user's computer, where the install fails when trying to run a MS run time library merge module custom action (SxSInstallCA).
The merge modules we include are:
"microsoft_vc90_crt_x86.msm"
"microsoft_vc90_mfc_x86.msm"
"policy_9_0_Microsoft_VC90_CRT_x86.msm"
"policy_9_0_Microsoft_VC90_MFC_x86.msm"
The funny thing is that this end users computer and install has successfully run other installers which included these merge modules as well.
An excerpt of the verbose log output just before and up to the first "return value 3" is as below.
I have hunted around and haven't been able to find any clues on how to debug the issue further from here. Any assistance you can provide would be greatly appreciated.
-----------start of log excerpt --------------
...
MSI (s) (2C:88) [13:02:29:500]: Doing action: InstallInitialize
MSI (s) (2C:88) [13:02:29:500]: Note: 1: 2205 2: 3: ActionText
Action 13:02:29: InstallInitialize.
Action start 13:02:29: InstallInitialize.
MSI (s) (2C:88) [13:02:29:500]: Machine policy value 'AlwaysInstallElevated'
is 0
MSI (s) (2C:88) [13:02:29:500]: User policy value 'AlwaysInstallElevated' is 0
MSI (s) (2C:88) [13:02:29:500]: BeginTransaction: Locking Server
MSI (s) (2C:88) [13:02:29:500]: Machine policy value
'LimitSystemRestoreCheckpointing' is 0
MSI (s) (2C:88) [13:02:29:500]: Note: 1: 1715 2: CCU 2.4.2
MSI (s) (2C:88) [13:02:29:500]: Note: 1: 2205 2: 3: Error
MSI (s) (2C:88) [13:02:29:500]: Note: 1: 2228 2: 3: Error 4: SELECT
`Message` FROM `Error` WHERE `Error` = 1715
MSI (s) (2C:88) [13:02:29:500]: Calling SRSetRestorePoint API.
dwRestorePtType: 0, dwEventType: 102, llSequenceNumber: 0, szDescription:
"Installed CCU 2.4.2".
MSI (s) (2C:88) [13:02:33:593]: The call to SRSetRestorePoint API succeeded.
Returned status: 0, llSequenceNumber: 904.
MSI (s) (2C:88) [13:02:33:593]: Server not locked: locking for product
{E67C9725-A794-4BD2-B0EA-986AC036158B}
Action ended 13:02:33: InstallInitialize. Return value 1.
MSI (s) (2C:88) [13:02:33:640]: Doing action: SxsInstallCA
MSI (s) (2C:88) [13:02:33:640]: Note: 1: 2205 2: 3: ActionText
Action 13:02:33: SxsInstallCA.
Action start 13:02:33: SxsInstallCA.
MSI (s) (2C:88) [13:02:33:640]: Creating MSIHANDLE (14) of type 790542 for
thread 3720
MSI (s) (2C:40) [13:02:33:640]: Invoking remote custom action. DLL:
C:\WINDOWS\Installer\MSI1C.tmp, Entrypoint: CustomAction_SxsMsmInstall
MSI (s) (2C:40) [13:02:33:671]: Closing MSIHANDLE (14) of type 790542 for
Action ended 13:02:33: SxsInstallCA. Return value 3.
-----------end of log excerpt --------------
Hi Edgroc – I can’t tell from the verbose log what the problem is in this case, but since it only happens on one computer, I’m guessing there is something wrong with that computer that is causing the VC++ runtime files custom actions to fail and that this problem isn’t specific to your setup package. I would expect to see the standalone VC++ runtime redistributable to fail in the same way, so you may want to have the customer try that to double-check that. If that also fails, then they will likely need to repair their OS to try to resolve this issue. What version of Windows is this error being seen on?
Thanks for the feedback.
While your blog was undergoing "upgrades", we managed to determine that the .MSI file that the end user was running from was in fact corrupted!
This certainly explains why a previous installer with the same VC++ runtime merge modules worked fine and the one in question failed.
I thought the MSI files themselves were internally checksummed and this type of error would be caught by the installer engine, but I guess not.
when I install Python 2.7 on Windows 7 32 bit, the installation failed and I got this error
An error occurred during the installation of
assembly 'Microsoft.VC90.CRT, version="9.0.21022.8",publicKey
Token="1fc8b3b9a1e18e3b",processorArchitecture="x86",type="win32".
Please refer to Help and Support for
more information.
Hi Sarhat - For installation issues with Win32 assemblies (like the Visual C++ runtime files) on Windows 7, I suggest using the troubleshooting information and links at blogs.msdn.com/.../9904471.aspx.
Hi Aaron,
I was pointed to your post on "How to locate the cause of error code 1603 in a verbose MSI log file", and in that post it lead me to this post. I'm wondering if the registry keys and values you mention on this post, are still relevant for Windows 2008 R2 Web Servers?
Hi Rod at Work - Yes, these registry keys are applicable to any version of Windows Installer on any version of Windows. They should work fine on Windows Server 2008 R2.
Thank you, Aaron.
I am using C# dll deferred custom action in my setup and it creates below entry in msi log files and writes all properties with 'Ignoring CustomActionData substring' <>, Can you please suggest if there is a way to hide this as this contains password entry as well. Log is added below for your reference.
----------------------------------------------
MSI (s) (1C:34) [00:01:36:125]: Executing op: CustomActionSchedule(Action=cs_CreateService,ActionType=11265,Source=BinaryData,Target=**********,CustomActionData=**********)
MSI (s) (1C:CC) [00:01:36:140]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI21F3.tmp, Entrypoint: m5
InstallShield: Attempting to load through CLR 4 APIs...
InstallShield: Getting meta host...
InstallShield: Loaded CLR successfully
InstallShield: Ignoring CustomActionData substring "C:\Program Files (x86)\TEST|C:\||5|True|False|True|VM134|TEST_DB_CD16|||0|||||2012/06/12 10:29:28||||Testdomain\admin|admin123|||1|1||"
InstallShield: Deferred action requested property MsiHiddenProperties not provided by CustomActionData
InstallShield: Loading assembly DLPInstall from resource 4097
InstallShield: Calling method with parameters [(System.IntPtr)424, (System.String)TestManager]
Thanks in advance for your help & suggestion.
Manish Jain
manish1979@gmail.com
Hi Manish - The MsiHiddenProperties property is used to control whether or not to show sensitive information in the MSI log file - msdn.microsoft.com/.../aa370308.aspx. I'd suggest taking a look at that documentation to see if that will help you in this scenario.
http://sdrv.ms/134Sdm4 there is the file. please help Aaron :/
Hi Volkan - Your log looks like it is from an attempt to install the .NET Framework 1.1 on Windows 7. This is the exact error that I see in your log:
1: ERROR: Process returned non-0 value! CMDLINE: "C:\windows\system32\URTTEMP\regtlib.exe" "C:\windows\Microsoft.NET\Framework\v1.1.4322\mscorlib.tlb"
I'm not sure what the root cause is for that type of error though. It might help to try the technique described at saranspot.blogspot.com/.../installing-dotnet-framework-11-on.html.
If that doesn't help, then I'd suggest posting a question about this issue on the .NET Framework setup forum and hopefully someone there will have some additional suggestions for you to try. You can find this forum at social.msdn.microsoft.com/.../threads.