clr-activation-debugging

Diagnose .NET Framework runtime activation failures by analyzing CLRLoad logs from mscoree.dll.

1|Updated Jun 1, 2026
One-click install
npx skills add https://github.com/D1ssolve/craft-agents --skill clr-activation-debugging-d1ssolve
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: clr-activation-debugging
Source: https://github.com/D1ssolve/craft-agents/tree/main/skills/clr-activation-debugging
Command: npx skills add https://github.com/D1ssolve/craft-agents --skill clr-activation-debugging-d1ssolve

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? When .NET Framework applications fail to load the CLR, pick the wrong runtime version, or trigger unexpected .NET 3.5 Feature-on-Demand dialogs, the root cause is hidden inside the shim's runtime selection logic. This Skill interprets CLR activation logs (CLRLoad logs) produced by mscoree.dll to trace exactly how the shim decided which runtime to load and why it failed. ## Core Features & Use Cases - Log Analysis Workflow: Surveys CLRLoad log files, identifies entry points (_CorExeMain, DllGetClassObject, CorBindToRuntimeEx), and traces version resolution decisions step by step. - FOD and Error Diagnosis: Explains why Feature-on-Demand dialogs appear or are suppressed based on SEM_FAILCRITICALERRORS inheritance, capping state, and config file presence. - COM Activation Troubleshooting: Decodes CLSID registry layout and legacy bind behavior for native tools like link.exe and mt.exe that activate CLR-hosted COM objects such as diasymreader. - Use Case: A build machine suddenly shows .NET 3.5 install dialogs when running mt.exe. Use this Skill to analyze the CLRLoad logs, discover the capped legacy COM activation path, and fix it by adding a config file with useLegacyV2RuntimeActivationPolicy. ## Quick Start Analyze the CLRLoad log files in C:\CLRLoadLogs and explain why mt.exe triggered a .NET 3.5 Feature-on-Demand dialog.

Frequently Asked Questions about clr-activation-debugging

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I enable CLR activation logging for .NET Framework?

Set the COMPLUS_CLRLoadLogDir environment variable or the HKLM\SOFTWARE\Microsoft\.NETFramework\CLRLoadLogDir registry value to an existing directory. The shim writes {ProcessName}.CLRLoad{NN}.log files there, readable only after the process exits.

Why does a .NET 3.5 Feature-on-Demand dialog appear unexpectedly?

A native process is doing a capped legacy COM activation that cannot see CLR v4, finds no v2.0 runtime installed, and SEM_FAILCRITICALERRORS is not set, so the shim launches fondue.exe. The error mode is inherited from the parent process, which explains behavior differences between launch methods.

Does this Skill work for .NET Core or .NET 5 and later?

No. This Skill covers only .NET Framework activation through the mscoree.dll shim. Modern .NET (CoreCLR and .NET 5+) uses a different host and does not produce CLRLoad logs.

Why does CLR activation fail with HRESULT 0x80131700?

HRESULT 0x80131700 (CLR_E_SHIM_RUNTIMELOAD) means the shim could not find or load a suitable runtime version. It commonly occurs when a capped legacy codepath runs on a v4-only machine without .NET 3.5 installed, and CLR activation logs reveal the exact decision path.

What is the difference between CLR activation logs and Fusion logs?

CLR activation logs record how the shim selects and loads a runtime version, while Fusion logs (fuslogvw.exe) diagnose assembly binding failures after the CLR is already loaded. Use activation logs for runtime load failures and Fusion logs for assembly resolution issues.

How do I make legacy COM activation use CLR v4 instead of failing?

Add an application config file with useLegacyV2RuntimeActivationPolicy="true" and a supportedRuntime entry for v4.0. This lifts the Whidbey cap so legacy codepaths can enumerate v4, though it disables in-proc side-by-side with pre-v4 runtimes.