Intel Arc iGPU (Core Ultra 7 155H): device lost every time Navi leaves to find Link, then VRAM climbs to 48 GB and igvk64.dll crashes (v2.0.2) #741

Closed

opened 2026-11-08 19:19:50 +00:00 by jochysautomationHN · 2 comments

jochysautomationHN commented

2026-11-08 19:19:50 +00:00

(Migrated from github.com)

Hookshot version

v2.0.2 (source 998ef8f9), built with the Hookshot Builder app (Windows) from a .nup. The same crash happened on v2.0.1.

What kind of problem

Crash / GPU hang (device lost)

What happened

On every run, the GPU hangs (submit ... failed (-4), device lost) right when Navi flies off to find Link. The 3D goes black while audio keeps playing. Over the next 30–60 s the Vulkan device heap grows from about 4–8 GB to about 48 GB, allocations start failing with pool ... not imported (VkResult -2), and the process dies inside the Intel driver with heap corruption:

CRASH: exception 0xc0000374 (read 0, guest 0xfffff00000000000) at ntdll.dll+0x112fc5
CRASH: host backtrace: ntdll.dll+0x112fc5 ntdll.dll+0x95a65 ntdll.dll+0xae02 ntdll.dll+0x12338a ntdll.dll+0x2790a igvk64.dll+0xee17bc igvk64.dll+0xec7d86 igvk64.dll+0x5dd055 igvk64.dll+0x5a7c72 igvk64.dll+0x5e1538 igvk64.dll+0x587ccf igvk64.dll+0x4f9446 hookshot_vk.dll+0x183fb5 hookshot_vk.dll+0x1818ce

(One earlier v2.0.2 run died instead with 0xc0000005 at igvk64.dll+0x1c9685, called from a hookshot_vk.dll worker thread.)

Device-lost checkpoints from 4 runs. The hang always happens in the compute dispatch that follows another one, but which program hangs changes once a program is rejected:

Run	Switches	Last completed (stage 0x2000)	Started, never finished (stage 0x1)
A	`RX_VK_NOOPT=1`	`ab7699ee7f536755`	`4b03b3040d7cf076`
B	`RX_VK_REJECT_KEYS` = 4 large vertex programs (unrelated)	`ab7699ee7f536755`	`4b03b3040d7cf076`
C	`RX_VK_REJECT_KEYS=4b03b3040d7cf076`	`ab7699ee7f536755`	`1153857ce380aa26`
D	`RX_VK_REJECT_KEYS=ab7699ee7f536755,4b03b3040d7cf076,1153857ce380aa26`	`435a0138b9013040`	`592079442d7129da`

Right up to the hang, GPU time is normal (GPU time 4.7 ms a frame (the longest submission 3.5 ms), 10–28 fps), so this does not look like a TDR caused by slow work. Rejecting the program that hung only moves the hang to the next dispatch.

Memory after the device is lost (run B): VRAM 3.9 GB → 8.1 GB (textures in) → device lost → 25.4 GB → 48.1 GB ("used 48078 of 37039 MB allowed") → crash. Imports stay at about 2 GB (60 live (1344 MB), 23 retired still imported (592 MB)), textures are about 2 GB, and mirrors are 0 MB. The growth is elsewhere in the device heap (heap 0 (device): 1179 blocks 44928 MB, 3431 allocations 44844 MB) and only starts after the device is lost. This may be the "RAM filling up" reported in #636.

Where in the game

Great Deku Tree intro, just after the Deku Tree's speech, as Navi leaves to find Link.

How often

Every time (6 of 6 runs across v2.0.1 and v2.0.2).

Graphics card and driver version

Intel Arc Graphics (Meteor Lake iGPU in a Core Ultra 7 155H), driver 32.0.101.8860, Vulkan 1.4.348, VK_EXT_mesh_shader supported. I will retest on 32.0.101.9175 and report back.

CPU, RAM and operating system

Core Ultra 7 155H, 64 GB DDR5-4800 dual channel, Windows 11 Pro. The driver reports a 37039 MB device budget.

Changes from the defaults

