Welcome to MSDN Blogs Sign in | Join | Help

Link to information about MSI script-based custom action error codes 2738 and 2739

Heath Stewart posted an item on his blog this past week that I wanted to raise awareness about.  In the post, located at http://blogs.msdn.com/heaths/archive/2007/05/31/windows-installer-errors-2738-and-2739-with-script-custom-actions.aspx, Heath described some potential issues and workarounds for script-based custom action failures in MSI-based setups.

These error codes appear in an MSI log file when a script-based custom action fails to run correctly, and the error messages look like the following:

  • 2738, Could not access VBScript run time for custom action [2].
  • 2739, Could not access JScript run time for custom action [2].

A common resolution for this type of error is to re-register the file %windir%\system32\vbscript.dll and/or %windir%\system32\jscript.dll.  However, on Windows Vista this can present problems because if you attempt to re-register these DLLs from a normal user cmd prompt, the registration will be written to HKEY_CURRENT_USER instead of HKEY_CURRENT_MACHINE.

A key point Heath makes in his blog post that I was not aware of before reading it is that Windows Installer will not load and use scripting engines if they are registered in HKEY_CURRENT_USER (for security reasons that he described in more detail in his post).  Therefore, if you have registered the DLLs on Windows Vista from a normal user cmd prompt, that will not help fix this type of error.

If you have these scripting engines registered under HKEY_CURRENT_USER, you need to make sure that you remove that registration and re-register them under HKEY_LOCAL_MACHINE.  You can use the following steps to unregister them from HKEY_CURRENT_USER:

  1. Click on the Start menu, choose Run, type cmd and click OK
  2. To unregister the VBScript engine, run this command:  reg delete "HKCU\SOFTWARE\Classes\CLSID\{B54F3741-5B07-11CF-A4B0-00AA004A55E8}" /f
  3. To unregister the JScript engine, run this command: reg delete "HKCU\SOFTWARE\Classes\CLSID\{F414C260-6AC0-11CF-B6D1-00AA00BBBB58}" /f

One last note - if you are a setup developer reading this post, I encourage you to read this post by Rob Mensching where he explains reasons why using script-based custom actions in an MSI can lead to bad results and should be avoided if at all possible.

Published Thursday, June 07, 2007 5:55 PM by astebner

Comments

Friday, June 08, 2007 2:35 AM by Joy of Setup » When VBScript and JScript custom actions aren't utterly evil

# Joy of Setup » When VBScript and JScript custom actions aren't utterly evil

PingBack from http://www.joyofsetup.com/2007/06/07/when-vbscript-and-jscript-custom-actions-arent-utterly-evil/

Saturday, June 09, 2007 12:12 PM by Jason Haley

# Interesting Finds: June 9, 2007

Wednesday, September 19, 2007 11:50 AM by spoiledsport

# Why doesn't MSI takes care of this automatically?

This is one the things that should have been taken care of by the instaler already. The instaler team has enhanced MSI for some while, but has not taken care of fixing some of the basic functionality of the product. I have submitted change request after change request for fixes to this since the beginning. Everytime I see posting referring to "this post by Rob Mensching", I completly freak out.  

This is total rubbish. All of his assumption are total bull. IMHO

1.- Robust code is difficult write in script.

This is utterly nonsense, bad code can be writing in any language, but specially C. If the developer of the custom action written in script can not do a simple try{}catch() on his code, changing to C would not make it any better.

2.  Debugging script in the Windows Installer is difficult

Another stupid instaler team mistake and another request of mine. Has anyone on that team heard of "Active Scripting Host debug". Microsoft for some while sold us the idea of scripting debugging, I built several of them. doesn't that team care what their customer want?

3.  Anti-virus products kill them

My anti-virus kills any new code I put in my machine. Many ways exist of fixing this, but the main one is: Just execute the stupid script, do not put it in the file system, get it directly from the binary table and execute it, simple isn't it?

4.- Make sure jscript.dll and vbscript.dll are correctly registered.

So many things that are supposedly part of the base system (ie, media player, etc). Aren't those part of the system too since they are required by and used by the former apps? Shouldn't the system (MSI, etc) make sure they are in the correct state before executing an action which requires it?

This is just the tip of the iceberg. I honestly think that script should be the ONLY allowable way of writing custom action, since they provide sort of a sandbox model to protect the end user from ill-intented code from the part of the producer of the MSI and for the most part (i could say allways) they provide all the functionality you may possible need, besides the fact that script is so easy to write and debug (with the right support, of course)

I will send another set of emails to the Windows Installer Wishes mailto:msiwish@microsoft.com asking for some fixes for the upcoming 4.5 release. Let's hope someone is actually listening............

Tuesday, April 01, 2008 8:59 PM by Aaron Stebner's WebLog

# How I resolved Windows Installer error code 2738 on Vista while running light.exe from WiX v3.0

Recently, while attempting to build a Japanese MSI using WiX v3.0 , I received an error message that

Anonymous comments are disabled
 
Page view tracker