How to read a REDscope crash report

First crash

Start here

You do not need to understand the whole file. Read these five things in order. Stop when you have a testable lead.

Open the newest .crash file. The filename contains the crash date and time. Open it in any text editor.
Read the lead. LIKELY CULPRIT is REDscope's best lead. The confidence tells you how much weight to give it.
Check the evidence. Look for the same module in the Crash block and Native call stack. Check whether script code was really running.
Separate context from proof. Warnings, loaded DLLs, memory pressure, archive activity, and wrap counts can help. None of them proves a cause by itself.
Repeat the same action. Compare the next Crash ID, lead, stack, and game action. Repeated evidence is more useful than one report.

File location: red4ext/plugins/REDscope/crashes/. In Mod Organizer 2, look in Overwrite.

What deserves your attention

Evidence ladder

Start at the top. A clue near the bottom can support a lead, but it should not choose the culprit for you.

Strong evidence

The fault landed inside a mod DLL.
The same mod appears near the top of the crashing stack.
The same Crash ID, action, and stack repeat.

Supporting evidence

A script was executing when the fault happened.
A mod changed just before the crashes began.
The same item, menu, save, or action triggers it.

Context only

A DLL was loaded.
A warning appeared near the crash.
Memory pressure was elevated.
An archive operation was active.
A mod has many wrap chains.

Simple rule: the more independent clues agree, the better the lead. One nearby name is not enough.

Sanitized real report

One crash, explained

This example came from a real REDscope report. Personal details and unrelated mod names were removed.

REDscope crash excerptnative crash

LIKELY CULPRIT: mod (MEDIUM) - ArchiveXL.dll on the crashing stack
Exception : 0xC0000005 ACCESS_VIOLATION
Class     : native
Mod code on native stack:
  ArchiveXL.dll + 0x12C836
Last script on crashing thread:
  OnEnterScenario  NOT in flight at crash
OOM suspected   : false
Resource pressure: elevated, physical RAM low
Final packet status: text and JSON complete

ArchiveXL at medium confidence

What this says: ArchiveXL code was on the crashing thread while the fault surfaced in game code.
What this does not prove: It does not prove ArchiveXL itself is broken. A framework can be doing work for another mod.
What to do next: Check recent ArchiveXL-dependent mods. Repeat the same loading action before removing the framework.

Native crash

What this says: No RedScript frame was executing at the exact fault.
What this does not prove: It does not rule out a script or data mod. Earlier work can feed bad data into native code.
What to do next: Give the Native call stack more weight than the last script name.

Last script not in flight

What this says: OnEnterScenario was the last script REDscope saw on that thread.
What this does not prove: It was not running when the native fault happened. It is earlier context.
What to do next: Use it only if the same script and action repeat across reports.

Pressure is not OOM

What this says: Windows had less free physical RAM than REDscope's normal range.
What this does not prove: OOM suspected: false means REDscope did not see hard memory exhaustion.
What to do next: Create some headroom, but follow the stronger module and stack evidence first.

Read from top to bottom

The important sections

The top half usually gives you everything you can act on. The bottom half is there for the person debugging the mod.

`LIKELY CULPRIT`

REDscope's highest-ranked lead. HIGH is strong evidence. MEDIUM is worth testing. LOW is a weak clue.

game does not clear every mod. Mods can hand bad data to game code. A framework name can also mean it was carrying another mod's work.

Crash ID and Capture ID

Crash ID groups reports that look alike. Use it to spot repeats, but also compare the action and stack. Broad failures such as corruption can share a group.

Capture ID names one crash event and its matching files. Two files with the same Capture ID belong together.

Crash block

ACCESS_VIOLATION means code tried to use memory it could not use. Read, write, and execute tell you what it tried to do. You do not need to decode the address.

Class: scripted means RedScript was in flight. Class: native means it was not. Neither line names the guilty mod.

Capture packet

This says what REDscope saved. first chance means REDscope saw the exception early. A real game-ending crash can still show this when CDPR owns the later crash step.

Minidump: unavailable does not make the text report useless. It often means another crash handler owned that part.

`LAST ACTIVE`

innermost (executing) is script code that was running. NOT in flight at crash is only the last script seen on a thread before a native fault.

Match the function name to what you did in game. Give repeated matches more weight than one old function name.

Call stacks

The Native call stack is the chain of code on the crashing thread. The top is closest to the fault. A mod DLL near the top matters more than one far down the list.

The RedScript call stack shows script frames that were truly in flight. Raw Cyberpunk2077.exe + 0x... lines are normal. Most game functions have no public name.

Memory and engine state

Physical RAM is memory sitting in the machine. System commit is the total memory Windows has promised to every program, backed by RAM and the page file. Process commit is Cyberpunk's share of those promises. VRAM is GPU memory.

Resource pressure records reduced headroom. It remains context. Only OOM suspected is REDscope's near-exhaustion signal.

Recent logs and changes

Recent log activity is a time window. A warning near the crash may be unrelated. Look for a warning that repeats with the same action.

