clr-activation-debugging

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

Updated Jul 12, 2026
One-click install
npx skills add https://github.com/Patrick-Rex/DotNetTechSamples --skill clr-activation-debugging-patrick-rex
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: clr-activation-debugging
Source: https://github.com/Patrick-Rex/DotNetTechSamples/tree/main/.agents/plugins/dotnet-diag/skills/clr-activation-debugging
Command: npx skills add https://github.com/Patrick-Rex/DotNetTechSamples --skill clr-activation-debugging-patrick-rex

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? When .NET Framework applications fail to start, load the wrong runtime version, or trigger unexpected .NET 3.5 Feature-on-Demand install dialogs, the root cause is hidden inside the mscoree.dll shim's runtime selection logic. This Skill decodes CLR activation logs (CLRLoad logs) to reveal exactly which decision path the shim took and why. ## 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 Dialog Diagnosis: Explains why .NET 3.5 Feature-on-Demand dialogs appear or are suppressed based on SEM_FAILCRITICALERRORS inheritance and Whidbey capping. - COM Activation Tracing: Resolves legacy COM activation failures (e.g., diasymreader in native build tools like link.exe and mt.exe) using CLSID registry inspection. - Use Case: A build suddenly shows .NET 3.5 install prompts on machines without .NET 3.5. Use this Skill to analyze the CLRLoad logs, discover a capped legacy COM activation with no config file, and fix it by adding useLegacyV2RuntimeActivationPolicy to the tool's config. ## 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 performed a capped legacy COM activation through mscoree.dll, found no v2.0 runtime installed, and SEM_FAILCRITICALERRORS was not set, so the shim launched fondue.exe to offer .NET 3.5 installation.

Why is the Feature-on-Demand dialog suppressed on some machines?

The SEM_FAILCRITICALERRORS process error mode flag suppresses FOD dialogs. It is inherited from the parent process, so build systems or scripts that call SetErrorMode silently change FOD behavior for all child processes.

Does CLR activation log analysis apply to .NET 5 or later?

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

How do I make legacy COM activation use .NET 4 instead of failing?

Add a config file for the executable with useLegacyV2RuntimeActivationPolicy="true" and a supportedRuntime entry for v4.0. This lifts Whidbey capping so legacy codepaths can enumerate and bind to CLR v4.

What does HRESULT 0x80131700 mean?

0x80131700 is CLR_E_SHIM_RUNTIMELOAD, meaning the shim could not find or load a suitable runtime version. It commonly appears when a capped legacy activation runs on a machine with only .NET 4 installed and no .NET 3.5.