clr-activation-debugging

What it does

Diagnoses .NET Framework CLR 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.

How it works

• When to use: apply to cases where the process cannot load a CLR, the shim selects the wrong CLR (e.g., v2.0 vs v4.0), unexpected or missing .NET 3.5 FOD dialogs, or when activation questions arise about the runtime.
• Prerequisites: CLR activation logging must be enabled to produce log files via environment variable or registry settings, with logs named "{ProcessName}.CLRLoad{NN}.log" and only readable after process exit.
• Inputs: CLR activation log files, symptom description, and expected behavior.
• Workflow:
  1. Load reference material (log format, activation flow, COM activation).
  2. Survey log files by grouping per process, identify outcomes like "Decided on runtime: vX.Y.Z", "ERROR:", "Launching feature-on-demand", or "Could have launched feature-on-demand".
  3. Analyze problematic logs tracing entry points (e.g., _CorExeMain, DllGetClassObject. Clsid: {guid}, ClrCreateInstance, CorBindToRuntimeEx, ICLRMetaHostPolicy::GetRequestedRuntime, LoadLibraryShim).
  4. Inspect input parameters such as IsLegacyBind, IsCapped, SkuCheckFlags, ShouldEmulateExeLaunch, and LegacyBindRequired.
  5. Process config file results, noting presence/absence and effects like UseLegacyV2RuntimeActivationPolicy.
  6. Review version resolution outputs (e.g., Installed Runtime: vX.Y.Z, Decided on runtime: vX.Y.Z).
  7. If failure, follow the path showing FOD behavior and SEM_FAILCRITICALERRORS state to determine whether FOD was shown or suppressed.
  8. For multiple activations in one process, understand sequence patterns (e.g., first activation succeeds, subsequent fails under legacy cap).
  9. Optional system checks for CLSID registrations, installed runtimes, and SEM_FAILCRITICALERRORS inheritance.
• Output: A diagnosis describing what happened, why it happened, which inputs controlled the behavior, and what changed if applicable.

When to use it

• When a process fails to load the CLR, the shim selects the wrong CLR, FOD dialogs appear unexpectedly or not at all, multiple runtimes load in one process, or a COM object fails to activate due to shim runtime resolution.

What it can touch

• Logs and references described in the workflow; explicit commands and file names are used as written in the logs and steps (e.g., CLRLoad logs, fondue.exe, fondue.exe /enable-feature:NetFx3, fuslogvw.exe).

Caveats

• Modern .NET (CoreCLR / .NET 5+) are not covered by this skill.
• Runtime crashes after the CLR has loaded are outside activation troubleshooting.
• Logs must be read after the process exits; the log file is held open during runtime. Logs directory must exist; the shim will not create it.