If you’ve ever supported Microsoft Office deployments at scale, chances are you’ve encountered Error 1935. It’s one of those frustrating installer failures that offers no meaningful explanation, stalls at around 70–90%, and then rolls back everything as if nothing ever happened.

What makes Error 1935 particularly annoying is that:

  • It affects otherwise healthy systems
  • It appears randomly across environments
  • Microsoft’s official guidance is vague at best

I’ve personally seen this error surface during:

  • Office 2013 installs on freshly imaged Windows 10 machines
  • In-place upgrades from Windows 7 or 8.1
  • Environments where Office was removed years ago

In this guide, I’ll walk through real-world fixes that actually work, starting with the most effective solution I’ve used in enterprise environments—without resorting to OS reinstallation.

office error 1935

The Problem: Office 2013 Installation Fails with Error 1935

Symptoms

  • Office 2013 installation reaches ~80%
  • Installer throws Error 1935
  • Setup immediately rolls back
  • No usable log output unless manually enabled

Typical Error Message

“Error 1935. An error occurred during the installation of assembly component…”

This error is almost always related to .NET assemblies, Windows component registration, or corrupt AppModel metadata—not the Office installer itself.


Why Error 1935 Happens (The Real Cause)

Despite popular belief, Error 1935 is rarely caused by:

  • Insufficient permissions
  • Antivirus software
  • Corrupt Office media

In practice, the most common causes are:

  • Corrupt Windows AppModel registry entries
  • Broken .NET Framework registration
  • Remnants of modern Windows apps after OS upgrades
  • Incomplete Office uninstallations

Windows 10 version 1803 made changes to how application manifests and assemblies are handled, which exposed these issues more frequently—especially on machines that had been upgraded rather than clean installed.


Solution 1 (Most Effective): Delete the AppModel Registry Key

Why This Works

In over 90% of cases I’ve dealt with, the issue was resolved by removing a corrupt AppModel registry hive. This forces Windows to rebuild internal application metadata the next time it’s required.

Despite how scary registry edits sound, this particular change has proven to be safe and non-destructive in real-world deployments.


Step-by-Step: Remove the AppModel Registry Key

  1. Open Registry Editor
    • Press Win + R, type regedit, press Enter
  2. Navigate to:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppModel
  1. Back up the key (recommended but optional)
    • Right-click AppModel
    • Select Export
    • Save the .reg file somewhere safe
  2. Delete the AppModel key
    • Right-click → Delete
  3. Close Registry Editor
  4. Reboot the machine
  5. Attempt the Office 2013 installation again

Real-World Insight

I’ve used this fix:

  • On domain-joined machines
  • On laptops with UWP apps installed
  • In production corporate environments

I have never seen negative side effects from removing this key. Windows recreates what it needs automatically.

If you only try one fix from this article, make it this one.


Solution 2: Deep Clean Office and Repair .NET Framework

If Solution 1 does not resolve the issue (rare, but possible), then the next step is a methodical cleanup and repair.

Step 1: Fully Remove Any Existing Office Components

Even if Programs & Features shows no Office installations, remnants often remain.

Use Microsoft’s Office Uninstall Tool (formerly Fix It):

  • Run the tool
  • Select Completely remove all Office versions
  • Reboot when prompted

⚠️ Important:
In stubborn cases, you may need to run the tool more than once until it confirms no Office products remain.


Step 2: Repair the .NET Framework

Office 2013 relies heavily on .NET assemblies. If these are damaged or partially registered, Error 1935 is almost guaranteed.

  • Download the Microsoft .NET Framework Repair Tool
  • Run the tool as Administrator
  • Allow it to apply recommended fixes
  • Reboot the machine

Step 3: Retry the Office Installation

After reboot:

  • Disable third-party antivirus temporarily (optional but helpful)
  • Right-click the Office installer → Run as Administrator
  • Monitor installation progress

In most environments, Office will now install cleanly.


Additional Checks (If You’re Still Stuck)

These aren’t usually required, but are worth checking in stubborn cases:

Confirm Windows Modules Installer Is Running

  • Service name: TrustedInstaller
  • Startup type: Manual
  • Status: Running during install

Check Windows Event Viewer

Look under:

  • Application logs
  • .NET Runtime errors
  • SideBySide warnings

These often confirm the assembly-related nature of Error 1935.


Why Reinstalling Windows Is the Wrong First Move

I’ve seen many techs jump straight to:

  • OS refresh
  • In-place Windows repair
  • Full device rebuild

In almost every case, that was unnecessary.

Error 1935 is:

  • A symptom, not a root cause
  • Almost always fixable with registry or component repair
  • Not a sign of a “broken” OS

Reinstalling Windows should be the absolute last resort, not the default response.


Final Thoughts: A Practical IT Fix That Actually Works

Office 2013 Error 1935 is one of those issues that:

  • Wastes hours of troubleshooting
  • Sends admins down the wrong path
  • Looks far more serious than it actually is

In real-world IT environments, the AppModel registry fix alone resolves the majority of cases. Combined with proper Office cleanup and .NET repair, this issue becomes completely manageable.

If you’re supporting legacy Office versions on Windows 10, this is one fix worth bookmarking—you will need it again.

Leave a Reply

Your email address will not be published. Required fields are marked *