Skip to content

Est. 2011·Microsoft Partner 7033487·Delivery under 3 min·Support 7 days a week

Your vault is empty.

Free Fix 0xe0434352

VSTO Add-in Crash 0xe0434352: .NET Exception Kills Outlook, Word or Excel

11 min read Updated October 4, 2026 Outlook & Office Applications

Fix it now

0xE0434352 is the CLR exception code – a managed exception reached Windows unhandled and the host process was terminated with it. Microsoft notes that the first exception parameter carries the HRESULT of the actual error. The Office application is the casualty; a managed add-in is the cause.

  1. In Event Viewer, under Windows Logs then Application, find the Event ID 1000 for the Office process and confirm the exception code is 0xe0434352.
  2. Look immediately above or below it for a .NET Runtime entry. That one names the exception type and the stack, and it is the actual diagnosis.
  3. Check whether Office has already parked the add-in: File > Options > Add-ins, then work through the Manage box, looking at both the disabled list and the inactive list.
  4. Turn on the add-in loader’s own diagnostics: create an environment variable named VSTO_SUPPRESSDISPLAYALERTS set to 0, and one named VSTO_LOGALERTS set to 1, then start the application again.
  5. Read the log. For an application-level add-in it is written beside the deployment manifest and named after the add-in with a .vsto.log extension; if that folder cannot be written, it goes to the %TEMP% folder instead.
  6. If the add-in or its assemblies live on a network path, unblock the files with Unblock-File in PowerShell, or install it locally instead.
  7. Reinstall the add-in with the vendor’s installer after removing the previous version, and keep the installer log if it fails.

Remove the two environment variables when you have finished. Leaving VSTO_SUPPRESSDISPLAYALERTS at 0 means every user of that machine gets a message box for every add-in error, which is a support problem of its own.

If the application starts three times in a row with the add-in loaded, you are done. The next section explains why a managed add-in can take the whole process down and what each HRESULT is telling you.

Why it happens

A managed Office add-in does not run beside the application. It runs inside it, in the same process, on a runtime loaded into that process. That is what gives it full access to the object model, and it is also why an exception nothing catches has nowhere to go: the runtime hands it to Windows as a structured exception with code 0xE0434352 – “CCR” in ASCII – Windows terminates the process, and the user sees Office disappear. Microsoft’s own note on the code is worth remembering: the first exception parameter is the HRESULT of the error.

Most failures happen in the few seconds of startup, because that is when the add-in reads its configuration, contacts a licence or data service, and builds its ribbon. An exception thrown from inside a startup handler comes back as 0x80131604, which is COR_E_TARGETINVOCATION – the HRESULT of TargetInvocationException. That is a wrapper by design: the real fault is the inner exception, and it is the .NET Runtime event rather than the Application Error event that names it.

0x80131509 is COR_E_INVALIDOPERATION, the HRESULT of InvalidOperationException, thrown when a call is invalid for the object’s current state – in this context usually an add-in expecting something in the host that is not there yet. 0x80131515 is COR_E_NOTSUPPORTED, the HRESULT of NotSupportedException, and it is worth being careful with: it does not mean “blocked assembly”. It means the operation is not supported, and one common instance is the .NET Framework refusing to load an assembly from a network location, which it reports as a NotSupportedException carrying this HRESULT.

Installation failures are a separate track. 1603 is the Windows Installer code ERROR_INSTALL_FAILURE, “A fatal error occurred during installation”, and that is the whole of its published meaning. The number tells you the install failed and nothing else; the installer’s own log is the only place the reason exists.

The add-in throws during startup

You have this one if Office dies within a few seconds of launch, every time, and the .NET Runtime event names an exception type from the vendor’s own namespace.

  1. Read the .NET Runtime event and note the exception type and the top of the stack. That is what the vendor will ask for.
  2. Check whatever the add-in needs at startup: its configuration file, a licence server, a database connection, a proxy that wants authentication.
  3. Start once with the add-in disabled to confirm it is the only problem, then re-enable it after fixing the dependency.
  4. If it is developed in house, wrap the startup handler so failures are logged rather than allowed to reach the runtime.

Assemblies are blocked, or loaded from a network path

You have this one if 0x80131515 with a NotSupportedException about loading an assembly from a network location, or the add-in works locally and fails when deployed from a share.

  1. Unblock the files: right-click, Properties, Unblock, or run Unblock-File against the deployment folder in PowerShell.
  2. Unblock the archive before extracting it. Extracting first copies the mark onto every file inside.
  3. Deploy the add-in to a local folder on each machine rather than running it from a share.
  4. Where a remote load genuinely has to be permitted, the .NET Framework switch for it is the loadFromRemoteSources element in the application configuration – which grants full trust to those assemblies, so understand what you are agreeing to.

Do not read 0x80131515 as “the assembly was blocked”. It is the HRESULT of NotSupportedException generally, so read the exception text before you go unblocking files that were never the problem.

The runtime the add-in needs is missing or damaged

You have this one if It fails on new machines or after a rebuild, and the loader log complains about the runtime rather than about the add-in.

  1. Confirm which .NET version the add-in targets. The vendor’s documentation is the authority; guessing wastes an afternoon.
  2. Install or repair that runtime, together with the Office runtime the vendor’s installer normally deploys alongside it.
  3. Reinstall the add-in afterwards so its registration is rewritten against a healthy runtime.
  4. If the installer ends with 1603, run it again with logging enabled and search the log for the first error, not the last.

Office has disabled the add-in after previous crashes

