Skip to main content
skill CX Codex

binlog-failure-analysis — Claude Code skill: setup and usage

Diagnoses MSBuild build failures from .binlog files. Use it when console output is unclear or cascading errors break multi-project builds.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add dotnet/skills --skill binlog-failure-analysis -a claude-code
Open on GitHub

What binlog-failure-analysis does

This skill inspects .binlog files using the bundled Microsoft.AITools.BinlogMcp server under the binlog namespace. Instead of parsing massive plain-text dumps, the agent calls structured tools to extract errors, warnings, MSBuild properties, and PackageReference items. Project files like .csproj and .props can be retrieved directly from the log payload when missing on disk.

Binary logs cannot be inspected with tools like cat or strings. Attempting to read them as plain text will fail. When the MCP server cannot start due to an older SDK or offline environment, the skill drops back to a text-log replay. It runs dotnet msbuild to produce structured diagnostic logs and filters them with grep.

What it helps with

  • Diagnose obscure MSBuild errors from an existing .binlog
  • Trace cascading build failures across multi-project solutions
  • Inspect MSBuild target execution order and property evaluation
  • Extract embedded project files from a binary log without source code

Example prompts for the agent

  • Analyze build.binlog and explain why the CoreCompile target failed
  • Inspect build.binlog to find the root cause of the build error
  • Check build.binlog for conflicting PackageReference items

How to install binlog-failure-analysis

1Skills CLI (Vercel)

npx skills add dotnet/skills --skill binlog-failure-analysis -a claude-code

2Manually: put the files in place

~/.claude/skills/binlog-failure-analysis/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/binlog-failure-analysis/

Step by step, with commands for each platform: How to install skills in Claude Code: five ways

Questions about binlog-failure-analysis

How to install binlog-failure-analysis in Claude Code?

Run npx skills add dotnet/skills --skill binlog-failure-analysis -a claude-code in your terminal. The skill file is stored at ~/.claude/skills/binlog-failure-analysis/SKILL.md.

What does binlog-failure-analysis do?

It investigates MSBuild .binlog files to pinpoint build failures, evaluate target execution order, and inspect properties. It relies primarily on the binlog MCP server to query structured data without manual text parsing.

What happens if the binlog MCP server cannot start?

The skill falls back to a text replay workflow using dotnet msbuild build.binlog with diagnostic log flags. It then inspects the resulting error and diagnostic logs with standard CLI tools like grep.

Source text

SKILL.md · MIT
---
name: binlog-failure-analysis
description: "Analyze MSBuild binary logs to diagnose build failures. USE FOR: build errors that are unclear from console output, diagnosing cascading failures across multi-project builds, tracing MSBuild target execution order, and generally any MSBuild build issues. Requires an existing .binlog file. DO NOT USE FOR: generating binlogs (use binlog-generation), binlog MCP startup or connection failures (use troubleshoot-binlog-mcp), non-MSBuild build systems."
license: MIT
---

# Analyzing MSBuild Failures with Binary Logs

This skill diagnoses MSBuild build failures from a `.binlog` file. The preferred
path uses the **binlog MCP server** (`Microsoft.AITools.BinlogMcp`, exposed under the
`binlog` MCP namespace) which is bundled with this plugin. If the MCP server is
not available, use `troubleshoot-binlog-mcp` to diagnose startup when repair is wanted.
If repair is blocked, declined, or unnecessary for this task, continue with the
**binlog replay** workflow at the bottom.

## Primary workflow — binlog MCP

The MCP server exposes structured tools for inspecting a `.binlog` without
parsing text logs. Call them directly instead of replaying the binlog to a text
file. Call `tools/list` for the MCP first if you are unsure which tools are available.

**Important constraints:**
- The `.binlog` file is a **binary format** — do NOT try to `cat`, `head`, `strings`, or read it directly. Use only the MCP tools to query it.
- The **original source/project files might or might NOT be available on disk**. Project files (.csproj, .props, .targets, App.config, etc.) - if you cannot locate them on disk, they can only be read from within the binlog via MCP tools (e.g., embedded/source file retrieval).
- **Synthesize findings as you go.** Do not spend all available time investigating — once you have enough evidence, present your conclusions. A partial answer with clear reasoning is better than timing out mid-investigation.

Use the available MCP server tools to query the binary log for:
- Build errors and warnings
- MSBuild properties and their values
- MSBuild items (PackageReference, ProjectReference, etc.)
- Project evaluation data
- Target execution details
- File contents embedded in the binlog

## Fallback workflow — text-log replay (when MCP is unavailable)

Use this only when the MCP server cannot be started (for example, on an older
SDK or in an offline environment).

### Replay the binlog to text logs

```bash
dotnet msbuild build.binlog -noconlog \
  -fl  "-flp:v=diag;logfile=full.log;performancesummary" \
  -fl1 "-flp1:errorsonly;logfile=errors.log" \
  -fl2 "-flp2:warningsonly;logfile=warnings.log"
```

> **PowerShell note:** Use `-flp:"v=diag;logfile=full.log;performancesummary"`
> (quoted semicolons).

### Search the text logs

```bash
cat errors.log
grep -n -B2 -A2 "CS0246" full.log
grep -i "CoreCompile.*FAILED\|Build FAILED\|error MSB" full.log
grep 'Target "CoreCompile"' full.log | grep -oP 'project "[^"]*"'
```

## Generating a binlog (only if none exists)

```bash
dotnet build /bl:build.binlog
```

© dotnet · MIT · dotnet/skills

Similar skills

Everything for DevOps and infrastructure →

From the same set101

test-gap-analysis Maps which caller-visible production outcomes could change without any existing test failing. Useful before you trust a suite to guard a change. CX Codex +1 3,500installs crap-score Calculates Change Risk Anti-Patterns (CRAP) scores for .NET methods, classes, and files. It highlights complex code that lacks adequate test coverage. CX Codex +1 3,500installs assertion-quality Reads tests you already have and reports how much their assertions actually verify, flagging green tests that check nothing meaningful. CX Codex +1 3,600installs dotnet-aot-compat Walks the IL analyzer warnings one at a time until a .NET project survives Native AOT and trimming. Useful right after an upgrade to net8.0. CX Codex +1 3,600installs migrate-nullable-references A skill that enables nullable reference types in C# projects and resolves all warnings. Use it to migrate existing codebases—project-wide or file-by-file—and annotate public APIs for nullability. CX Codex +1 3,400installs migrate-dotnet10-to-dotnet11 Systematically migrates .NET 10 solutions to .NET 11. It updates target frameworks, bumps dependencies, and resolves C# 15 compiler and EF Core 11 breaking changes. CX Codex +1 3,400installs detect-static-dependencies Scans C# and .NET code for static dependencies that complicate testing. Use it before adding unit tests or planning a refactor. CX Codex +1 3,400installs technology-selection Walks you from a task type to the right .NET 8+ library for AI and ML work. Useful when adding classification, RAG or agent loops. CX Codex +1 3,400installs

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor