Hot swap patch: research

Asked for by the owner on 2026-10-22, after H2 was parked (World API, “H2 parked”). The goal: a swap of an archive into the running game after which everything that uses its files shows the new version at once, worn clothing included, without crashing. That may mean holding the game’s threads during the swap, or replacing game objects so REDnode controls when they change. This page gathers what is known, what is not, and the phases to find out. Nothing here is built yet.

Phases are named HP0 to HP5 (hot swap patch). Each ends with an in-game test, as everywhere in REDnode.

What a swap does today

The sound work is the model for this research: read the engine statically, prove the reading with read-only probes, then hold the one thread that owns the data and change it at a safe point.

What H2a found

The crashes of 2026-10-22

Six crash reports from the laptop (game 2.31, RTX 3070 Laptop with 8 GB, 16 GB RAM, texture quality Medium, then High), with the player’s two new trouser versions, between 10:06 and 10:21. The player started the game twice by a double click more than once that morning. Each report names the time its process started (in the attached log’s name), which shows the pairs. In each dump the crashing thread is the game’s crash reporter, so the stacks say little; the reports and REDnode’s logs say more.

The reading: every crash of that morning is explained by two copies of the game sharing the 8 GB of graphics memory, or comes in a session with no swap. Even the GPU crash after the swap came in the same second as the second copy’s out-of-memory crash, so it most likely ran out of graphics memory too (unverified: the swap loading new textures may have tipped it over). So there is no clean evidence yet of a crash caused by a swap. The earlier H2a crashes (2026-10-21, at the first swap of some sessions, with the Fia leggings mod installed) left no reports, so whether a second copy ran then is not known.

A small REDnode change would make this visible next time: the plugin can tell when another copy of the game is already running (a named mutex) and say so in its log and on screen. Proposed, not agreed.

The engine’s pieces

Names follow the RED4ext SDK and the game’s RTTI where they exist. How they hold each other is unverified and is what HP1 maps.

Phases

HP0 can run now. HP1 to HP4 are research on game 2.31; each one’s findings decide whether the next is worth doing.

Rules

Risks

HP0 test

On the laptop, game 2.31. No swap in this test: it rules out the archive’s own content. Make sure only one copy of the game runs (Task Manager shows one Cyberpunk2077.exe).

1. Switch on Test timer in the launcher, press Start, and press Mark after each step.
2. With the game closed: put EDGEmatB.archive (the version swapped at 10:08) in archive\pc\mod, and only it: no other version of the trousers, archive\pc\hot empty.
3. Start the game and load the save wearing the trousers. Mark.
4. Play for two minutes, looking at V’s legs now and then. Mark.
5. Quit. If the game crashed, send the crash report folder (%LOCALAPPDATA%\REDEngine\ReportQueue\).

A crash here, with no swap, points at the archive’s content. No crash points back at the swap.

HP0 test: results

2026-10-22, on the laptop. The player loaded a save with each of the two new trouser versions installed normally, one at a time, with no swap. Both worked, with no crash. So the archives’ content is fine, and a crash with them would come from the swap. Next in HP0: swap runs with only one copy of the game open (the clean archives test in World API, “H2a clean archives: test (runs 1 and 2)”).

HP0: a swap crash with one copy of the game

2026-10-22 at 11:02, on the laptop after a reboot, one copy of the game (a copy of the 2.31 install, Cyberpunk 2077 - Copy), REDnode 0.26.16, Refresh test 0.2.3. The clean archives test, step 2: the first swap, of EDGEmatA.archive, in gameplay. An earlier try at 10:23 crashed at the same step, and its fault watch line is the same.

What it shows:

• The game died inside RED Hot Tools’ load of the new archive, the step that calls the game’s own ResourceDepot::LoadArchives on the game thread. It is the same place as the H0 crash (2026-10-18), the first H2a crash (2026-10-21) and H1c-2’s first run.
• Nothing caught it: no fault reached REDnode’s handler, the game’s crash reporter wrote nothing, and the game did not call its own exit. That is the mark of a fail-fast (Windows ends the process at once on heap corruption or a failed security check, code 0xC0000409 or 0xC0000374) or of a process ended from outside. Unverified which.
• It is not memory: the game ran at 43 fps for a minute before, and a lack of memory fails through the game’s own reporter.

Open, to settle next:

HP0: the control run

