mcpbeat

Binlog Failure Analysis

microsoft/binlog-failure-analysis

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), non-MSBuild build systems.

This is a copy. The original lives at dotnet/binlog-failure-analysis.

732 tokens
context cost
the whole folder, loaded on every use
1
files
instructions only
1
copies elsewhere
how many repositories repackaged it
1034
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/microsoft/testfx --skill binlog-failure-analysis

The instruction itself

6 sections, as written by the author

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, fall back to 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 without access to the dotnet-tools NuGet feed).

Replay the binlog to text logs

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

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)

dotnet build /bl:build.binlog

Repackaged in 1 other repositories

same content, different owner
dotnet/skills open on GitHub →

How to use it

Copy the folder

Take microsoft/binlog-failure-analysis from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.