Case study: How I approach debugging and fixing a setup failure


I received a mail from a customer this week regarding an installation failure that proved to be fairly interesting.  I wanted to describe the scenario and the steps I used to approach solving this issue in the hopes that it will help others who might need to debug setup related problems and find this post.


The customer was trying to install the Microsoft Enterprise Instrumentation Framework package, but it continually failed and rolled back with error code 1720.  I had the customer send me a verbose log file from this installation using these steps, and then I used this technique to search through the vebose log file for the root cause.


The verbose log file showed this error message immediately before the setup started to roll back:



Error 1720. There is a problem with this Windows Installer package. A script required for this install to complete could not be run. Contact your support personnel or package vendor.  Custom action IsDotNetInstalled script error -2146827859, Microsoft JScript runtime error: Automation server can't create object Line 1, Column 1, MSI (c) (80:98) [13:48:47:296]: Product: Enterprise Instrumentation -- Error 1720. There is a problem with this Windows Installer package. A script required for this install to complete could not be run. Contact your support personnel or package vendor.  Custom action IsDotNetInstalled script error -2146827859, Microsoft JScript runtime error: Automation server can't create object Line 1, Column 1, 


Action ended 13:48:47: IsDotNetInstalled. Return value 3.


This error is a custom action failure for the action named IsDotNetInstalled.  Since the error code mentions a JScript runtime error, that means that the custom action is script-based, and I can extract the script from the MSI and look at the source code to try to debug further.


I used the following steps to extract the custom action script from the MSI:



  1. Download the setup package (named EnterpriseInstrumentation.exe) and save it to my local hard drive

  2. Extract the contents of the setup package by running EnterpriseInstrumentation.exe /t:c:\temp /c

  3. Right-click on c:\temp\EnterpriseInstrumentation.msi and open it in Orca

  4. Go to the CustomAction table, locate the entry for the IsDotNetInstalled action and find that the Source value is set to XrayCustomJs

  5. Go to the Binary table, locate the entry for XrayCustomJs, and double-click on the [Binary Data] entry in the Data column

  6. In the dialog that appears, enter the filename c:\temp\isdotnetinstalled.js and choose the radio button labeled Write binary to filename

  7. Press OK to extract the jscript file

The 1720 error message above stated that the error happened on line 1, column 1 and that it failed to instantiate an object.  After I finished running the above steps, I could open the file c:\temp\isdotnetinstalled.js in a text editor such as notepad to look at what appears on line 1:



var FSO = new ActiveXObject ( "Scripting.FileSystemObject" );


Based on that, it appeared to me that there was something wrong with instantiating a Scripting.FileSystemObject control on the customer's computer.  I searched for that object in the registry on one of my computers, and I found the following registration information:



[HKEY_CLASSES_ROOT\CLSID\{0D43FE01-F093-11CF-8940-00A0C9054228}\InprocServer32]
(default) = c:\windows\system32\scrrun.dll


I made an educated guess at this point that something was wrong with the registration for this DLL, so I had the customer try to run regsvr32.exe scrrun.dll to try to fix the registration for the Scripting.FileSystemObject.  Once they ran regsvr32 and it succeeded, they were able to successfully install the Enterprise Instrumentation Framework on their system.


The steps listed above are fairly specific to the problem that I was troubleshooting with the Enterprise Instrumentation Framework setup package, but hopefully the underlying approach I used to narrow down the problem and some of the tips and tricks listed above will be helpful to you for debugging other types of setup-related issues.


 

Comments (2)

  1. Pat Murphy says:

    Nice…Very Logical AND save me a lot of debugging time doing the same steps myself…Thanks!  I forgot about the old scripting runtime registering trick.

Skip to main content