RAD Debugger: Epic's Visual Debugger, Now Open Source

TL;DR: RAD Debugger is Epic Games’ graphical debugger for C and C++, released under the MIT license. It attaches to a running process, shows you the object graph as a visual tree, and lets you inspect memory without attaching a separate IDE.

What it is

RAD Debugger describes itself as a native, user-mode, multi-process, graphical debugger. That phrase is doing more work than it looks like.

Native means it uses platform debug APIs directly rather than wrapping GDB or LLDB. User-mode means it does not need kernel components or a driver. Multi-process means one instance can follow several processes at once, which is what a game engine actually looks like while it boots. Graphical is the part that sets it apart: memory inspection happens in a tree view you can click through, not in a text dump you scroll through.

The repo lives under the EpicGames organization, the code is C, and the license is MIT. It was created in January 2024 and had a push dated October 7, 2026, the day before this writing.

Why it exists

If you have debugged a large C++ codebase before, you know the pain. Attaching a debugger to a multi-gigabyte process can take minutes. The watch window becomes an unreadable wall of pointers. Finding the one object you care about means reading hex by hand.

RAD Debugger takes a different position on each of those. Attach speed matters when your iteration loop is measured in minutes. A visual object graph turns “find the player controller” into clicking a search box and typing a name. The tool is built for the case where you are inspecting live state in a process you cannot easily restart, which is the normal case in game development.

Metric	Value
Stars	7,875
Forks	384
Open issues	311
Language	C
License	MIT
Created	2024-01-10
Last push	2026-10-07

It is worth being clear that this is not a general-purpose replacement for a standard debugger. It is a specialist tool from a game engine company, and its strengths line up with engine-scale processes.

How to try it

The build is a standard C project with CMake:

git clone https://github.com/EpicGames/raddebugger.git
cd raddebugger

# configure and build with CMake
cmake -B build
cmake --build build

Once built, you attach it to a running target rather than launching under it:

# attach to a running process by pid
RADDebugServer --pid 12345

# or wait for a process by name
RADDebugServer --wait --name MyGame

The client then connects and you browse the object tree from there. A second server can attach to the same client, which is what the multi-process support is for.

When to use it

Reach for it when you are debugging a large native C or C++ process and you need to understand live object state rather than step through code. Game engines, large simulations, and long-running native services all fit that shape.

MIT licensing is the practical headline here. Commercial tooling that was previously locked inside a game studio can now be used, vendored, and modified without a business arrangement. That is a meaningfully different situation from most studio-internal tools.

When not to use it

It is not a replacement for lldb or gdb. If you want breakpoints, step commands, and disassembly, you still want a traditional debugger. RAD Debugger is strongest on inspection, not on low-level stepping.

It is C and C++ oriented. If you are debugging a managed runtime or a scripting layer, the object model will not line up with what you need.

Also expect platform friction. This is native debugger software built by a game studio for game development, so Windows support is the primary target and macOS and Linux are the secondary ones. Check the repo documentation for your platform before budgeting time to it.

Source and Accuracy Notes

• Project page: https://github.com/EpicGames/raddebugger
• Source repository: EpicGames/raddebugger (verified via GitHub API html_url)
• License: MIT (verified via GitHub API license.spdx_id)
• Stars at time of writing: 7,875
• GitHub API was queried unauthenticated for this post; the environment’s GITHUB_TOKEN returned HTTP 401