Crimson Desert: startup crash investigation and GPU stability follow-up

September 18 update: what fixed my PC

The later black screens and restarts stopped after I repaired the household electrical supply to the PC. I found a cable getting hot in the house wiring/outlet supply, switched off the breaker and repaired the installation. This was outside the computer, not its internal PSU cables.

This is Nathan's follow-up to the September 8–9 startup investigation below. There were two failure patterns: Crimson Desert crashing before gameplay, and the PC later losing video or restarting while games were running. The electrical repair resolved the remaining crashes in my use. The original VKD3D comparison concerns the startup failure.

Relato em português — Markdown para compartilhar.

What the later failures looked like

Games ran smoothly until video disappeared or the machine restarted. This happened in Crimson Desert, Like a Dragon: Infinite Wealth and Assassin's Creed Black Flag Resynced. Sometimes audio kept playing and Num Lock still responded after video was lost. Other failures ended in a restart.

On September 15 (UTC−03:00), the Linux log recorded this sequence:

11:15:52  device lost from bus!
11:15:52  TransferTableSmu2Dram ... response:0xFFFFFFFF
11:15:53  ring gfx_0.0.0 timeout
11:15:56  GPU Recovery Failed: -19

The GPU had stopped responding to PCI configuration reads before the timeout and failed recovery. The log identified the failure, but did not identify the household wiring as its cause.

What we checked before finding it

The machine has a Ryzen 7 5800X, Gigabyte X570 AORUS PRO WIFI rev. 1.1, XFX RX 9070 XT Swift and Corsair HX850 PSU. Troubleshooting covered Windows and Ubuntu.

Windows WHEA 0x124 and Linux MCEs were also investigated. Several Linux events were reported by physical CPU cores 6 and 7, with IFU/Poison errors and process termination. Those records remain part of the history; they do not, by themselves, establish which component was faulty.

Result after the repair

Since repairing the house wiring/outlet supply, I have reported stable use, including leaving a game in the background and switching between it and other applications. The settings I kept were Curve Optimizer +12 and XMP memory at 1.39 V. These are my machine's settings, not recommended values for another PC.

The electrical repair was the fix for the remaining crashes in my case. CPU and memory settings also changed during troubleshooting, so this does not assign every earlier WHEA/MCE event to the cable. A GPU timeout alone is not a diagnosis of a defective graphics card.

The original startup investigation follows, including its patch, binary comparisons and unresolved cache control. Its requested follow-up tests remain unperformed; the electrical repair did not supply those missing software comparisons.

Investigated over many hours on 8–9 September 2026. Times below use UTC−03:00 unless specified.

Summary

Crimson Desert crashes during shadow-renderer setup with the vkd3d-proton pair distributed in Proton 11.0-2c. The game dereferences a null pointer at CrimsonDesert.exe+0x3b39c34: exception 0xc0000005, read address 0x30, RBP=0.

The same crash occurs with both the official Stable DLLs and a locally rebuilt unmodified Stable pair inside an otherwise unchanged Proton Experimental installation. A local adaptation of the upstream Crimson Desert View Instancing capability gate passes startup and reaches interactive gameplay. Full Proton Experimental also works with the tested small BAR.

Causality remains unresolved: the patched build also changes VKD3D's generated build/cache identity. A cache invalidation effect has not been excluded, and the reused application prefix introduces an order/state confound. The engine's exact reason for producing the null shadow-pass pointer is unknown.

Expected: startup and shadow initialization complete, or an unavailable rendering capability/pass is handled without dereferencing null. Actual: repeatable CPU access violation at the same instruction in the failing configurations.

Environment

Component revisions read from the installed distributions:

The Wine vkd3d component is distinct from the native vkd3d-proton d3d12.dll/d3d12core.dll pair tested here. Game, redistributables, Proton Stable and Runtime 4 passed Steam integrity validation (No Error).

Linux experiments

The upload-heap and nosam flags are not equivalent to a measured PCIe BAR change. Stable still failed after BAR0 was actually reduced. Full Experimental with large BAR, a reduced graphics preset, matched cache/build-ID controls and A→B→A reversal were not tested.

The original/restored settings XML SHA-256 was 5b629d9827ac19c57e109f1013375f94a7c8fc1b3097a9a7c64bbd31b5e658c1.

Controlled VKD3D comparison

The three component cases used an independent copy of Experimental. Only its x64 pair at files/lib/wine/vkd3d-proton/x86_64-windows/{d3d12,d3d12core}.dll was replaced. Wine, AMD AGS, DXVK/DXGI, the x86 pair, runtime, game executable, Ultra settings, driver and small BAR were fixed. The game's Agility SDK copy at bin64/d3d12/d3d12core.dll was unchanged.

