Visio 2007 under W11

Received this error trying to install service pack via... vcredist_x86.exe

That indicates a failure of the Visual C++ 2005 runtime to install or register its assemblies on newer Windows builds. Visio 2007 depends on that exact runtime, and Windows 11 often blocks or breaks the old installer unless the system is prepared first.

First, try installing the correct redistributable manually. Use the Microsoft Visual C++ 2005 SP1 Redistributable (the updated one with the security fix). Install the x86 version at minimum, even on a 64-bit system. It’s often safest to install both x86 and x64. If it fails with the same 1935 error, the issue is not the installer itself but the Windows component store.

That error code tied to assembly “Microsoft.VC80.MFC” usually means the WinSxS store or .NET/installer transaction system is in a corrupted state. Fix that first, then reinstall the redistributable. Open an elevated Command Prompt and run:

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

Reboot after those complete. Then try installing the VC++ 2005 SP1 package again as administrator.

If it still fails, clear any stuck installer transaction state:

net stop msiserver
ren C:\Windows\WinSxS\Temp PendingDeletes.old
ren C:\Windows\WinSxS\Temp PendingRenames.old
net start msiserver

Reboot again and retry the redistributable install.

Once the VC++ runtime installs successfully, Visio 2007 should launch without the MSCVR80.dll error. If Visio itself still behaves oddly, run its setup again and choose Repair, or reinstall it after the runtime is in place.

Unfortunately copying the Office12 folder likely won’t work reliably because these assemblies must be registered in WinSxS - that’s what the 1935 failure prevented.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

What do you mean by "try installing the correct redistributable manually"
I've run the exe's from CMD and with /r but no joy. It prompts for me to allow vc_red_enu_a64_ixp.msi Then progress bars appear and then the 1935 error . The x64 also fails. ALSO - this is what is installed. Do we need all ?

I meant bypassing the bundled bootstrapper (the vcredist_x86.exe wrapper) and instead extracting the underlying MSI package and installing that directly with Windows Installer. Those redistributables are just containers for one or more .msi payloads plus a setup engine. In practice, that sometimes helps when the bootstrapper fails but the MSI itself is still installable.

However, in your case the relevant part is likely not MSCVR80.dll but the Windows Installer error 1935 during the VC++ 2005 installation. That error typically means Windows is failing to register a component into the WinSxS/.NET/assembly subsystem while the installer is running. On Windows 11, VC++ 2005 SP1 is particularly fragile because it relies on older .NET and assembly registration behavior that modern servicing stacks no longer handle gracefully in all cases.

One potential cause is a broken or incomplete .NET Framework 3.5 subsystem. Even if Visio itself doesn’t explicitly mention it, VC++ 2005 SP1 frequently triggers 1935 when .NET 2.0/3.5 side-by-side registration is not healthy. You might want to start by ensuring .NET 3.5 is properly enabled (not just installed, but fully provisioned from Windows Features).

Run this from an elevated command prompt:

DISM /Online /Enable-Feature /FeatureName:NetFx3 /All

After that completes, reboot before attempting anything else.

If it still fails, the next step is to repair the servicing and component store, because 1935 is often caused by corruption in the WinSxS registration system rather than the installer itself:

sfc /scannow

followed by:

DISM /Online /Cleanup-Image /RestoreHealth

Then reboot again.

If VC++ 2005 still throws 1935 after that, the installer itself is usually not the problem—the registration engine is. At that point, temporarily disabling third-party antivirus during installation can matter (not because of malware, but because older MSI custom actions can be incorrectly blocked). Also make sure the Windows Modules Installer service is running, because MSI-based installs depend on it.

After those are clean, you might want to go back to the “manual MSI” approach. If you extract vcredist_x86.exe (for example using /extract), you can locate the MSI and attempt:

msiexec /i vc_red.msi

But if your system is already producing 1935, that MSI will usually fail in exactly the same way, because the failure is happening at the Windows component registration layer, not at the bootstrapper layer.

Visio 2007 working on one Windows 11 machine but not another suggests the working machine has older runtime components already present (often inherited from older Office/VC++ stacks), which is why it “just works” there. The clean machine is exposing the missing legacy dependencies.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Thank you , Kinda makes sense. I'll try to work through these suggestions. But it's all pretty nuts that this is needed. Ho hum !! :-)