RAD Debugger: Epic's Native Windows x64 Debugger and RAD Linker

What RAD Debugger solves, and who it is actually for

Most debuggers on Windows are either IDE-embedded or built on top of older infrastructure. RAD Debugger takes a different position: it is a standalone, native, user-mode, multi-process graphical debugger that reads its own debug information format rather than the one the toolchain emitted. The README describes it as currently supporting only local-machine Windows x64 debugging with PDBs, with plans to expand to native Linux debugging and DWARF debug info.

The audience is narrower than the name suggests. This is for engineers working on Windows x64 C and C++ codebases, particularly large ones, who are willing to run alpha software and file issues with dumps and reproduction steps. The README asks for exactly that, noting that the debugger is in ALPHA and that reports should include dump files, the build used, reproduction instructions, and test executables. If your project is small, cross-platform, or maintained by a team that cannot tolerate a debugger crash mid-session, the pitch lands differently.

The second half of the project is less about debugging and more about build speed. The RAD Linker is a performance linker for x64 PE/COFF binaries, and the README states it is primarily optimized to handle huge linking projects, with 50% faster link times in test cases where debug info is multiple gigabytes. That number comes from the project's own test cases, not an independent measurement.

RDI, PDB conversion, and the linker's role in the pipeline

The mechanism is the most interesting part of the project and the part most likely to surprise someone expecting a conventional debugger. RAD Debugger does not parse PDB or DWARF directly as its primary format. It parses the RAD Debug Info (RDI) format, described in the README as a custom debug information format, and converts PDB files into RDI on demand to interoperate with existing toolchains. The README states that PE/ELF files with embedded DWARF are planned but not yet handled.

RDI is specified in code rather than in a document. The README points to src/lib_rdi/rdi.h and src/lib_rdi/rdi.c for the types and functions that define the format, and to rdi_parse.h and rdi_parse.c for parsing helpers. A library for constructing and serializing RDI data is in progress under src/lib_rdi_make. That is a real constraint for anyone who wants to write a third-party consumer: the specification is the source, so it moves when the source moves.

The conversion path runs through the radbin utility, which the README says can convert native debug information formats to RDI and produce textual dumps of RDI contents. radbin is also reachable from inside the debugger through the --bin command line argument.

The linker closes the loop. RAD Linker generates standard PDB files, and can optionally create RDI natively, which the README says eliminates on-demand conversion time and avoids the broken PDBs that huge executables produce when they overflow internal 32-bit tables. That overflow case is the strongest argument for the whole design: if your executable is large enough that PDB generation itself fails, converting after the fact is not an option.

Installing RAD Debugger and building from source on Windows

There are two paths. The README points to pre-built release binaries on the GitHub releases page, which is the faster route and the one most users should take. The debugger's own README, containing usage instructions and tips, is packaged with those releases; the repository README explicitly says it does not document usage and is a technical overview instead.

Building from source requires x64 Windows. The README states that only x64 Windows development is supported, and that you need the Microsoft C/C++ Build Tools v15 (2017) or later for both the Windows SDK and the MSVC compiler and linker. Clang can be used if the Windows SDK is installed.

Start in a terminal that can call MSVC. The usual way is the x64 Native Tools Command Prompt for VS, which calls vcvarsall.bat x64 for you.

cl

If the environment is set up correctly, the README says you should see output resembling the Microsoft C/C++ Optimizing Compiler version banner followed by its usage line.

From the repository root, run the build script with no arguments to produce a debug-mode raddbg.exe in a build folder.

build

The README shows the expected output beginning with a debug mode line, an msvc compile line, and a default mode line assuming a raddbg build, followed by metagen and parsing steps.

Release mode is a separate argument, and the README warns it takes significantly longer.

build release

To build the linker or the radbin utility instead of the debugger, pass them as arguments. The README gives this example for the linker.

build radlink

A first real use is to launch the built raddbg.exe from the build folder and load a local x64 executable with PDBs. The repository README does not cover what to click once it opens; that lives in the debugger README shipped with releases and in the build folder.

The linker's thread and large-page switches, and where they break

RAD Linker aims for command line compatibility with MSVC, and the README says a full list of implemented switches is available from /help. Two switches are worth knowing before you run it in a build farm.

By default the linker spawns as many threads as there are cores. If you plan to run multiple linkers in parallel, the README says to limit the number of thread workers with /rad_workers. On a machine running several link jobs at once, the default will oversubscribe the CPU.