Pair hashes were checked in the isolated tool for each case. Proton copies that pair into the prefix's system32 and selects native DLL overrides; the patched pair was additionally hash-checked there. Live prefix hashes were not recorded for the two failing cases. The clean build identifier is shared by the official and rebuilt baseline, so that log string alone does not distinguish their binaries.

Patched gameplay included NPC reaction, weapon drawing and switching to another desktop application. At 20:46:01 the process had been alive for about 11 minutes 19 seconds, with no matching access violation in the captured log. This establishes limited gameplay success, not an FPS benchmark or prolonged stability result.

Build/cache identity confound

The generated headers differ:

Unmodified baseline: vkd3d_build = 0x212991fc2c266bc
Patched dirty tree:  vkd3d_build = 0x212991fc2c266bc0

libs/vkd3d/cache.c rejects cached blobs with a different build identity using D3D12_ERROR_DRIVER_VERSION_MISMATCH; the identity also participates in cache headers/keys. The patched build can therefore reject/recompile data accepted by the baseline. The same mutable prefix and caches were reused sequentially, without matched cold-cache runs or reversal. The result is consistent with the View Instancing workaround but does not isolate it from cache invalidation.

Tested x64 DLL hashes

Crash and shadow-pass analysis

Addresses refer to the executable SHA-256 above, image base 0x140000000. Function labels are descriptive or recovered from diagnostic strings; private C++ symbols were unavailable.

Exception:    0xc0000005, read 0x30
Instruction:  0x143b39c34
RBP:          0
Return chain: 0x143ade421 -> 0x143adc38b -> 0x143adb65f

The RenderShadows caller at 0x143addb90 passes [render_object+0xe40] in R8 to helper 0x143b39ae0:

0x143ade326: mov r15, qword ptr [rbx + 0xe40]
0x143ade413: mov r8, r15
0x143ade41c: call 0x143b39ae0
; inside the helper:
0x143b39b01: mov rbp, r8
0x143b39c34: mov edx, dword ptr [rbp + 0x30]

This is a CPU NULL+0x30 read, not a Vulkan device-loss report. Static object identity follows vtable 0x145c0b1b8: slot 0x145c0b2c0 points to 0x143adb0f0, which preserves this through 0x143adbec0 into the caller. Constructor 0x143ac1a80 writes that vtable and initializes the subobject at this+0x9c8 via 0x143ac2150. Its later trampoline was not decoded.

Populator 0x143ac4650 calls 0x143aed820 with the subobject, manager from [render_object+0x530], and configuration-like object from [render_object+0x550]. The callee resolves SceneCharacterShadowBindless0 (string at 0x145c0d8f0) and performs this lookup:

0x143af1f5b: call 0x14122ff40       ; interned integer name ID
0x143af1f6d: mov eax, dword ptr [0x146f84a4c]
0x143af1f76: lea rcx, [rbx + 0x40] ; manager table
0x143af1f7e: call 0x143835c70       ; named-entry lookup
0x143af1f83: test rax, rax
0x143af1f86: je   0x143af1f8d
0x143af1f88: mov  rax, qword ptr [rax]
0x143af1f8b: jmp  0x143af1f90
0x143af1f8d: mov  rax, r13          ; r13 = 0
0x143af1f90: mov  qword ptr [rsi + 0x478], rax

The destination is render_object + 0x9c8 + 0x478 = render_object + 0xe40. Adjacent fields name SceneCharacterShadowBindless and SceneCharacterShadowBindless1.

0x143835c70 is a hash-table lookup: table offsets +0x00/+0x04 hold bucket/entry counts, +0x10/+0x18 hold bucket/entry storage; bucket stride is 0x200, entry stride 24 bytes. Entries contain name ID at +0x08 and stored pointer at +0x10. A match returns the address of the stored pointer; no match returns null. Equivalent dataflow:

int id = intern_name("SceneCharacterShadowBindless0");
void **slot = lookup_named_entry(manager + 0x40, id);
void *pass = slot ? *slot : nullptr;
store_pointer(render_object + 0xe40, pass);
// Later, RenderShadows forwards that member to setup_shadow_pass:
uint32_t field = load_u32(pass + 0x30); // observed fault with pass == nullptr

This identifies a route to the null read, but not whether the key was absent, its stored value was null, or another writer changed the field. No failing D3D12 HRESULT or exact private object type is established.

A later branch at 0x143af2c1e references ViewInstancing and tests bit 0 of the configuration-like object's +0x94; it configures a different pass at subobject +0x1a8. The faulting helper also uses the interned ViewInstancing setting. These references do not prove which branch creates SceneCharacterShadowBindless0.

Missing dump bytes

