What each part of the .crash file means, and how to read it.
REDscope is a crash reporter for Cyberpunk 2077. When the game crashes it writes one plain-text .crash file that names the likely culprit and records the call stacks, engine state, what the game was loading, recent log errors, and which mods changed since your last working launch.
Install it through Mod Organizer 2 or Vortex like any other mod, or unzip the folders into your Cyberpunk 2077 directory. It should load ahead of any other crash-handler plugin. There is nothing to configure.
Each crash writes a .crash file (and a matching .crash.json) to red4ext/plugins/REDscope/crashes/. Under Mod Organizer 2 that lives in your Overwrite folder.
Open the .crash file in any text editor, or open the Cyber Engine Tweaks panel in-game to read the latest one without leaving the game. Once you have the culprit, disable or roll back that mod, or attach the file when you report the crash to its author.
The file is plain text, named by date and time (REDscope-2026-06-23_20-10-15.crash). Read it top to bottom and stop when you have what you need. The top sections usually answer it; the hex dumps near the bottom are for mod authors.
LIKELY CULPRIT lineThe first line is REDscope's best guess:
LIKELY CULPRIT: game (MEDIUM) - icuuc.dll!icu_65::UObject::UObject+0x1817The word in parentheses is confidence: HIGH means start with whatever it names, MEDIUM is a lead worth checking, LOW is a weak hint. The word after it is who it blames. A mod .dll name (for example Mod ArchiveXL.dll+0x8124) means that mod is the suspect.
This example says game, meaning the fault landed in Cyberpunk's own code or a Windows library.
"game" does not rule out a mod. Mods run through the game's code, so a mod can trigger a fault that lands in the engine. When you see
game, check the native call stack for mod.dllnames and check what your scripts were doing.
The CRASH ID below it is a fingerprint of this specific crash. The same crash produces the same ID, which tells you whether a fix worked and is worth quoting in a bug report.
Crash blockException : 0xC0000005 ACCESS_VIOLATION
Fault data: write at 0x00000056C7223FD8
region: FREE -> unmapped; dangling ptr / garbage
Class : scriptedACCESS_VIOLATION is the most common type: the game used memory it wasn't allowed to.region: FREE means it reached for something already thrown away, not that it ran out of memory.Class: scripted means script code was running at the time, which points toward a mod.You don't act on the addresses. The summary you want for a bug report is the type: "access violation, dangling pointer, during scripts".
REDscope : 0.1.0
RED4ext : 1.30.0.0
Cyberpunk : 3.0.80.51928If the Cyberpunk version doesn't match what your modlist expects, that mismatch can be the whole problem. Worth a glance after a game update.
LAST ACTIVEWhat script code was running on each thread at the crash:
Scripted code (per thread):
[CRASHING] tid=12820 OnItemDisplayHoverOver (-00.008s ago)
...The [CRASHING] line is the one that died. Here it is OnItemDisplayHoverOver, which runs when you hover an item, so the crash happened while hovering something in a menu. Below it:
Mod code on native stack (crashing thread):
(none - native stack contains no frames in installed mod DLLs)This says no installed mod .dll was directly on the crashing thread. With "hovering an item" from the line above, the likely suspect is a script or UI mod that changes item tooltips or the inventory, even though no native .dll showed up. Match the [CRASHING] name to an in-game action and try to reproduce it.
Live game statecombat no
menu Hub
district Watson / NorthsideWhere you were and what you were doing, plus your graphics settings. The top few lines place the crash; the graphics list matters mainly when a setting like Frame Generation or Path Tracing is involved in a graphics or VRAM crash.
Mods changed since last launchLast launch: 2026-06-23 19:10:38 (541 mods tracked)
+1 added:
REDscope v0.1 0.1.0.0A diff against the last time you played. If a mod was added, updated, or removed and the crashing started right after, that's your first suspect. "No changes" means an existing setup, not a new mod.
Native call stackThe long numbered list. Skim it for one thing: mod .dll names. Each line is a step in the chain of code that was running, newest at the top.
Cyberpunk2077.exe + 0xSOMETHING are the game's own code. Only about 84 of its functions are named in the public database, so the rest show as raw offsets. That is normal, not a defect..dll from a gameplay or UI mod is your lead.If the only non-game names are framework DLLs (CET, RED4ext, Codeware, ArchiveXL, REDscope), the native stack won't name the culprit on its own. Fall back to LAST ACTIVE and the mods-changed diff.
Engine state (at crash)GPU memory : 6629 / 11997 MB used (budget 11229 MB)
OOM suspected : falseThis answers whether the game ran out of memory. OOM suspected: true, or GPU memory near the maximum, means lower your settings (texture quality, ray tracing, path tracing, frame generation) or trim heavy texture mods. That's a resource problem, not a broken mod.
Resource streaming at crashGame files that failed to load or were still streaming when it crashed. REDscope looks each one up in the path dictionary that ships with the mod:
Failed to load (792 this session):
base\localization\en-us\vo\judy_sq030_f_136656bf.wem
0xDB8DF92FE7746657 (missing or modded path)
...Base-game files resolve to a path. Anything the dictionary doesn't contain shows the hash with a label: (missing or modded path) for a failed load, (modded or dynamic path) for one still streaming. Modded asset paths can't be reversed from a hash, so on a heavy modlist expect a mix of paths and labeled hashes. When a resolved path lines up with the crash, that file's mod is worth a look.
Setup integrityInstall problems found independently of the crash. The main one is loose files: mod files sitting directly in your game folder instead of being managed by your mod manager, which silently override your setup. If any are found they're listed here; otherwise it reads (no install problems detected). The same check runs before launch through tools/check-clean-install.ps1, which writes a report without starting the game.
System and Installed modsSystem is your hardware, drivers, and OS; check the GPU driver and free RAM if crashes are frequent. Installed mods is a one-line count plus your manager and profile, with the full per-mod list in the .crash.json next to the report. Loaded modules lists the actual DLLs with versions, sorted into Mod, Game, and System. Attach the .json when you report a crash; it's the complete modlist.
Registers, Stack memory, Process memory, and Wrap chains are detail for the mod author. Wrap chains is the one a player might read: it lists which mods modify the most game functions, so if the crash is in an area one of them touches, that's a hint. Attach the whole .crash file when reporting; the author needs these.
| Question | Section |
|---|---|
| What's the one-line answer? | LIKELY CULPRIT |
| Did a mod I just installed do it? | Mods changed since last launch |
| What was I doing? | LAST ACTIVE and Live game state |
| Is a specific mod named? | Native call stack |
| Did I run out of video memory? | Engine state |
| Which mod's file failed to load? | Resource streaming |
| Loose files in my game folder? | Setup integrity |
When reporting a crash, attach the .crash file and the .json next to it. And remember that Cyberpunk2077.exe + 0xNUMBERS with no name is normal.
REDscope matches crashes against known signatures and groups each by the kind of problem it points to. Find the entry matching your LIKELY CULPRIT and follow the fix.
Resource, driver, or setup problems. The fix is settings or hardware, not disabling one mod.
Out of video memory: GPU memory at or near your card's total, OOM suspected. Lower texture quality, ray tracing, path tracing, and frame generation, and trim heavy texture mods.
Out of system memory, OOM suspected. Close background apps, raise your Windows page file, reduce memory-heavy mods, add RAM if it recurs.
The driver stopped responding and Windows reset it. Update or cleanly reinstall the GPU driver, drop any overclock, lower settings, and check for overheating.
The fault landed in a GPU driver DLL (for example nvwgf2umx.dll or amdxc64.dll). Update or cleanly reinstall (DDU) the driver, remove overclocks, and roll the driver back if the crash started right after an update.
The fault landed in an upscaling library (nvngx_dlss.dll, an FSR library, libxess.dll). Turn off Frame Generation or switch the upscaler. If you hand-swapped DLSS or FSR DLLs, restore the versions the modlist ships.
A required dependency (RED4ext, Codeware, ArchiveXL, TweakXL) wasn't loaded. Install or repair it, confirm it loaded, and check load order and version.
Corrupted or mishandled memory. A mod can cause these, but the signature describes the failure, not the culprit.
Something wrote where it shouldn't have. Usually a mod writing bad data: bisect the modlist (disable half, test, narrow down) and keep frameworks current.
Code wrote past a stack buffer and tripped the security check. Bisect the modlist, update frameworks, and report it to the author with the .crash file.
The system couldn't read a memory page from disk, often failing storage or a corrupted file. Verify the game files, check the drive's health and free space, and re-download any mod whose files may be corrupted.
The engine's own behavior, often set off by script code.
Code called itself until it ran out of stack, usually shown by the same frames repeating. Use those frames and the scripted stack to find the area, then disable the mod that touches it.
The fault landed in the text library (icuuc.dll / icuin.dll) with script code running. Suspect mods that change tooltips, descriptions, or UI text. Reproduce by hovering items, then disable tooltip and inventory mods one at a time.
The crash fired in the item-hover code (such as OnItemDisplayHoverOver) with the class scripted. Almost always an inventory or tooltip mod reacting to a specific item. Hover items to find the trigger and disable tooltip mods until it stops.
Signatures that match a situation but can't name a confident culprit.
The crash happened while the game was still starting (scripts not yet loaded). Usually load order or a framework problem: confirm frameworks are installed and current, check load order, and bisect recent additions.
The game stopped responding, caught by the hang watchdog rather than a crash. The stuck scripted frames show the area; disable the mod that touches it. If it lines up with heavy streaming or memory pressure, treat it with the memory steps above.
topA REDscope .crash gives you three things without a minidump or symbol server.
Every native frame is tagged with its owning module, so a fault in your DLL shows as YourMod.dll + 0xOFFSET instead of an anonymous address. Game frames mostly show as Cyberpunk2077.exe + 0xOFFSET (only about 84 engine functions are named in the RED4ext address database), so the signal is which module faulted. If your code was running, the RedScript call stack shows the scripted frame that was live on the crashing thread, even when the fault is deep in a vanilla function you wrapped.
REDscope scans @wrapMethod annotations across every installed .reds file and reports the wrap chains, plus a top-mods-by-wrap-count summary. If your mod and another both wrap the same vanilla method, that's visible in the report.
REDscope keeps a ring of recent breadcrumbs and prints the last entries next to the call stacks. Add your own for the moments that matter: menu opens, feature toggles, or right before and after an operation you suspect. The tag is capped at 15 characters and the message at 111, so put the important part first. Use a short, stable mod name, and note the call does nothing when REDscope isn't installed.
RedScript (the native is module REDscope; tag is a String):
REDscope.Crumb("MyMod", "ApplyEffect target=" + ToString(target.GetID()));CET / Lua (reach it through GetMod):
GetMod("REDscope").Crumb("MyMod-CET", "setting toggled: " .. tostring(key))