Windows Installer Errors 2738 and 2739 with Script Custom Actions

Windows Installer Errors 2738 and 2739 with Script Custom Actions

  • Comments 28

Windows Script custom actions should be avoided. They are difficult to debug, get blocked by virus scanners, and are far more susceptible to machine state than native custom actions. That is indicated by Windows Installer error messages 2738 and 2739, which read:

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

As some people have found, re-registering the runtime libraries vbscript.dll and jscript.dll will fix the errors, but that isn't always the solution.

As a security measure, Windows Installer will not load script engines registered in HKEY_CURRENT_USER. As a user-writable store, a normal user could get an elevated install to run their library masking as a script engine if the custom action was not explicitly attributed with msidbCustomActionTypeNoImpersonate (0x0800). This is an elevation of privileges attack; thus, Windows Installer returns error message 2738 or 2739 for custom actions type 6 and type 5, respectively, and returns Windows error 1603, ERROR_INSTALL_FAILURE.

Check that vbscript.dll and jscript.dll aren't registered in HKEY_CURRENT_USER (HKCU), checking for the registry keys below.

  • VBScript, HKCU\SOFTWARE\Classes\CLSID\{ B54F3741-5B07-11CF-A4B0-00AA004A55E8}
  • JScript, HKCU\SOFTWARE\Classes\CLSID\{ F414C260-6AC0-11CF-B6D1-00AA00BBBB58}

Remove these keys if they exist in HKEY_CURRENT_USER.

Also be sure that if you need to re-register vbscript.dll or jscript.dll, you run regsvr32.exe in an elevated console on Windows Vista and newer with UAC enabled; otherwise, you'll end up registering the runtimes in HKCU.

Leave a Comment
  • Please add 4 and 4 and type the answer here:
  • Post
  • If you are running Vista 64 bit, you might want to run c:\windows\syswow64\regsvr32 vbscript.dll instead of system32.. :-)

  • well ive removed the key but how do i re-register them?

  • You may not need to. These should always be in HKLM. If they're not, then you should run "regsvr32 vbscript.dll" and/or "regsvr32 jscript.dll" *from an elevated console*.

  • Where do I find the reg keys at... Not computer savey.. This really helped..

  • Clara, my coworker, Aaron Stebner, has more information about how to find and remove these keys based on my post here.

    http://blogs.msdn.com/astebner/archive/2007/06/07/3151752.aspx

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

  • Mi proble es que tengo windows vista de 64 bits pero al momento de ejeuctar como administrador me sale C.windows \system32> y no C:windows \ SysWow64 > como me deberia salir ya que tengo de 64 bit.

    Ayudenme gracias de antemano.............

  • @Luis Z, assuming the machine translator worked correctly, C:\Windows\SysWOW64 is actually the location of 32-bit (loaded) files (WOW64), while C:\Windows\System32 is the location of 64-bit (loaded) files. It looks odd, yes, but is correct.

  • Hi,

    It's possible to find what is the product installing this key instead of removing it always ?

    Kr,

    Gilles

  • On a 64 bit machine the registry entrys are in HKEY_CURRENT_USER\Software\Classes\Wow6432Node\CLSID

  • @Gilles, there's no trace left of which products install it and MSI API calls to see which MSI components might install it have turned up nothing so far. If you have a live repro, you delete the key(s), use procmon, and run your typical apps to see what process is writing them.

  • I have been having this problem with an installer. The keys are not in HKCU, but are in HKLM as expected. Both the 32 bit and 64 bit versions seem to be registering ok. Still getting the error. Any other suggestions?

Page 1 of 2 (28 items) 12