SQL SERVER – Error Installing Microsoft Visual Studio 2010 Shell

A Visual Studio 2010 Shell error interrupted a SQL Server patch in this 2017 case. The setup screen named the component, but a package path in its log explained the failure. This is a legacy installation case, not a requirement to install that shell for modern SQL Server tools.

Follow the component log

The useful file was VC10Redist_Cpu64_1.log. It identified a package in the SQL Server 2012 setup update cache. The relevant details were:

Product: C:\Program Files\Microsoft SQL Server\110\Setup Bootstrap\Update Cache\KB3045318\GDR\redist\VisualStudioShell\VC10SP1\vc_red.msi
MSI error: 2203
System error: -2147287037
MainEngineThread is returning 3

Windows Installer error 2203 concerns opening an installer database file. The associated path and system error are needed to investigate it. A component name on the setup screen alone does not prove the shell itself is damaged.

I checked the named location and found that vc_red.msi was absent. We did not establish why it had disappeared. The original suggestion that someone removed it to save space was only a possibility, not a confirmed cause.

What resolved this particular case

We obtained the same KB3045318 update package again. Its extracted files contained vc_red.msi under VC10SP1\x64. The original fix restored that package file to the VC10SP1 location expected by the failed operation.

KB3045318 identifies a SQL Server 2012 SP1 GDR security update. That package and directory layout belong to this historical case. They are not the right repair inputs for every Visual Studio 2010 Shell error.

Match the missing package before making changes

1. Preserve Summary.txt, Detail.txt and the component log from the failed attempt.
2. Record the complete requested path, package name, product version, architecture, language and update branch.
3. Check whether the requested file is missing or inaccessible. If it exists, investigate the recorded access or system error.
4. Obtain the matching trusted installation or update package. Do not choose a different vc_red.msi because its filename looks right.
5. Follow the supported setup repair or missing-package recovery procedure for that product. Preserve the current files before any repair.

Do not delete the SQL Server Update Cache or Windows Installer cache to make room for another attempt. Those are distinct locations, and both can contain files needed for maintenance. Do not copy another computer’s complete installer cache over this one.

Verify the patch, not just the dialog

After restoring the required package through the appropriate procedure, rerun the intended maintenance operation. Check its final result and the affected SQL Server instance’s normal startup. Confirm the expected build and review any remaining component failures.

Keep the successful logs with the original failure. For a different package or newer product, investigate its own logged path first. The old folder name is evidence from this case, not a universal destination.

A familiar installer filename is not proof of a matching package, it is one detail to verify before repair.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.