You have this one if The crash has stopped and the add-in has disappeared with it, and re-enabling it lasts only until the next restart.

  1. Check both lists under File > Options > Add-ins: the disabled items and the inactive application add-ins.
  2. Re-enable it there rather than by reinstalling, so you can see whether Office disables it again.
  3. Fix the exception first. Restoring the add-in without fixing what it throws simply repeats the cycle.

Being disabled is a symptom, not the fault. An add-in that Office disables twice in a row is telling you the crash is still happening.

Full reference

Sorting the failure by its code

What you see What it points at
0xe0434352 with a .NET Runtime event naming a vendor exception A fault inside the add-in’s own code or configuration
0x80131604 in the log TargetInvocationException: the real fault is the inner exception
0x80131509 InvalidOperationException: the call was invalid for the object’s state at that moment
0x80131515 NotSupportedException. Read the message: a network assembly load is one common instance, not the meaning
The add-in is missing from the ribbon with no crash It was disabled after an earlier failure, or its load behaviour was reset
Installer ends with 1603 A fatal installer error. The log holds the reason; the number does not

Turning on the loader’s diagnostics

Variable Set it to What happens
VSTO_SUPPRESSDISPLAYALERTS 0 Each error is displayed in a message box
VSTO_SUPPRESSDISPLAYALERTS 1, or delete it The messages are suppressed again
VSTO_LOGALERTS 1 Errors are written to a log file
VSTO_LOGALERTS 0, or delete it Logging stops

The log goes into the folder holding the deployment manifest for the add-in, or the folder holding the document for a document-level customisation, and falls back to %TEMP% if neither can be written. Application-level add-ins produce a file named after the add-in with a .vsto.log extension; document-level ones are named after the document, extension included, with .log added.

Where the network-assembly rule comes from

By default the .NET Framework refuses to load an assembly from a remote location and raises a NotSupportedException saying that doing so would have sandboxed the assembly under older versions, and that the load may be dangerous because policy is no longer applied by default. The configuration switch that permits it grants those assemblies full trust, which is exactly why deploying add-ins to a local folder on each machine is the better answer than reaching for the switch.

Runtime support, so nobody plans around a dead end

Microsoft states that the Visual Studio Tools for Office runtime add-ins platform is supported and serviced in Office with .NET Framework 4.8 as the last major version. That is worth knowing before anyone proposes rewriting an add-in onto a newer runtime to fix a crash: it will not be a supported target for this hosting model, and the crash you have is almost certainly the add-in’s own code rather than the runtime under it.

Editing add-in registration under the Office registry keys changes whether the add-in loads at all. Export the branch before you change a load-behaviour value, and put it back if the add-in still crashes, rather than leaving Office and the registry fighting each other at every start.

Every code this article covers

Code What it points at Source
0xe0434352 The CLR exception code – “CCR” in ASCII. A managed exception reached Windows unhandled; the first exception parameter carries the HRESULT of the error Microsoft Learn
0x80131515 COR_E_NOTSUPPORTED, the HRESULT of NotSupportedException. A common instance in this context is the .NET Framework refusing to load an assembly from a network location Microsoft Learn
1603 ERROR_INSTALL_FAILURE: a fatal error occurred during installation. The reason exists only in the installation log Microsoft Learn
0x80131604 COR_E_TARGETINVOCATION, the HRESULT of TargetInvocationException; the real fault is the inner exception Microsoft Learn
0x80131509 COR_E_INVALIDOPERATION, the HRESULT of InvalidOperationException: the call was invalid for the object’s current state Microsoft Learn

Confirm the fix worked

  1. Start the affected application three times in a row and confirm it stays open.
  2. Check the Application log for new Event ID 1000 entries carrying the managed exception code.
  3. Confirm the add-in shows as an active application add-in rather than an inactive or disabled one.
  4. Read the loader log once more to confirm a clean load, then remove both environment variables.
  5. Have the user who reported it work normally for a day, because a startup dependency can fail intermittently rather than every time.

Questions people ask about this

Can I fix this by reinstalling Office?

Rarely. The crash comes from a component loaded into Office, so reinstalling Office removes nothing except your afternoon. Remove or update the add-in first, and keep the reinstall for the case where the .NET Runtime event points at the installation itself.

Do I need to buy anything to resolve this?

No. There is no licence that prevents an add-in throwing an exception, and every step here is free. If the add-in is itself a paid product, an updated build from its vendor may be the fix, and that is a conversation with them.

Can I just leave the add-in disabled?

If nobody uses it, yes, and that is the cheapest outcome. If it is needed, disabling it only buys time – the vendor still has to be told what the .NET Runtime event said, and that event is the only thing that will get you a useful answer from them.

Why does it work for some users and not others?

Because the exception depends on what the add-in reads at startup. Different permissions, a different profile, a mapped drive only some people have, or an unreachable licence server all produce exactly this pattern.

The error says 0x80131515, so the assembly is blocked. Should I unblock everything?

Read the exception text first. 0x80131515 is the HRESULT of NotSupportedException in general, not a code that means “blocked assembly”. A network assembly load is one common instance and the message says so explicitly when it is the cause. If the message says something else, unblocking files will not help.

Related error codes

Was this article helpful?

Your feedback helps us improve our documentation.

Related articles

Free Fix There Was a Problem Sending the Command to the Program: Excel DDE and OLE Failures Free Fix Outlook Certificate Errors 0x80072F0D and 0x800B0109: Untrusted or Mismatched SSL Free Fix Outlook 0x800CCC13 Cannot Connect to Network: Repair a Broken Winsock Stack Free Fix Excel found unreadable content: Repair a Corrupt Workbook and Recover Data
← Back to Knowledge Base