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.
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:
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:
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.
<update date="7/29/2009"> Added steps to unregister the VBScript and JScript engines on 64-bit OS's. </update>
I understand that your product has not to be installed due to this key but it's not possible to find before what is the application create this key (install or using) and solve it ?
Hi Gilles - I'm not sure I understand your question. Are you asking about what is causing those keys to be created in the first place? If so, there isn't one single root cause for that. Someone could be incorrectly registering the DLLs, or it could be a badly behaving setup program or something like that.
tried re registering vb and jscrips . . . didnt work
deleted the 2 reg commands in W7 x64 and VOALLA . .
Thanks for the post . . really helped me out
Thanks, this article was very helpful.
Had this problem installing CorelDraw 12 on Win7 64bit. Applied the 64-bit commands and it now installs properly. Thanks for the info!
My problem is that i keep getting this error 2738, Could not access VBScript run time for custom action each time i try to uninstall a blackberry 9630 update and or install a srs HD audio lab software. I use a lenovo pc vista 32 bit.
Hi Michael - Did you try the steps listed in this blog post to see if they help resolve this error? If you already tried those steps and they didn't help, then you may need to contact the manufacturer of the software that you're trying to install and see if they know of any other workarounds to try.
Deleting the registry keys worked for me. Thanks.
I TRIED UNREGISTERING THE VBSCRIPT ENGINE BY CMD...BUT IT IS NOT HAPPENING...IT SAYS- The system was unable to find the specified registry key or value.
Hi Shubham - If you tried the commands and they reported that the registry keys are not found, then that likely means that the problem you're facing isn't the same one described in this blog post. What version of Windows are you using, and what is the exact error you're seeing?
This is what fixed my problem.. just run Microsoft Fix it to reset VBScript security settings
You will also get this error if you are running the WiX build on a TFS Build Server and the Service Account under which the build process is running is not in the Local Administrators group on the machine. After adding the Build Service Account to the Local Administrators group on the build server, make sure to restart the Build Service.
I can only assume that the Windows Installer service somehow limits access to account which are Local Administrators.
Thanks Art, very pleased I read *all* the comments.