Aaron Stebner's WebLog

Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio

Help me help you if you have setup bugs

Help me help you if you have setup bugs

Rate This
  • Comments 74

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:

  1. As much detail about the error message as possible, including the full text of any error messages.
  2. Any troubleshooting steps that you have already tried, including links to any of my other blog posts that you've already tried.
  3. Most importantly - log files from the setup if at all possible.  You can zip and upload log files to a file server of your choice and include a link to the log files when you contact me.  My preference is http://skydrive.live.com because it is free, gives you a lot of storage space, and doesn't contain annoying ads to try to get you to pay for "premium" services like faster download speeds.

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.

  1. If you are running Windows XP or older:  Click on the Start menu, choose Run, type cmd and click OK
  2. If you are running Windows Vista or newer:  Click on the Start menu, choose All Programs, then Accessories, then right-click on the item named Command prompt and choose Run as administrator
  3. Copy this command into the cmd prompt and press enter to run it:  reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer" /v Debug /t REG_DWORD /d 7 /f 
  4. Copy this command into the cmd prompt and press enter to run it:  reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer" /v Logging /t REG_SZ /d voicewarmupx! /f
  5. Re-run the setup and let it fail one more time
  6. Go to your temporary folder (go to the Start menu, choose Run, and type %temp%)
  7. Locate a file named msi*.log (where * is a randomly generated set of letters and numbers)
  8. Zip the msi*.log file (because it tends to be very large but since it is text it compresses nicely)
  9. Run this command in the cmd prompt:  reg delete "HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer" /v Debug /f
  10. Run this command in the cmd prompt:  reg delete "HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer" /v Logging /f
  11. Upload the zipped log files to a file server such as http://skydrive.live.com

<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,

    Mike

  • 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

    thread 3720

    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.

  • Hi 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.

Page 5 of 5 (74 items) 12345
Leave a Comment
  • Please add 5 and 4 and type the answer here:
  • Post