protonscr

[d3d9] 32-bit King's Bounty: Warriors of the North — NULL vtable deref at d3d9.dll RVA 0x466833, entered via device method RVA 0xb0914

dxvkopen needs apitraced3d9needs more infoAI bullshit
doitsujin/dxvk#5942 · opened 2026-10-01 by als-creator · updated 2026-10-13 · 5 comments · github
Aals-creator 2026-10-01 github

[d3d9] 32-bit King's Bounty: Warriors of the North — NULL vtable deref crash inside d3d9.dll (movl 4(%ecx),%eax at ecx=0), RVA 0x466833, entered via device method RVA 0xb0914

Summary

32-bit Windows build of King's Bounty: Warriors of the North (Steam 203350) running through
Steam Play (Proton Experimental) crashes with EXCEPTION_ACCESS_VIOLATION inside DXVK's
32-bit d3d9.dll: a NULL pointer is dereferenced at vtable offset +4 (movl 4(%ecx),%eax
with ecx=0 → read of 0x4). Caught in a PROTON_LOG=1 / WINEDEBUG=+seh log with the
full winedbg backtrace.

Environment

  • OS: EndeavourOS (Arch), kernel 7.2.7-zen1-1-zen
  • GPU: AMD Cezanne iGPU (1002:1638), Mesa RADV 26.2.3 (Vulkan 1.4.354), 4 GB shared VRAM
  • RAM: 20 GB
  • DXVK: v3.1.1-21-7df3596eed49cb7 (32-bit build / info: Build: x86 gcc 14.0.0), from
    Proton Experimental 11.0-20260917b
  • Game: KBWotN.exe (32-bit), appid 203350

Trace (winedbg, 2026-09-25 19:34:17 +06)

code=c0000005 (EXCEPTION_ACCESS_VIOLATION), flags=0
addr=77C56833  →  movl 4(%ecx), %eax  при ecx=0  (read access to 0x00000004)

Backtrace:
=>0  0x77c56833  d3d9 (+0x466833)   ; movl 4(%ecx),%eax  ← fault
   1  0x77874cf6  d3d9 (+0x84cf6)
   2  0x7788f60b  d3d9 (+0x9f60b)
   3  0x7782081a  d3d9 (+0x3081a)
   4  0x778a0914  d3d9 (+0xb0914)   ; IDirect3DDevice9 method entry
   5  0x006be1e0  kbwotn (+0x2be1e0)

D3D9 method entry is d3d9.dll RVA 0xb0914; the fault sits at RVA 0x466833.
Caller is the game at KBWotN.exe RVA 0x2be1e0.

Session duration at crash: ~1 h 42 min. The game's settings at the time had memory
pressure removed (streaming 1, shadow 1024, FSAA off — the workaround for a separate
32-bit address-space exhaustion bug), so OOM is not a plausible trigger here.

Interpretation

Either the game calls a D3D9 device method on a released/NULL interface, or DXVK returns a
NULL interface/object where native Windows (or wined3d) returns a valid one — classic
DeviceLost/Reset and state/surface-lifecycle suspects. A symbolicated build (or PDB) would
identify the exact function; I can only provide RVAs from winedbg, plus the full register
dump and stack data from the log.

Status

The fault has not recurred since updating to DXVK v3.1.1-27-g25ca63f17f34bdc
(Proton Experimental 20260924): ~10 h / 9 sessions since 2026-09-25 evening. If this is
indeed fixed by a change between v3.1.1-21 and v3.1.1-27, that would be worth knowing.

Diagnostics available

  • Full PROTON_LOG (~1 MB) with the winedbg backtrace, register dump and thread/module list — can attach or paste on request.
  • Relevant game.ini (before/after) and exact settings.

Would DXVK maintainers like the full log? And is there a known fix between v3.1.1-21 and v3.1.1-27 that matches this pattern?

BBlisto91 maintainer 2026-10-01 github

Would DXVK maintainers like the full log?

Yes. The issue template asks for it. If your LLM even knows about or cares for it

Edit: Assuming you are using a LLM. If not then apologies

KK0bin maintainer 2026-10-01 github

Let's start at the beginning: I assume your problem is a crash.

So how do I reproduce this crash?

Image

Seems to run just fine here.

Aals-creator 2026-10-02 github

Thanks for taking a look, and sorry for the terse first post. Let's be practical.

@Blisto91 — full log (the PROTON_LOG with the winedbg backtrace, ~940 KB) is here:
https://gist.github.com/als-creator/12ac5fe9967fdcbdcd7a33890b98f652