In-game menu (Custom): frame generation 2x, frame pacing on, resolution 50%, Lanczos, sharpness 35%, Real time, Handheld profile on. hookshot_env.txt only as listed in the table. With RX_VK_NOOPT=1 the 3D was also black before the hang, at about 9 fps.

Other software hooked into the game

None.

hookshot_log.txt

Not attached from the CLI. The excerpts above are verbatim, and I can attach the full logs if needed.

Before you send it

I'm on the newest release, or the problem is still there on it.
I searched the open issues for this problem. Related: #636 (same place, "RAM filling up", no logs), #655 and #366 (Intel GPUs), #17.
I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

### Hookshot version v2.0.2 (source 998ef8f9), built with the Hookshot Builder app (Windows) from a .nup. The same crash happened on v2.0.1. ### What kind of problem Crash / GPU hang (device lost) ### What happened On every run, the GPU hangs (`submit ... failed (-4)`, device lost) right when Navi flies off to find Link. The 3D goes black while audio keeps playing. Over the next 30–60 s the Vulkan device heap grows from about 4–8 GB to about 48 GB, allocations start failing with `pool ... not imported (VkResult -2)`, and the process dies inside the Intel driver with heap corruption: ``` CRASH: exception 0xc0000374 (read 0, guest 0xfffff00000000000) at ntdll.dll+0x112fc5 CRASH: host backtrace: ntdll.dll+0x112fc5 ntdll.dll+0x95a65 ntdll.dll+0xae02 ntdll.dll+0x12338a ntdll.dll+0x2790a igvk64.dll+0xee17bc igvk64.dll+0xec7d86 igvk64.dll+0x5dd055 igvk64.dll+0x5a7c72 igvk64.dll+0x5e1538 igvk64.dll+0x587ccf igvk64.dll+0x4f9446 hookshot_vk.dll+0x183fb5 hookshot_vk.dll+0x1818ce ``` (One earlier v2.0.2 run died instead with `0xc0000005` at `igvk64.dll+0x1c9685`, called from a hookshot_vk.dll worker thread.) **Device-lost checkpoints from 4 runs.** The hang always happens in the compute dispatch that follows another one, but which program hangs changes once a program is rejected: | Run | Switches | Last completed (stage 0x2000) | Started, never finished (stage 0x1) | |---|---|---|---| | A | `RX_VK_NOOPT=1` | `ab7699ee7f536755` | `4b03b3040d7cf076` | | B | `RX_VK_REJECT_KEYS` = 4 large vertex programs (unrelated) | `ab7699ee7f536755` | `4b03b3040d7cf076` | | C | `RX_VK_REJECT_KEYS=4b03b3040d7cf076` | `ab7699ee7f536755` | `1153857ce380aa26` | | D | `RX_VK_REJECT_KEYS=ab7699ee7f536755,4b03b3040d7cf076,1153857ce380aa26` | `435a0138b9013040` | `592079442d7129da` | Right up to the hang, GPU time is normal (`GPU time 4.7 ms a frame (the longest submission 3.5 ms)`, 10–28 fps), so this does not look like a TDR caused by slow work. Rejecting the program that hung only moves the hang to the next dispatch. **Memory after the device is lost (run B):** VRAM 3.9 GB → 8.1 GB (textures in) → *device lost* → 25.4 GB → 48.1 GB ("used 48078 of 37039 MB allowed") → crash. Imports stay at about 2 GB (`60 live (1344 MB), 23 retired still imported (592 MB)`), textures are about 2 GB, and mirrors are 0 MB. The growth is elsewhere in the device heap (`heap 0 (device): 1179 blocks 44928 MB, 3431 allocations 44844 MB`) and only starts after the device is lost. This may be the "RAM filling up" reported in #636. ### Where in the game Great Deku Tree intro, just after the Deku Tree's speech, as Navi leaves to find Link. ### How often Every time (6 of 6 runs across v2.0.1 and v2.0.2). ### Graphics card and driver version Intel Arc Graphics (Meteor Lake iGPU in a Core Ultra 7 155H), driver 32.0.101.8860, Vulkan 1.4.348, `VK_EXT_mesh_shader` supported. I will retest on 32.0.101.9175 and report back. ### CPU, RAM and operating system Core Ultra 7 155H, 64 GB DDR5-4800 dual channel, Windows 11 Pro. The driver reports a 37039 MB device budget. ### Changes from the defaults In-game menu (Custom): frame generation 2x, frame pacing on, resolution 50%, Lanczos, sharpness 35%, Real time, Handheld profile on. `hookshot_env.txt` only as listed in the table. With `RX_VK_NOOPT=1` the 3D was also black before the hang, at about 9 fps. ### Other software hooked into the game None. ### hookshot_log.txt Not attached from the CLI. The excerpts above are verbatim, and I can attach the full logs if needed. ### Before you send it - [x] I'm on the newest release, or the problem is still there on it. - [x] I searched the open issues for this problem. Related: #636 (same place, "RAM filling up", no logs), #655 and #366 (Intel GPUs), #17. - [x] I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

