/clr-activation-debugging

name: clr-activation-debugging
description: >-
  Diagnoses .NET Framework CLR activation issues using CLR activation logs
  (CLRLoad logs) produced by mscoree.dll. Use when: the shim picks the wrong
  runtime, fails to load any runtime, shows unexpected .NET 3.5 Feature-on-Demand
  (FOD) dialogs, unexpectedly does NOT show FOD dialogs, loads both v2 and v4
  into the same process causing failures, or any time someone is wondering
  "what is happening with .NET Framework activation?"
license: MIT

CLR Activation Debugging

Diagnose .NET Framework runtime activation issues by analyzing CLR activation logs (CLRLoad logs) produced by the shim (mscoree.dll). These logs record every decision the shim makes when selecting and loading a CLR version.

When to Use

• A process fails to load the CLR at all ("Unable to find a version of the runtime to use")
• The shim picks the wrong CLR version (e.g., v2.0 instead of v4.0)
• Unexpected .NET 3.5 Feature-on-Demand (FOD) install dialogs appear
• FOD dialogs are expected but do NOT appear
• Both CLR v2 and CLR v4 load into the same process, causing failures
• A COM object fails to activate because the shim can't resolve the runtime
• Legacy hosting APIs (CorBindToRuntime) bind to an unexpected version

When Not to Use

• **Modern .NET (CoreCLR / .NET 5+)** — this skill covers .NET Framework only (the mscoree.dll shim)
• **Assembly binding failures** — use Fusion logs (fuslogvw.exe), not CLR activation logs
• **Runtime crashes after the CLR has loaded** — activation succeeded; the problem is elsewhere

Background

The Shim Architecture

The .NET Framework shim has two layers:

• **mscoree.dll** (the "shell shim") — the public-facing DLL that is the registered `InprocServer32` for CLR-hosted COM objects and the entry point for `_CorExeMain`, legacy APIs, etc.
• **mscoreei.dll** — the actual shim implementation where the runtime selection logic, logging, and activation decisions live. mscoree.dll forwards into mscoreei.dll.

When reading logs, the `caller-name:mscoreei.dll` in FOD command lines reflects this — it's mscoreei.dll doing the work.

.NET 3.5 / v2.0.50727 Version Mapping

.NET 2.0, 3.0, and 3.5 all share the same CLR runtime version: **v2.0.50727**. The "3.0" and "3.5" releases were library additions on top of CLR v2.0. For activation purposes, they are all "v2.0.50727." When the shim resolves to v2.0.50727 or FOD offers to install "NetFx3", it's installing the CLR v2.0 runtime (plus the 3.0/3.5 libraries). Similarly, CLR v4.0 (v4.0.30319) covers all .NET Framework versions from 4.0 through 4.8.x.

.NET 3.5 Availability on Recent Windows

On recent Windows versions (Windows 11 Insider Preview Build 27965 and future platform releases), .NET Framework 3.5 is **no longer available as a Windows optional component (Feature-on-Demand)**. It must be installed from a standalone MSI. This means the FOD dialog (`fondue.exe /enable-feature:NetFx3`) will not succeed on these systems even if it fires. On Windows 10 and Windows 11 through 25H2, FOD remains available. .NET Framework 3.5 reaches end of support on January 9, 2029.

Shim HRESULT Codes

When the shim fails, it returns specific HRESULTs in the `0x8013xxxx` range. These are the errors you'll see from callers (not in the activation logs themselves, which log human-readable messages):

| HRESULT | Symbol | Meaning | |---------|--------|---------| | `0x80131700` | `CLR_E_SHIM_RUNTIMELOAD` | Cannot find or load a suitable runtime version. **This is the most common shim error** — it's what callers see when capped legacy activation fails on a v4-only machine. | | `0x80131701` | `CLR_E_SHIM_RUNTIMEEXPORT` | Found a runtime but failed to get a required export or interface from it. | | `0x80131702` | `CLR_E_SHIM_INSTALLROOT` | The .NET Framework install root is missing or invalid in the registry. | | `0x80131703` | `CLR_E_SHIM_INSTALLCOMP` | A required component of the installation is missing. | | `0x80131704` | `CLR_E_SHIM_LEGACYRUNTIMEALREADYBOUND` | A different runtime is already bound as the legacy runtime. A legacy API tried to bind to a version that conflicts with the one already chosen. | | `0x80131705` | `CLR_E_SHIM_SHUTDOWNINPROGRESS` | The shim is shutting down and cannot service the request. |

If a user reports one of these HRESULTs (especially `0x80131700`), CLR activation logs are the right diagnostic tool.

Prerequisites

CLR activation logging must be enabled to produce log files. If the user doesn't have logs yet, instruct them to enable logging:

**Via environment variable (recommended — scoped to current session):**

set COMPLUS_CLRLoadLogDir=C:\CLRLoadLogs

**Via registry (machine-wide — affects all .NET Framework processes):**

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework
  CLRLoadLogDir = "C:\CLRLoadLogs" (REG_SZ)

On 64-bit systems, also set under `Wow6432Node` if 32-bit processes are involved.

> ⚠️ **The log directory must already exist.** The shim will not create it. If it doesn't exist, no logs will be written and there will be no error or indication of failure.

Logs are written as `{ProcessName}.CLRLoad{NN}.log` (NN = 00–99, one per process instance). **Logs cannot be read until the process exits** — the file is held open.

After capturing, **remove the env var or registry key** to stop logging.

Inputs

| Input | Required | Description | |-------|----------|-------------| | CLR activation log files | Yes | One or more `.CLRLoad*.log` files | | Symptom description | Recommended | What the user observed (FOD dialog, wrong runtime, failure, etc.) | | Expected behavior | Recommended | What the user expected to happen |

Workflow

Step 1: Load Reference Material

Try to load the reference files in this order — they contain the detailed log format, decision flow, and CLSID registry documentation:

1. `references/log-format.md` — Log line format, fields, and all known log message types 2. `references/activation-flow.m