It's the complete PROTON_LOG=1 DXVK_LOG_LEVEL=info %command% capture from the crashed
session (2026-09-25, DXVK v3.1.1-21-7df3596eed49cb7, 32-bit build). The interesting part
starts at line ~7295 of that file: dispatch_exception code=c0000005 ... addr=77C56833,
followed by the winedbg register dump/backtrace and the thread list (dxvk-cs/queue/frame
threads present). Faulting instruction is movl 4(%ecx), %eax with ecx=0
(d3d9.dll RVA ~0x466833), entered via d3d9.dll RVA 0xb0914, caller KBWotN.exe RVA 0x2be1e0.

@K0bin — how I get there (repro steps):

  1. Steam → King's Bounty: Warriors of the North (203350) → Properties → Launch Options:
    PROTON_LOG=1 DXVK_LOG_LEVEL=info %command% (Steam Play → Proton Experimental).
  2. In-game settings used in the crashed session: 1920x1080, windowed off, streaming ON
    (~streaming 1 in game.ini), shadowresolution 1024, r_fsaa 0, r_filter 5,
    vsync at 75 Hz.
  3. Play a normal session — the crash happened after ~1 h 42 min of regular play
    (map travel + combat + autosaves), at 19:34:17 +06 on 2026-09-25. The game just
    closed; the fault and teardown are fully logged in the gist (engine tried to show an
    error afterwards: .NET-side Win32Exception "invalid window handle" ×9, then winedbg
    tore the process down ~17 s later).

Honest caveats, because I want this to be useful:

  • This is a single capture out of roughly five sessions on that DXVK build; it is
    reproducible in the sense that long sessions crash, but the probability per session is
    low, so don't expect it within minutes.
  • After updating Proton Experimental to 20260924 (DXVK v3.1.1-27) I have played ~10 h
    across ~9 sessions without another crash — so if something between v3.1.1-21 and
    v3.1.1-27 fixed this exact NULL deref, that's worth knowing at your side too.
  • The initial report was drafted with the help of an LLM assistant; all facts above and
    every line of the log are real and taken from the captured session — nothing fabricated.
  • If you want a clean apitrace capture: I can run PROTON_LOG/apitrace on the next
    occurrence, or set up an automated retry loop next time I'm on that machine. Just say
    which tool/version you'd prefer (d3d9trace vs. structured apitrace) and I'll provide it.

Neither AV about the specific situation. If there's a known NULL-deref fix between
v3.1.1-21 and v3.1.1-27 (device-reset/state-lifetime related), a pointer would help me
match it against the RVA above.

Aals-creator 2026-10-02 github

Follow-up observation — same engine bug, new manifestation (soft-lock, not a crash).

Today 2026-10-03 ~01:24 the game froze ~5s after an autosave: main thread (KBWotN.exe) spins at ~100% CPU in a tight __regs__setjmp3/longjmp loop (the engine's software-exception machinery), the swapchain/late-acquire threads sit parked on futex (no frames), PROTON_LOG goes silent and stays so. This is the exact same setjmp/longjmp rhythm that precedes the NULL-deref in the 25.09 log — same buffer addresses, same esp/eip.

The loop executes in an anonymous executable (JIT) mapping 0x7b9b1000-0x7bb7a000, and mscoree:DllMain loads right at the onset — i.e. the spinning code is the game's own script/.NET runtime, not DXVK. DXVK's threads are idle here.

So the trigger lives in the game engine (Katauri) right after autosave; the 25.09 crash in d3d9+0x466833 (writes to 0x4) is just where the broken game state finally surfaced into a D3D9 call. If you want repro guidance, it should be a game-side soft-lock/stderr kind of issue, not a D3D9 one.

Freeze log (PROTON_LOG, WINEDEBUG=+seh): https://gist.github.com/als-creator/12ac5fe9967fdcbdcd7a33890b98f652 (added as steam-203350-freeze-20261003-0124.log). Happy to capture an apitrace D3D9 trace if you still want one for crash-2 — instructions are ready.

Summary of all four sessions: 24.09 crash (32-bit address-space exhaustion), 24.09 silent exit, 25.09 NULL-deref, 03.10 soft-lock — all within ~seconds…minutes after an autosave.

PPourOutYourPowerAndLove 2026-10-13 github

bro generated an essay to not answer the question 💀

edit: but maybe worth closing because this isn't related?

Proton versions

Launch options

Launch lines

DLLs