The official-Stable-pair dump was 1,057,160,744 bytes, with 310 MemoryList ranges, exception thread 656, RSP 0x4092f910, return address 0x143ade421 and saved caller RBX 0x5479caa7000. Stack offsets were checked against the helper prologue: return address at RSP+0x68, saved caller RBX at RSP+0x70. The exception thread's stack descriptor matched a MemoryList range, and captured ranges fit within the file.

The render object's bytes, manager, +0xe40 member and name-ID bytes at 0x146f84a4c were absent from MemoryList. MemoryInfo described committed mappings without supplying their contents. The expected vtable and missing-key versus stored-null distinction could not be checked at runtime.

Competing explanations

AGS counterexample. Both examined Wine implementations query ID3D12DeviceExt3 and return AGS_DX_FAILURE for this AppID when INTRINSICS_19 is unavailable. The source references were Stable dc26e618 and Experimental 81b7818af42f7d03b9f622f8c8336127bf679f18. The AGS CreateDevice failure message remained present in the successful patched run, so that message alone is insufficient to explain this startup crash.

Shader Model. Failing Stable and successful treatment both reported SM 6.8. The pass name does not establish an SM 6.9 requirement; direct resource-heap indexing is defined by SM 6.6 Dynamic Resources. No shader-model override was used.

Broad experimental flag. In the exact Stable source, enable_experimental_features gates View Instancing (device.c:9366), AdvancedTextureOps (9532), Work Graphs (9607) and SM 6.7 promotion (9890). The measured Vulkan features and source imply this GPU would gain both ViewInstancingTier 2 and WorkGraphsTier 1.0; SM 6.8 and AdvancedTextureOps were already eligible. That flag was not used as the isolated treatment.

Other examined upstream changes were AGS capability discovery, AGS DrawIndex translation, buffer/image aliasing and RDNA1 VRS fallback. None was imported into the successful treatment.

Tested patch

Upstream a8677602 enables a Crimson Desert View Instancing gate. Stable uses a mutually exclusive application-feature enum instead of the later bitmask. At baseline 212991fc2c266bc0d59f4c4ce8f80f7126508d71, only CrimsonDesert.exe maps to VKD3D_APPLICATION_FEATURE_RDNA1_COMPATIBILITY; the adaptation uses that existing game identity in d3d12_device_caps_init_feature_options3:

--- a/libs/vkd3d/device.c
+++ b/libs/vkd3d/device.c
@@ -9363,7 +9363,10 @@
             D3D12_COMMAND_LIST_SUPPORT_FLAG_COMPUTE | D3D12_COMMAND_LIST_SUPPORT_FLAG_COPY |
             D3D12_COMMAND_LIST_SUPPORT_FLAG_BUNDLE;
 