jochysautomationHN commented

2026-11-08 20:50:39 +00:00

(Migrated from github.com)

Update: retested on v2.0.3 (source 73ddf2ad) with Intel driver 32.0.101.9175.

Better:

The Navi scene now plays through every time. There is no device lost there, only a 2–5 minute pause on the first visit while new pipelines compile.
VRAM stays at 6–9 GB ("8904 MB used of 38338 MB allowed") instead of climbing to 48 GB.
storage buffer NOT bound (reads zeros) no longer appears at all (it showed 40 times per run before).
Gameplay in Kokiri Forest runs at about 17–27 fps with frame generation 2x, and saving works.
Shader preparation: prepared 31985 shader programs (39842 new, 0 failed, 3808 stage libraries) in 1502.3 s.

Still happening: one device lost after about 45 minutes in Kokiri Forest, in another compute dispatch:

vk: submit 160971 failed (-4)
vk: device lost: 2 checkpoints (7484241 markers set)
vk:   stage 0x1: marker 7482363 (dispatch of program 435a0138b9013040, frame 22992)
vk:   stage 0x2000: marker 7482362 (dispatch of program aba5e6af8d4683eb, frame 22992)

435a0138b9013040 is the program with the compare-exchange loop named in #17. It still hangs on this Intel iGPU, but only now and then instead of at a fixed point.

Update: retested on **v2.0.3** (source 73ddf2ad) with Intel driver **32.0.101.9175**. **Better:** - The Navi scene now plays through every time. There is no device lost there, only a 2–5 minute pause on the first visit while new pipelines compile. - VRAM stays at 6–9 GB ("8904 MB used of 38338 MB allowed") instead of climbing to 48 GB. - `storage buffer NOT bound (reads zeros)` no longer appears at all (it showed 40 times per run before). - Gameplay in Kokiri Forest runs at about 17–27 fps with frame generation 2x, and saving works. - Shader preparation: `prepared 31985 shader programs (39842 new, 0 failed, 3808 stage libraries) in 1502.3 s`. **Still happening:** one device lost after about 45 minutes in Kokiri Forest, in another compute dispatch: ``` vk: submit 160971 failed (-4) vk: device lost: 2 checkpoints (7484241 markers set) vk: stage 0x1: marker 7482363 (dispatch of program 435a0138b9013040, frame 22992) vk: stage 0x2000: marker 7482362 (dispatch of program aba5e6af8d4683eb, frame 22992) ``` `435a0138b9013040` is the program with the compare-exchange loop named in #17. It still hangs on this Intel iGPU, but only now and then instead of at a fixed point.

NotRexed commented

2026-11-09 05:55:17 +00:00

(Migrated from github.com)

Tracked in #999, follow there. That issue collects every report of Intel Arc / Core Ultra device lost, black screens and Linux ANV crashes, and this one is linked from it with its GPU, version and log details. If it still happens on v2.0.6 (https://github.com/NotRexed/Hookshot/releases/tag/v2.0.6; Update next to Play in the launcher), please add a comment there with your hookshot_log.txt.