Repository navigation
Crash inside Intel Vulkan driver (igvk64.dll) at first gameplay render on Intel HD 520 - still present on windows-v2.8.0-intel-test4 #1126
Description
Before reporting
- I searched the existing issues for this problem, my GPU and my error message (same family: game crashes/black screen #286; identical open report: crash di menu #1090 - commented there too)
- I tested on the latest release (v2.7.0) and on the newest Intel test build (windows-v2.8.0-intel-test4, from 4008738)
Port version
windows-v2.8.0-intel-test4 (build from commit 4008738). Same crash also reproduced on:
- v2.7.0 (
igvk64.dll+0x5de4b0) - v2.2.0 (
igvk64.dll+0x5cfab2— exact same offset as test4) - windows-v2.1.8-intel-hd630-test1 (
igvk64.dll+0x5cfab2)
Operating system
Windows 10 Pro, 64-bit, build 19045 (22H2), fully updated
GPU and driver version
Intel HD Graphics 520 (Skylake, Gen9) — driver 31.0.101.2115 (latest available driver for 6th gen; legacy branch; newer versions exist only for 7th gen+)
CPU
Intel Core i5-6300U (2 cores / 4 threads), 8 GB RAM
Game build / update version
CUSA01715, version 01.02 (base game combined with v1.02 update by the launcher)
Selected game folder
D:\Games\God of War III Remastered\game (custom user_dir: D:\Games\God of War III Remastered\Saves)
Exact error message
Runtime: guest thread 'WorkerThread4' created (stack=262144, prio=700)
Runtime: pad map: 1 gamepad and 19 keyboard buttons remapped
Runtime: stick prompts: keyboard
Runtime: trophies: 35 texts read from D:\Games\God of War III Remastered\Saves/trophy_texts.txt
Runtime: trophies: 35 in trophy00.trp, 0 already unlocked
Fault: read access to 0000000000000298 at igvk64.dll+0x5cfab2 (thread 7576)
rax=0000000000000000 rbx=00000000112f6dc8 rcx=00000000112f6dc8 rdx=0000000000000070
rsi=0000000000000001 rdi=00000000112f6dc8 rbp=0000000000090000 rsp=000000001d6df860
Crashes right when gameplay rendering starts, after WAD mounts + WorkerThread0..5 + audio + pad + trophies. 100% reproducible, ~40-60 s after launch. Never reaches the main menu on any version.
What I already tested (all on CUSA01715 01.02)
All crashes identical, same fault offset, immediately after WorkerThread0..4 lines in the log:
- render_resolution=480p / windowed / vsync off / anisotropy 0 / frames_queued=1 (all versions)
SPARTAN_SCENE_STENCIL_BITS=0and=4and=8(test4) — no changeSPARTAN_LDS_BARRIERS=1+SPARTAN_COPY_GPU_BUFFERS=1(test4) — no changeSPARTAN_GPU_CHECKPOINTS=0(test4) — no change (log confirms checkpoints off)SPARTAN_VK_VALIDATION=1(the Khronos validation layer is not installed on this system, so no layer loaded): crash shifts toigvk64.dll+0x5cfab9,read access to ffffffffffffffff,rdx=8000b400153ecd74— reproducible every time- Intel-related log lines confirm test4's workarounds active:
GPU: vertex input dynamic state off (Intel Windows driver; SPARTAN_VERTEX_INPUT_DYNAMIC=1 turns it on),GPU: checkpoints: on (Intel Windows driver),extensions off: VK_EXT_vertex_input_dynamic_state (Intel Windows driver) Game and update combined from <update folder>— I am definitely running v1.02, and the log listsError 1450no longer (page file raised: this is fixed)
Additional data point (maybe useful for bisecting — test4)
- With Mesa lavapipe (llvmpipe, Vulkan 1.4) injected via
VK_ICD_FILENAMES+VK_DRIVER_FILES: instance/device enumeration works, the engine printsGPU 0: llvmpipe (LLVM 23.1.2, 256 bits)/GPU: using llvmpipe, but then crashes at the same startup point — this time inside the system loader:Fault: read access to 0000000000000000 at vulkan-1.dll+0x5725awith rcx=0000000000000000- It crashes right after this engine warning, on both the Intel driver and llvmpipe:
CollectImageFormatInfo: Depth format z_format=1, stencil_format=1 is not fully supported (vk_format=D16UnormS8Uint, missing features={ DepthStencilAttachment })
- It crashes right after this engine warning, on both the Intel driver and llvmpipe:
- Mesa Dozen (Vulkan-on-D3D12, API 1.2): fails cleanly early with
STOP: GPU library assertion failed—Vulkan 1.3 is required, but only 1.2 is supported by device! - Idea for bisecting: the fault on two unrelated ICDs (Intel proprietary and llvmpipe) at the same spot suggests the code path around that depth-format probe / device-format collection may pass an unexpected NULL pointer rather than the driver being solely at fault.
Attaching
- Full logs (all three, exact content) uploaded as one gist: https://gist.github.com/mustafaMansourr/f8ac38bcf374d3cadd4e91e71ce6a89f
Notes
- Happy to run any new test build and report back quickly — this machine reproduces it in ~60 seconds every time. The GPU checkpoint dump (VK_NV_device_diagnostic_checkpoints) triggers only on device-lost so far; I could not get a checkpoint dump from this segfault.
- Willing to test with
GOW3_VK_VALIDATION=1if a validation layer is provided/installed.
(Submitted for the Intel Gen9 family crashtracked in #286; identical fault also seen on UHD 630 desktop in #1090 and UHD (Comet Lake) in #977.)
Activity
Joss-Zero commentedon Nov 3, 2026
If you have version 3.0.0 of GOW (spartanport-windows), it may crash when using Intel HD or UHD integrated GPUs. To fix this, simply download version v2.8.0-intel-test4 (Release Windows test build windows-v2.8.0-intel-test4 · FelipePrado0/SpartanPort · GitHub), open the "spartanport-windows/bin" folder within the zip file, copy the "spartanport-probe.exe" file, and use it to replace the corresponding file in your own "spartanport-windows/bin" game folder. This will resolve the crashes.
mustafaMansourr commentedon Nov 3, 2026
Thanks @Joss-Zero! Quick note: we are not on 3.0.0 - this entire install IS windows-v2.8.0-intel-test4, launched through its own Play SpartanPort.exe, so the test4 spartanport-probe.exe is already the engine here. That tip fits people whose crashes arrived with the 3.0.0 update. Our report is the CPU-segfault form, different from the device-lost crashes, and it reproduces on the test build itself (on v2.2.0, v2.7.0 and test4).
I just ran the two probe combos the devs asked for on the Intel threads, on test4 (each is a fresh launch, Intel HD 520 / driver 31.0.101.2115, ~95 s):
Fault: exception 0x20474343 at KERNELBASE.dll+0x25369 (thread 2664)- this is no longer the baseline igvk64.dll NULL read; the engine gets through the whole driver init (device pick, all format probes, D16S8 warning, swapchain) and dies in a deliberately-thrown exception (KERNELBASE RaiseException)Fault: exception 0x20474343 at KERNELBASE.dll+0x25369 (thread 10216)- this is no longer the baseline igvk64.dll NULL read; the engine gets through the whole driver init (device pick, all format probes, D16S8 warning, swapchain) and dies in a deliberately-thrown exception (KERNELBASE RaiseException)So at least one of the probes avoids the igvk64.dll segfault outright. With SPARTAN_EMPTY_FS=1 the log confirms it was active ("GPU: empty fragment shader on every pipeline without one (SPARTAN_EMPTY_FS=1; disk pipeline cache off)"), which pins the failing work to the pipeline setup for draws WITHOUT a fragment shader - the depth/stencil-only full-screen rectangle path from the test3 findings in #1018.
Already tried earlier on test4 with zero change: SPARTAN_SCENE_STENCIL_BITS=0/4/8, SPARTAN_LDS_BARRIERS=1 + SPARTAN_COPY_GPU_BUFFERS=1, SPARTAN_GPU_CHECKPOINTS=0 alone, SPARTAN_GPU_LOG=1. SPARTAN_VK_VALIDATION=1 only rotates the fault to +0x5cfab9 (reads ffffffffffffffff instead of 0x298). The same NULL handoff also reaches the same stage under Mesa lavapipe (fault lands in the vulkan-1.dll loader right after the D16S8 format probe).
Logs for every run are in the same gist (the two new probe logs are appended there too): https://gist.github.com/mustafaMansourr/f8ac38bcf374d3cadd4e91e71ce6a89f
Question for the maintainers: the checkpoint dump prints on device-lost, but the baseline crash is a CPU-side segfault inside igvk64.dll, so the last checkpoint never prints. Is there a way to force a checkpoint dump on a segfault (SPARTAN_DIAG_DIR?), or should I attach a WinDbg stack of the faulting frames? Also happy to run any other probe combo - just list the env vars or drop a .bat file and I will report back with logs.
FelipePrado0 commentedon Nov 10, 2026
EN:
@mustafaMansourr thank you for the careful runs.
0x20474343is a C++ exception thrown by the port itself, not a driver fault, so with those settings the driver setup now gets through and the port stops on purpose a bit later. The last lines before the fault in those two logs tell us what it rejected; please paste them here. A WinDbg stack of the baselineigvk64.dllfault would also help.The same crash on Intel HD 530 (#1269) is now followed here too.
PT-BR:
@mustafaMansourr obrigado pelos testes cuidadosos.
0x20474343é uma exceção C++ lançada pelo próprio port, não uma falha do driver, então com essas configurações a preparação do driver passa e o port para de propósito um pouco depois. As últimas linhas antes da falha nesses dois logs mostram o que ele recusou; cole aqui, por favor. Uma pilha do WinDbg da falha original emigvk64.dlltambém ajudaria.O mesmo crash na Intel HD 530 (#1269) passa a ser acompanhado aqui também.
georgedenteh226-source commentedon Nov 10, 2026
I’m facing the same issue has there been a solution