+    /* Backport a8677602: this baseline's RDNA1_COMPATIBILITY override is
+     * assigned only to CrimsonDesert.exe; preserve all other capability gates. */
     if (vkd3d_debug_control_is_test_suite() ||
+            vkd3d_application_feature_override == VKD3D_APPLICATION_FEATURE_RDNA1_COMPATIBILITY ||
             (vkd3d_config_flags & VKD3D_CONFIG_FLAG_ENABLE_EXPERIMENTAL_FEATURES))
     {
         /* Currently only partially implemented.

The condition is game-specific, not restricted to RDNA1 hardware. Existing checks for multiview, output layer/viewport, geometry/tessellation multiview and optional mesh-shader multiview remain unchanged; when satisfied, they expose ViewInstancingTier 2. The source patch adds no AGS, Work Graphs, shader-model or aliasing changes.

Patch SHA-256: 01cc0fbeecc00b4934d82f3868da3b57437a60ab0ee1c2df4a2ed227105a433c. Patched device.c SHA-256: 0869570f3a752a605bf46ee794a9766562a5b5c1c604f084569f3152f23cbe4c.

Build and reproduction

Both variants used GCC/G++ MinGW-w64 x86-64 POSIX 13, Meson 1.10.1, Ninja 1.13.2 and glslangValidator 16.2.0, release mode with trace enabled. Recursive submodules matched, including dxil-spirv 219d770799606f15abb3c57a8a9b9d19c2ae94ca. Both builds exited 0. DLL import/export sets matched, with no additional standalone libgcc/libstdc++/libwinpthread dependency.

sudo apt-get install meson ninja-build \
  gcc-mingw-w64-x86-64-posix g++-mingw-w64-x86-64-posix \
  mingw-w64-tools glslang-tools pkgconf

Run the following in a new working directory. Save the complete diff in “Tested patch” above as view-instancing-backport.patch in that directory.

git clone --no-checkout https://github.com/HansKristian-Work/vkd3d-proton.git baseline
git -C baseline checkout --detach 212991fc2c266bc0d59f4c4ce8f80f7126508d71
git -C baseline submodule update --init --recursive
git -C baseline worktree add --detach ../treatment 212991fc2c266bc0d59f4c4ce8f80f7126508d71
git -C treatment submodule update --init --recursive
git -C treatment apply ../view-instancing-backport.patch

Save this as cross-win64.txt in the parent directory:

[binaries]
c = '/usr/bin/x86_64-w64-mingw32-gcc-posix'
cpp = '/usr/bin/x86_64-w64-mingw32-g++-posix'
ar = '/usr/bin/x86_64-w64-mingw32-ar'
strip = '/usr/bin/x86_64-w64-mingw32-strip'
widl-mingw-tools-fallback = '/usr/bin/x86_64-w64-mingw32-widl'
pkg-config = '/usr/bin/pkgconf'

[properties]
needs_exe_wrapper = true

[host_machine]
system = 'windows'
cpu_family = 'x86_64'
cpu = 'x86_64'
endian = 'little'

Build each tree with the same settings:

unset CFLAGS CXXFLAGS CPPFLAGS LDFLAGS
export LC_ALL=C TZ=UTC
for variant in baseline treatment; do
  meson setup "build-$variant" "$variant" \
    --cross-file cross-win64.txt --buildtype release \
    -Denable_tests=false -Denable_extras=false -Denable_trace=true \
    -Denable_profiling=false -Denable_renderdoc=false \
    -Denable_descriptor_qa=false -Denable_extended_emulation=false
  nice -n 19 ninja -j 4 -C "build-$variant" \
    libs/d3d12/d3d12.dll libs/d3d12core/d3d12core.dll
done

The recipe reproduces the source change and clean/dirty build-ID difference; different compilers or PE timestamps can change binary hashes.

Run the component comparison

1. Make an independent copy of the installed Experimental tool, preserving permissions and symlinks (for example, cp -a --reflink=never). Register that clone under Steam's compatibilitytools.d, using a distinct tool name and install_path pointing at the clone. Retain its toolmanifest.vdf, including runtime AppID 4183110. Restart Steam and select the custom tool for AppID 3321460.
2. With the game stopped, install the official Stable x64 pair into the clone's files/lib/wine/vkd3d-proton/x86_64-windows/. Launch and record the startup result, pair/prefix SHA-256 hashes, and logged build identifier.
3. After the game exits, repeat with build-baseline/libs/d3d12/d3d12.dll and build-baseline/libs/d3d12core/d3d12core.dll, then with the corresponding build-treatment pair. Keep game/settings, Experimental base and BAR configuration fixed. Do not modify the game's own Agility SDK DLL.
4. Use equivalent logging in every case and a separate absolute PROTON_LOG_DIR for each run:

PROTON_LOG=1
VKD3D_DEBUG=info
WINEDEBUG=+timestamp,+pid,+tid,+seh,+debugstr

No VKD3D_SHADER_MODEL, enable_experimental_features, no_upload_hvv or RADV_PERFTEST=nosam override was used in the component comparison. Evaluate the exact exception signature and startup/gameplay outcome, not just successful DLL deployment. To establish causality, additionally perform the cache controls below; the original sequence did not include them.

Windows and hardware experiments

Windows produced WHEA 0x124, a separate failure class from the Linux process access violation. These are the recorded interventions/results; a complete BIOS matrix and raw MCA records are unavailable.

Power-connection clarification, September 18: the earlier reseating entry was not a verified fix. Nathan clarified that the repair which stopped the later crashes was in the household wiring/outlet supply, outside the computer. Do not read that earlier entry as evidence of an internal PSU-cable fix.

A GRUB memory test was reported, but no completed full-pass count/duration/result was retained. No full Memtest clearance is established.

On Linux, an MCE and Steam disk-write error occurred at 17:36:24 on 9 September. Their causal relationship is unknown. Subsequent Steam integrity checks passed. Read-only NVMe checks showed no SMART critical alert, zero media errors and 100% spare, with a pre-existing historical error count; no NVMe self-test was run. Later inspected kernel intervals contained no new matching hardware/storage errors. The successful software treatment does not resolve the WHEA/MCE events.

Requested follow-up

• Compare unpatched and patched builds with matched build identities and controlled cache state; separately test cache invalidation on the unpatched baseline and repeat A→B→A. This separates capability exposure from cache acceptance and run order.
• Capture the render object, manager table, interned name ID and registration path before the null dereference. Determine whether the named entry is missing, stores null, or is overwritten; add appropriate failure handling before the unconditional +0x30 read.
• Review/backport the existing View Instancing workaround against the Stable enum representation. Validate longer gameplay and Experimental with large BAR separately; neither result is established here.