2026-10-22 at 11:23, on the laptop, one copy of the game, REDagent off. Yesterday’s EDGEmat_M3.archive (the leather look installed, the base look swapped in), which passed nine replaces on 2026-10-21, crashed at the first swap, the same way: the fault watch started at 11:23:34.710, and the plugin log ends there. So the new archives are not the cause; something in the setup changed.

The game folder is the clear difference: every crash of the morning ran in the copy. How a copied folder could make the archive load die is not known (another mix of mods or plugin versions in the copy, or something in it that was not copied, are guesses). Next: the same swap in the main folder, and the two sessions’ RED4ext logs compared.

A Windows dump of the 10:09 GPU crash (Cyberpunk2077.exe.42248.dmp, from Windows error reporting) has a real stack: only the game’s own code, the render side’s check that found the device removed. No mod’s module is on it.

HP0: who ends the game (REDnode 0.26.17)

The crashes inside the archive load leave no fault, no crash report and no exit line. If Windows error reporting’s dump setting was on and still no dump came, the game was most likely ended by a TerminateProcess call, which Windows does not report. REDnode 0.26.17 (asked for by the player on 2026-10-22) names it:

HP0 run with 0.26.17: test

On the laptop, in the Cyberpunk 2077 - Copy folder, one copy of the game, REDnode 0.26.17 (the update zip over 0.26.16), REDagent off.

1. Switch on Test timer in the launcher, press Start, and press Mark after each step.
2. With the game closed: the leather EDGEmat_M3.archive in archive\pc\mod, no other version, archive\pc\hot empty. Start the game, load the save wearing the trousers. Mark.
3. In Refresh test, swap the base look EDGEmat_M3.archive. Mark if the game is still running.
4. Send rednode-faults.log, the plugin log of the session (its line “Faults: exit hooks attached” matters), the RED Hot Tools log, and any new dump in %LOCALAPPDATA%\CrashDumps.

HP0: the game ends itself (0.26.17 run)

2026-10-22 at 11:42, on the laptop, the Cyberpunk 2077 - Copy folder, one copy of the game, REDnode 0.26.17, the control swap (EDGEmat_M3.archive, the leather look installed at start, the base look swapped in). The exit hooks attached, and the fault log has the answer:

11:42:27.636 watch for 15 s: swap of EDGEmat_M3.archive (the game thread is 29036)
11:42:27.681 the game is being ended by TerminateProcess, status 0x00000001, on thread 29036 (the game thread)
  stack: REDnode.dll (the hook) <- KERNELBASE.dll <- Cyberpunk2077.exe+0x29cea69 <- Cyberpunk2077.exe+0x7bbc29
         <- RedHotTools.dll+0x50e5a <- +0x552d0 <- +0x64ec9 <- Cyberpunk2077.exe (the script call) <- ... <- REDnode.dll (the swap call)

A static reading of the 2.31 exe (the helpers stay in the scratchpad):

So the swapped archive failed the engine’s own checks at the moment of the swap, and the engine quits on purpose. The same files load fine at start (HP0 test), so the engine read something at the swap that does not match the file on disk. A lead to test (unverified): the size check compares the archive’s header with the size its reader reports; if the reader is a reopened handle (RED Hot Tools reopens the old archive’s handle before the load) that still reports the old file’s size, two versions of different sizes fail and two of the same size pass.

The four test archives, read on the dev PC with the engine’s header checks (a scratchpad script, not committed):

Every file passes on disk, and the two versions of each pair differ in size, which fits the lead of a reader reporting the old size. The two EDGEmatA versions share only 2 of their 9 paths, so they are not the “same file list” pair the H2 tests assumed.

The check’s error numbers (2.31): 1, the header is wrong for the file (under 4 KB, not RDAR, the header’s size differs from the reader’s, the index past the end, not 4 KB aligned); 2, an unsupported version; 4, the header or the index could not be read; any other number comes from the index’s own parse (+0x7bd31c). The number in the engine’s message would tell a size mismatch (1) from a dead file handle (4).

The player adds (2026-10-22): the EDGEmat_M3 archives were rebuilt for other EDGEmat tests after 2026-10-21, so today’s two versions are not the files that passed nine swaps that day. Yesterday’s passes therefore do not count against the size lead. Next, a test with no new build: install EDGEmatA.archive version 1, swap the identical file (same size), then version 2 (a different size). If the identical swap passes and version 2 ends the game, the size lead holds.

HP0: the identical file fails too; REDnode 0.26.18

