MSI 2738 and 2739: Could Not Access VBScript or JScript Runtime in Setup

Fix it now

Windows Installer asked COM for a script engine so it could run a custom action, and did not get one. Microsoft’s message for 2738 is that the VBScript run time could not be accessed; 2739 says the same about JScript. The engine is either shadowed by a class registration in your own user hive or not registered machine-wide.

reg query HKCU\SOFTWARE\Classes\CLSID /s /f vbscript.dll
reg query HKCU\SOFTWARE\Classes\CLSID /s /f jscript.dll
regsvr32 %windir%\System32\vbscript.dll
regsvr32 %windir%\System32\jscript.dll
%windir%\SysWOW64\regsvr32.exe %windir%\SysWOW64\vbscript.dll

1. Read the two reg query results first. Any hit means a class registration in your own hive is pointing at the engine, and that copy is used in preference to the machine-wide one.
2. Export each key it found before you touch it, then delete it: reg export "<key>" %USERPROFILE%\Desktop\clsid.reg followed by reg delete "<key>" /f. Sign out and back in.
3. Run the install again with a log and search the log for the error number: msiexec /i "C:\pkg\app.msi" /l*v "C:\pkg\install.log".

The last line covers 32-bit installers on 64-bit Windows, which resolve against the SysWOW64 copies of both the engine and regsvr32. Registering the 64-bit copy does nothing for them.

If setup now gets past the custom action you are done. If not, the next section explains how COM picks an engine and which of the five causes you are looking at.

Why it happens

A scripted custom action does not run a file. It asks COM to create a script engine by class identifier, hands it the script text, and waits. Everything before that point in the installation is unaffected, which is why the error lands mid-transaction and the whole thing rolls back looking like a damaged package.

COM resolves a class identifier through a merged view: registrations in the user’s own hive are read in preference to the machine-wide ones, so that software can register a class for one account without affecting others. That ordering is the reason this failure is so common. One stray key under your classes takes priority over a perfectly good machine registration, and if it points at a file that is missing, renamed or quarantined, the engine cannot be created. Because that key belongs to a profile, the same package usually installs without complaint under a different account on the same machine, which is the cheapest confirmation of the diagnosis you will get.

The neighbouring numbers describe adjacent failures rather than the same one. 1720 and 2740 both report a script that ran and then broke, and both carry the custom action name, the script error and a line and column – a packaging fault rather than a machine one. 2869 is not about scripting at all: Microsoft publishes it as a dialog in the package that has the error style bit set without being an error dialog.

Full reference

What Microsoft publishes for each number

The bracketed placeholders are filled in at run time, which is why a verbose log is worth more than the dialog on screen. msiexec /i package.msi /l*v log.txt writes every substituted value, so the custom action name and the script position arrive intact.

Finding the shadowing key without a GUID

Advice for this error usually opens with two class identifiers to delete. Microsoft does not publish those identifiers in its documentation, and typing a GUID from memory into reg delete is a good way to break something else. Search your own registry for the file name instead, which finds the same key and proves it is the right one:

reg query HKCU\SOFTWARE\Classes\CLSID /s /f vbscript.dll
reg query HKCU\SOFTWARE\Classes\CLSID /s /f jscript.dll
reg query HKCU\SOFTWARE\Classes\Wow6432Node\CLSID /s /f vbscript.dll
reg query HKLM\SOFTWARE\Classes\CLSID /s /f vbscript.dll

The last line is the control. It shows what the machine-wide registration looks like, which is what COM will use once the per-user key is gone. If the machine-wide entry points somewhere that is not %windir%\System32\vbscript.dll, that is the thing to fix, and re-registering with regsvr32 rewrites it.

Registering the right copy

Both architectures matter more often than people expect. A 64-bit machine running a 32-bit installer resolves the class through the 32-bit view, so a perfectly registered 64-bit engine is invisible to it. Registering both costs nothing and removes the question.

Where this is heading

Microsoft’s deprecated features list records VBScript as deprecated, announced in October 2023, and states that in future releases of Windows it will be available as a feature on demand before it is removed from the operating system. That has two practical consequences. On a machine where the component has not been added, the file genuinely is absent and no amount of re-registering will help. And if you author packages, a scripted custom action is now a dependency with an end date.

• Prefer standard actions where the installer already has one for the job.
• Where you need code, a compiled custom action has no engine to resolve and no per-user class registration to be shadowed by.
• If you must keep script actions, make them fail with a message rather than an unhandled error, so the log shows something better than a line and column number.
• Test the package under a second, freshly created account. That is where per-user shadowing shows up.

When none of the above applies

1. Check whether the install works from the built-in Administrator account. If it does, the difference is in your profile, and it is almost always a class registration.
2. Look at the log for the action immediately before the first Return value 3. That is the action that failed, and on a scripted action it will be named.
3. Confirm the engine files exist and are the size they should be, then re-register them and read what regsvr32 reports rather than assuming it worked.
4. If the machine has had a script-based infection cleaned off it, expect leftovers in the class registrations and check both the 64-bit and 32-bit views.

Every code this article covers

Confirm the fix worked

1. Run the installer again with /l*v and confirm the custom action completes instead of returning a failure.
2. Re-run the two reg query commands and confirm no per-user class registration has come back.
3. Confirm the product appears in Settings, Apps, Installed apps and starts.
4. Install a second package that uses scripted actions, so you know the engine is healthy generally rather than for one product.
5. Sign out and back in, then check once more, which rules out a profile tool recreating the key at logon.

Questions people ask about this