Mods changed since last launch is a useful shortlist. Start with a mod only when the crashes began after that change and the report points to the same area.

Setup and conflicts

Setup integrity checks for known installation problems. Curated conflicts list known combinations worth checking. These checks are separate from the crash itself.

no install problems detected means those checks passed. It does not prove every file and every mod is correct.

Final packet status

This is the last health check for the report. It tells you which parts reached disk.

Status	Meaning
complete	That part was saved.
partial	Some data was saved, but that collector did not finish its full result.
unavailable	REDscope could not collect that part in this crash path. Other parts can still be good.
failed	That collector hit an error. Use the parts marked complete.
pending	REDscope did not run or finish that collector. Check the other status rows before deciding why.

`engine-state.txt`

After the next launch, REDscope can match CDPR's crash data to the same event. It may add engine, GPU, save, and archive-operation context.

An active archive path tells you what the engine was touching. It does not prove that archive caused the crash.

Know what kind of report you have

Three report types

Do not look for a fault address in a report that never had one.

Caught crash

The game raised an exception and REDscope saved fault information. Read the lead, Crash block, stacks, and packet status.

Hang or freeze

The game stopped responding without an exception. There is no faulting address. Use the last active scripts, game state, and repeated action.

Unclean exit

REDscope found an unfinished session on the next launch. The report uses the last saved state. It cannot show a live crash stack that never survived.

Start with what you saw

Common situations

Pick the moment that matches your crash. Run the first test before making a large change.

Crash during startup

Check Setup integrity, framework load failures, the direct fault module, and recently changed native plugins.

First test

Undo the most recent plugin or framework update. Start the game again and compare the lead.

Crash while loading a save

Check whether the same save repeats it. Archive activity and last game state can narrow the area, but they are context.

First test

Load a different save from the same character. Then load the failing save again.

Crash in a menu or tooltip

Look for an executing RedScript frame tied to item hover, tooltips, inventory, or text formatting.

First test

Repeat the same hover or menu action. Note the exact item and compare the Crash ID.

Crash during gameplay

Write down the exact action: entering combat, driving, opening a door, changing equipment, or entering an area.

First test

Repeat that action once. Compare the direct module, stack, and Crash ID.

Game froze instead of closing

Use the Hang report. There is no exception to decode. Look for the same last active function across hangs.

First test

Repeat the action and wait for the watchdog once. Compare the last active scripts and game state.

No clear lead

One unknown report may not be enough. Build a repeat before blaming a loaded mod or a nearby warning.

First test

Undo recent changes first. If it still repeats, disable half of the remaining suspects and narrow from there.

Give the next person a clean handoff

Ask for help

A short reproduction is more useful than a guess about the cause.

Send

The matching .crash file.
The matching .crash.json file.
Other matching files only when the person investigating asks for them.

Say

What you were doing.
Whether the same action repeats it.
The Crash ID.
What changed before it began.

Read the files before posting them in public. The JSON includes your modlist and system details.

Open only what you need

Reference

The guide above is enough for most crashes. These sections cover installation, lower report sections, and mod-author details.

Install and file locations

Requirements

RED4ext
Cyber Engine Tweaks for the in-game panel
redscript for script-stack coverage

Install

Install REDscope through your mod manager like any other mod. There is nothing you must configure before it can write reports.

Files

Reports live in red4ext/plugins/REDscope/crashes/. Matching filenames belong to the same Capture ID.

What the lower report sections are for

Registers

Raw CPU values at the fault. A mod author may use them to follow bad pointers. Players do not need to decode them.

Process memory

Cyberpunk's working set, commit, virtual address space, and handle count. These measurements are context unless the report also identifies pressure or OOM.

Loaded modules

DLLs present in the process. Loaded does not mean responsible.

Installed mods

The text report gives a summary. The matching JSON contains the full list.

Wrap chains

RedScript methods modified by one or more mods. A high count is ambient setup context. A specific executing wrapped method is more useful.

Special crash words

Heap corruption

The game noticed damaged memory. The code at the final fault may be innocent because the damage happened earlier. Repeated action and recent native changes matter more than the last address.

Stack overflow

Code called too deeply, often through recursion. Look for the same frames repeating.

GPU device removed

Windows reset the graphics device. Test stock clocks, current or rolled-back drivers, and lower GPU load before blaming a gameplay mod.

In-page error

Windows could not read a memory-backed page. Verify game files and check the game drive if it repeats.

For mod authors

Native attribution

Native frames include the owning module and relative offset. Use the fault module, top stack frames, exception operation, and repeated fingerprint together.

Structured sidecar

The JSON sidecar keeps capture state, frames, module attribution, engine measurements, setup findings, mod changes, and the full mod inventory in machine-readable fields.

Live state from CET

Publish a small current value when it can explain a later crash. Updating a key replaces its old value.

local rs = GetMod("REDscope")
if rs then rs.SetState("MyMod.phase", tostring(phase)) end

Use stable keys and short values. State is context. It does not change culprit scoring by itself.