2026-10-22 at 11:56: a swap of EDGEmat_M3.archive with the same file that was installed (the player) ended the game the same way (TerminateProcess(1) from the engine’s fatal quit, after the archive load). The sizes matched, so the size lead is out.

REDnode 0.26.18 adds the engine’s own message to the fault log. The engine’s assert reporter (+0x29ce848 in 2.31) formats every assert message into one 1 KB buffer (+0x3b268f0) before the fatal quit. The plugin finds the buffer by the reporter’s lea (one match in 2.31; none or several turn it off) and, when the game is ended during a watch, writes “the engine’s last message: …” under the stack: for this failure, the archive’s path and the error number (1 a header that does not fit the file, 2 a version, 4 a read that failed).

HP0 run with 0.26.18: test

On the laptop, Cyberpunk 2077 - Copy, one copy of the game, REDnode 0.26.18 (the update zip over 0.26.17).

1. Switch on Test timer in the launcher, press Start, and press Mark after each step.
2. With the game closed: one EDGEmatA.archive (version 1) in archive\pc\mod, archive\pc\hot empty. Start the game, load the save. Mark.
3. In Refresh test, swap version 1 itself (the identical file). Mark if the game is still running.
4. Send rednode-faults.log (its last lines carry the engine’s message) and the plugin log (its line “the engine’s message buffer found”).

HP0 run with 0.26.18: results

2026-10-22 at 12:15, on the laptop, Cyberpunk 2077 - Copy, REDnode 0.26.18, the identical EDGEmat_M3.archive swapped over itself. The plugin log: “the engine’s message buffer found”. The game was ended the same way, and the fault log now carries the engine’s words:

the engine's last message: Failed to load archive C:\Program Files (x86)\Steam\steamapps\common\Cyberpunk 2077 - Copy\archive\pc\mod\EDGEmat_M3.archive, error 1, try regenerating archives!

Error 1 with a file that passes every check on disk, and an identical file at that, means the reader the engine used reported something other than the file: most likely a size of 0, the first check (a reader whose file handle is closed reports no size). A lead from RED Hot Tools’ source (MIT, ArchiveLoader.cpp), unverified:

lower_bound with strcmp finds the entry only if the engine keeps the mod archives in strcmp order (case-sensitive: every uppercase letter before every lowercase one). If the engine orders them another way, such as case-insensitively, the search can miss an archive whose name starts with uppercase letters (EDGEmat_M3, EDGEmatA) among names that start with lowercase ones. Its handle then stays closed, and the engine’s load reads through it and fails with error 1. Whether it misses depends on the other archives’ names around it, which would explain why a swap of the same name can pass in one setup and fail in another.

Next, a test with no new build: the same file under a name that sorts the same both ways, such as zzz_rednode_test.archive (after every other name, case-sensitive or not).

HP0: the name test

2026-10-22 at 12:21, on the laptop, Cyberpunk 2077 - Copy, REDnode 0.26.18. EDGEmatA.archive version 1 renamed zzz_rednode_test.archive, alone in archive\pc\mod:

The same swaps under the names EDGEmat_M3.archive and EDGEmatA.archive ended the game every time in this setup. Only the name changed, which supports the lookup lead: RED Hot Tools’ FindArchivePosition (lower_bound with strcmp) misses an archive whose name sorts differently case-sensitively and case-insensitively among the other mod archives, so its closed handle is never reopened and the engine’s load fails with error 1. Still unverified: the engine’s own order of the mod archives (to be checked against the folder’s file names).

After that, the player pressed Reset look (nothing changed) and then Re-attach (RefreshAttachment), which crashed the game with a crash report at 12:24:34: an access violation reading address 0x1EC (a null pointer plus an offset), at 0x7ff7734a0ac4, about 128 KB below the game exe’s start, where hooking libraries put their trampolines, so inside some mod’s hook. The dump holds too little of that thread’s stack to say whose. A separate crash, on H2’s side: refreshing a worn item after a swap. Kept for H2.

HP0: the lookup, simulated

The laptop’s archive\pc\mod in Cyberpunk 2077 - Copy (2026-10-22): ###_nim_material_override, basegame_hud_minimap_scanner_tweak, clothing_Fia_00Leggings, EquipmentEx, instant_wardrobe, LimitedHUD, SkippySkippy (.archive), plus .xl files and modlist.txt. RED Hot Tools’ FindArchivePosition simulated over that list with each test archive added (a scratchpad script):