Large memory pages are opt-in through /rad_large_pages, and the README states they reduce link time by another 25%. The same paragraph is unusually blunt about the cost: Windows support for large pages is described as a bit buggy, and the recommendation is to use them only in Docker or VM images where the environment resets after each link. On a normal Windows machine, the README says large pages will fragment memory quickly and force a reboot. That is a hard operational limit, not a tuning note.

There is a feature gap too. The README states that link-time optimizations are not supported yet and are on the road map. If your build depends on LTO, the linker cannot replace your current one today.

Where RAD Debugger is the wrong tool

The platform boundary is the first answer. The README says the debugger currently only supports local-machine Windows x64 debugging with PDBs. If you are debugging on Linux, or debugging a remote target, or working with DWARF debug info, this project does not do it yet, and the README frames Linux and DWARF as future work rather than current capability.

Alpha status is the second. The README asks users to submit issues with dump files, the build used, reproduction steps, and test executables, which is a reasonable request for an alpha and also a signal about expected failure rates. A debugger that crashes while you are diagnosing a crash costs more than it saves, so keep a second debugger installed.

Large pages are the third. The README's own guidance limits /rad_large_pages to disposable Docker or VM environments because of Windows large-page behavior and memory fragmentation. On a developer workstation this switch is a liability.

Finally, RDI is a project-specific format. If your workflow depends on other tools reading your debug info, the conversion path back from RDI is not something the README describes. The README documents conversion from PDB to RDI and textual dumps of RDI contents; it does not document a reverse path, and it does not document rollback of any conversion.

RAD Debugger against GDB and Visual Studio's debugger

The comparison people search for is against GDB, and the difference is architectural rather than cosmetic. GDB is a portable debugger built around DWARF and other native formats, and it runs on Linux, macOS, and Windows. RAD Debugger is Windows x64 only, user-mode only, and parses RDI, a format defined inside this repository. The README states that DWARF support is planned, so today the two tools do not even read the same debug information on the same platform.

Against Visual Studio's debugger, the split is about packaging and scope. Visual Studio's debugger is embedded in an IDE and reads the PDBs your toolchain produces directly. RAD Debugger is a standalone graphical application with its own format in the middle, plus a linker that can emit RDI natively. The README's argument for that extra layer is concrete: eliminating on-demand conversion time, and avoiding PDBs that break on huge executables because internal 32-bit tables overflow. If your binaries are not in that size class, the conversion layer is overhead you are choosing to take on.

RemedyBG and editor integrations such as VS Code, Neovim, Zig, Odin, and Unity setups appear in what people search for around this project, but the repository README does not describe any of those integrations. Do not assume an integration exists because someone searched for it.

Licence, maintenance, and what upgrades cost you

The repository is licensed MIT, per the LICENSE file at the top level. That is a permissive licence, and it means the debugger and linker can be used in commercial builds without a copyleft obligation. This is a description of the licence identifier, not legal advice; read the LICENSE file itself for the terms.

Maintenance signals are visible in the repository. The project is not archived, and the last push to the default branch master was on 2026-09-21. Releases are frequent and versioned in the 0.9.x-alpha line, with v0.9.28-alpha published on 2026-08-21, v0.9.27-alpha on 2026-06-12, and v0.9.26-alpha on 2026-05-19. The alpha suffix in every release name is the honest summary of what you are tracking.

Upgrade cost is mostly about the on-disk format. Because RDI is specified in code within src/lib_rdi rather than in a frozen document, and because the RAD Linker can emit RDI natively, a version bump can change what the debugger expects to read. The README does not document a compatibility guarantee for RDI files across versions, and it does not document a migration or rollback procedure. If you generate RDI artifacts in CI and cache them, treat them as version-coupled to the toolchain that produced them. The CHANGELOG.md at the top level is where release-to-release changes are recorded.

Editorial conclusion

Adopt RAD Debugger if you build large C or C++ projects on Windows x64 and want a faster link step or a multi-process view of your program. Do not adopt it if you need Linux, macOS, DWARF, or a stable tool, since the README labels the debugger ALPHA and states that only local-machine Windows x64 debugging with PDBs is supported. Before committing, verify that the pre-built binary from the releases page attaches to one of your own executables and that the RAD Linker accepts your current MSVC link switches, since link-time optimization is not implemented.

Frequently asked questions

Official sources

1. EpicGames/raddebugger on GitHub
2. Issues
3. License: MIT
4. README
5. Releases