Volantic Systems
Repo Room

Specimen 06 of 09

netcoredbg

The .NET Framework codebases that fund the bills are also the ones with the worst tooling. This fork is the part of that gap I have closed: a debugger that speaks both the modern .NET runtime and the 20-year-old one running production today.

Overview

Samsung’s netcoredbg is a serious managed-code debugger: GDB/MI interface, VSCode-compatible Debug Adapter Protocol, CLI, the works. It runs against CoreCLR, the runtime behind .NET Core and modern .NET. It does not run against the older Windows .NET Framework runtimes, CLR 2.0 (powering .NET 2.0 through 3.5) and CLR 4.0 (powering .NET 4.x), which is exactly the gap that hurts, because that is where the unmigrated production code still lives.

This fork closes the gap. Four commits of original work add CLR 2.0 and CLR 4.0 support alongside CoreCLR, with Windows PDB conversion to make the existing variable-inspection paths work and an mscorlib.dll fallback for the older runtimes. The reason the work lives in a fork rather than upstream is documented in one of my own commit messages: Samsung does not accept external pull requests on this repo. Not a problem to be argued with, just a constraint to engineer around. So I did.

Technical

The fork lives on a framework-support branch. Original commits ahead of origin/master:

  • feat: add .NET Framework CLR 2.0 and CLR 4.0 debugging support: the core extension. Adding a second runtime to a debugger originally designed for one means dealing with different metadata layouts, different PDB symbol formats, and different process-attach mechanics on Windows.
  • feat: Windows PDB conversion, CLR 2.0 pause/stack, stopOnEntry for attach: Windows-style PDB symbol conversion so the existing variable-inspection paths work, plus the legacy-runtime equivalents of pause, stack walking, and stopOnEntry semantics for attach scenarios.
  • fix: add mscorlib.dll fallback for .NET Framework variable inspection and expression evaluation: the older runtimes ship core types in mscorlib.dll rather than the System.Private.CoreLib of CoreCLR; without a fallback path, variable inspection collapses on anything touching primitive boxing or string handling.
  • docs: note that Samsung does not accept external PRs: operational reality, written down so the next person who looks at the diff understands why the work is downstream.

The codebase is C++ with CMake; integration with both runtimes is through their respective debug-symbol and runtime-introspection interfaces. The fork pairs with the mcp-debugger fork in the same org, which exposes this debugger to AI agents over MCP.

Why You Should Care

A lot of consulting work in 2026 is not greenfield. It is a .NET 4.6 service running on Windows Server 2019 that needs to keep working while the modernisation plan is figured out. Set a breakpoint inside that process, from an AI agent or from a developer, and the whole job gets easier. Refuse to touch it because the tooling is awkward, and the bill grows. The instinct to stay in the modern stack is understandable. The economic value lives in being willing to go where the older code lives.

The technical surface is real. Adding CLR 2.0 and CLR 4.0 to a CoreCLR-only debugger is not a configuration flag. Different metadata layouts, different symbol formats, different process-attach mechanics. Windows PDB conversion is the kind of plumbing that does not exist in tutorials; you read Microsoft’s debug-info documentation, look at how dbghelp resolves symbols, write the conversion, and then debug it against actual binaries until the variables show up correctly. The mscorlib.dll fallback is the same story at the type-system layer.

Maintaining a long-lived fork against an active upstream that does not accept PRs is its own discipline. You keep up with Samsung’s changes. You keep your branch clean. You write commit messages future-you can read in six months. None of it is glamorous. All of it is what serious systems work actually looks like.

Status

Active fork on the framework-support branch. Four commits of original work ahead of Samsung/netcoredbg master. Pairs with the mcp-debugger fork above to expose this debugger to AI agents over MCP.

Repo: https://github.com/VolanticSystems/netcoredbg Upstream: https://github.com/Samsung/netcoredbg

netcoredbg