With a case-insensitive order (Windows’ own), the simulation matches every result of the day: both EDGEmat names fail, zzz_rednode_test passes. In strcmp, every uppercase letter sorts before every lowercase one, so EDGEmat... belongs before basegame...; in Windows’ order it sits after clothing_.... lower_bound therefore stops on the wrong entry, RED Hot Tools does not reopen the closed handle, and the engine’s load fails with error 1.

Still open: why the EDGEmat_M3 swaps of 2026-10-21 passed in the main folder (the folder’s other archives, or modlist.txt, may have differed then), and the engine’s exact order rule (case-insensitive is inferred, not read from the exe).

RED Hot Tools’ current source (1.3.0-rc.3, 2026-10-20) still uses this lookup, and its issues have no report of it (checked 2026-10-22). The fix there is small: find the archive by comparing paths one by one (or case-insensitively, as the engine orders them), for both the reopen and the insert.

HP0: a fix in RED Hot Tools

Agreed with the player on 2026-10-22: fix RED Hot Tools locally and test the fix in the game before reporting it upstream. Built from v1.3.0-rc.3 (the current release) with xmake, as in dev setup, section 11, in a clone beside the other repos, branch fix/archive-lookup:

The unchanged rc.3 build is kept in the scratchpad as a control. The fixed DLL went to the laptop as RedHotTools-1.3.0-rc.3-lookupfix.zip.

HP0: the fix’s test

On the laptop, Cyberpunk 2077 - Copy, REDnode 0.26.18, the fixed RedHotTools.dll in place of the installed one (backed up first).

1. Switch on Test timer in the launcher, press Start, and press Mark after each step.
2. With the game closed: back up red4ext\plugins\RedHotTools\RedHotTools.dll, then put the fixed one in its place. Put EDGEmatA.archive version 1 in archive\pc\mod (the uppercase name that failed), take out zzz_rednode_test.archive, empty archive\pc\hot. Start the game once, load the save. Mark.
3. In Refresh test, swap EDGEmatA.archive version 1 itself (the identical file). Mark if the game is still running.
4. Swap EDGEmatA.archive version 2. Mark.
5. Swap version 1 again. Mark.
6. Quit. Send rednode-faults.log, the plugin log and the RED Hot Tools log.

HP0: the fix’s test: results

2026-10-22 at 12:47, on the laptop, Cyberpunk 2077 - Copy, REDnode 0.26.18, the fixed RedHotTools.dll, EDGEmatA.archive (the name that ended the game every time before). Passed: four swaps, each logged by RED Hot Tools through “Archives reload completed.” and each with 0 faults, then a clean quit.

So the swap crashes of 2026-10-22 came from RED Hot Tools’ archive lookup, and finding the archive by its exact path fixes them. What it means:

The Edgemodders build of RED Hot Tools, and REDnode’s guard

Agreed with the owner on 2026-10-22: fork RED Hot Tools to the owner’s account, ship the fixed build to players for now (further fixes and changes are expected), and offer the fix upstream.

The Edgemodders build and the guard: test

On the laptop, Cyberpunk 2077 - Copy, game 2.31, REDnode 0.26.19 (update zip over 0.26.18).

1. Switch on Test timer in the launcher, press Start, and press Mark after each step.
2. With the game closed: put the official RedHotTools.dll back (the backup). EDGEmatA.archive version 1 in archive\pc\mod. Start the game once, load the save. Mark.
3. In Refresh test, swap EDGEmatA.archive version 1. It should be refused with a message naming RED Hot Tools, and the game should keep running. Mark.
4. Quit. Extract RedHotTools-1.3.0+edgemodders.1.zip into the game folder (it replaces the official files). Start the game, load the save. Optional: in CET’s overlay, a RED Hot Tools window (Hot Reload, World Inspector or Ink Inspector) has a ⋯ button at its top right; About there shows Plugin Version: 1.3.0+edgemodders.1. The host log also names the version at each swap (“RED Hot Tools 1.3.0+edgemodders.1”). Mark.
5. Swap EDGEmatA.archive version 2, then version 1. Both should swap. Mark.
6. Quit. Send rednode-mods.log, rednode-overlay.log, the plugin log and the RED Hot Tools log.

The Edgemodders build and the guard: results

2026-10-22, on the laptop, Cyberpunk 2077 - Copy, REDnode 0.26.19. Passed.

The release followed the same day: RED Hot Tools 1.3.0+edgemodders.1 on the fork, with the player zip.