# Clr Activation Debugging

Diagnoses .NET Framework CLR activation issues using CLR activation logs (CLRLoad logs)...

- Repository: https://github.com/dotnet/skills (5787 stars)
- Category: Engineering
- License: MIT
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add dotnet/skills --skill clr-activation-debugging -g -a claude-code -y`
Codex: `npx skills add dotnet/skills --skill clr-activation-debugging -g -a codex -y`
Cursor: `npx skills add dotnet/skills --skill clr-activation-debugging -g -a cursor -y`
Gemini CLI: `npx skills add dotnet/skills --skill clr-activation-debugging -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add dotnet/skills`

## 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?

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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

The rest: https://github.com/dotnet/skills/blob/HEAD/plugins/dotnet-diag/skills/clr-activation-debugging/SKILL.md