[AMD RX 6600] Reproducible Vulkan device loss and crash inside Deku Tree on v2.0.2

Zedoge7 commented

2026-11-08 17:59:50 +00:00

(Migrated from github.com)

Hookshot version

v2.0.2

What kind of problem

Crash, freeze or black screen

What happened

Description

Hi NotRexed and contributors,

First of all, thank you for your work on Hookshot! The game runs significantly better than the emulator alternatives on my PC, and audio works correctly.

Unfortunately, I am still experiencing a recurring GPU crash inside the Deku Tree on Hookshot v2.0.2, despite the recent AMD shader fixes and the bounded compare-and-swap loops introduced in PR #548.

This appears related to the RX 6600 Deku Tree issue mentioned in the v2.0.2 release notes (#614).

System specifications

GPU: AMD Radeon RX 6600 8 GB (RDNA 2)

CPU: AMD Ryzen 7 5800XT

Graphics API: Vulkan 1.4

Vulkan driver identifier: 0x800161 (as reported by Hookshot)

Hookshot version: v2.0.2 (source 998ef8f9)

Renderer: hookshot_vk.dll

Steps to reproduce

Launch the game using Hookshot v2.0.2.

Load a save and enter the Deku Tree.

Continue playing inside the dungeon.

The graphics device stops responding and Hookshot crashes.

The issue has occurred repeatedly during gameplay inside the Deku Tree.

Actual behavior

Hookshot reports Vulkan submission failures followed by device loss:

[hos Presentation Thread] vk: submit 41353 failed (-4)
[hos Presentation Thread] vk: device lost: reading the fault info (RX_VK_CHECKPOINTS=1 for markers)
[hos Presentation Thread] vk: submit 41354 failed (-4)

Several logs also show an access violation inside AMD's Vulkan driver:

CRASH: exception 0xc0000005
(read 0x38, guest 0xfffff00000000038)
at amdvlk64.dll+0x319b63

The crash backtrace begins with:

amdvlk64.dll+0x319b63
amdvlk64.dll+0x31b9f9
amdvlk64.dll+0x2d8e21
amdvlk64.dll+0x2d8a24
amdvlk64.dll+0x25617b
hookshot_vk.dll+0x183

This suggests a Vulkan device-loss issue involving the AMD driver, although I cannot determine whether the initial trigger is a shader translation issue, a driver bug, or their interaction.

Additional information

The issue persists on v2.0.2, which includes the AMD shader and GPU hang fixes.

The game runs well before the crash, with working audio.

Frame interpolation activity appears in the logs.

The logs contain the suggestion to enable RX_VK_CHECKPOINTS=1 for additional GPU markers.

Multiple crash logs are attached.

Expected behavior

The game should remain stable inside the Deku Tree without losing the Vulkan device or crashing the AMD driver.

Logs

I have attached five Hookshot logs containing repeated crash attempts and Vulkan device-loss errors.

Please let me know if you would like me to collect additional logs using RX_VK_CHECKPOINTS=1, test specific Vulkan settings, or try an experimental build.

Thank you for investigating this issue!

Where in the game

Inside the Deku tree

How often

Every time

Graphics card and driver version

RX 6600

CPU, RAM and operating system

ryzen 7 5800 xt

Changes from the defaults

No response

Other software hooked into the game

No, nothing hooked in

hookshot_log.txt

hookshot_log.1.txt
hookshot_log.2.txt
hookshot_log.3.txt
hookshot_log.4.txt
hookshot_log.txt

Screenshots or video

No response

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.
I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

### Hookshot version v2.0.2 ### What kind of problem Crash, freeze or black screen ### What happened Description Hi NotRexed and contributors, First of all, thank you for your work on Hookshot! The game runs significantly better than the emulator alternatives on my PC, and audio works correctly. Unfortunately, I am still experiencing a recurring GPU crash inside the Deku Tree on Hookshot v2.0.2, despite the recent AMD shader fixes and the bounded compare-and-swap loops introduced in PR #548. This appears related to the RX 6600 Deku Tree issue mentioned in the v2.0.2 release notes (#614). System specifications GPU: AMD Radeon RX 6600 8 GB (RDNA 2) CPU: AMD Ryzen 7 5800XT Graphics API: Vulkan 1.4 Vulkan driver identifier: 0x800161 (as reported by Hookshot) Hookshot version: v2.0.2 (source 998ef8f9) Renderer: hookshot_vk.dll Steps to reproduce Launch the game using Hookshot v2.0.2. Load a save and enter the Deku Tree. Continue playing inside the dungeon. The graphics device stops responding and Hookshot crashes. The issue has occurred repeatedly during gameplay inside the Deku Tree. Actual behavior Hookshot reports Vulkan submission failures followed by device loss: [hos Presentation Thread] vk: submit 41353 failed (-4) [hos Presentation Thread] vk: device lost: reading the fault info (RX_VK_CHECKPOINTS=1 for markers) [hos Presentation Thread] vk: submit 41354 failed (-4) Several logs also show an access violation inside AMD's Vulkan driver: CRASH: exception 0xc0000005 (read 0x38, guest 0xfffff00000000038) at amdvlk64.dll+0x319b63 The crash backtrace begins with: amdvlk64.dll+0x319b63 amdvlk64.dll+0x31b9f9 amdvlk64.dll+0x2d8e21 amdvlk64.dll+0x2d8a24 amdvlk64.dll+0x25617b hookshot_vk.dll+0x183 This suggests a Vulkan device-loss issue involving the AMD driver, although I cannot determine whether the initial trigger is a shader translation issue, a driver bug, or their interaction. Additional information The issue persists on v2.0.2, which includes the AMD shader and GPU hang fixes. The game runs well before the crash, with working audio. Frame interpolation activity appears in the logs. The logs contain the suggestion to enable RX_VK_CHECKPOINTS=1 for additional GPU markers. Multiple crash logs are attached. Expected behavior The game should remain stable inside the Deku Tree without losing the Vulkan device or crashing the AMD driver. Logs I have attached five Hookshot logs containing repeated crash attempts and Vulkan device-loss errors. Please let me know if you would like me to collect additional logs using RX_VK_CHECKPOINTS=1, test specific Vulkan settings, or try an experimental build. Thank you for investigating this issue! ### Where in the game Inside the Deku tree ### How often Every time ### Graphics card and driver version RX 6600 ### CPU, RAM and operating system ryzen 7 5800 xt ### Changes from the defaults _No response_ ### Other software hooked into the game No, nothing hooked in ### hookshot_log.txt [hookshot_log.1.txt](https://github.com/user-attachments/files/34550507/hookshot_log.1.txt) [hookshot_log.2.txt](https://github.com/user-attachments/files/34550506/hookshot_log.2.txt) [hookshot_log.3.txt](https://github.com/user-attachments/files/34550509/hookshot_log.3.txt) [hookshot_log.4.txt](https://github.com/user-attachments/files/34550508/hookshot_log.4.txt) [hookshot_log.txt](https://github.com/user-attachments/files/34550505/hookshot_log.txt) ### Screenshots or video _No response_ ### 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. - [x] I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

TOOKY993 commented

2026-11-08 18:35:29 +00:00

(Migrated from github.com)

I encountered the same issue in Kakariko Village; I’m also using an RX 6600, and I’ll attach the log.

hookshot_log.txt

I encountered the same issue in Kakariko Village; I’m also using an RX 6600, and I’ll attach the log. [hookshot_log.txt](https://github.com/user-attachments/files/34551153/hookshot_log.txt)

Palayop7239 commented

2026-11-08 19:14:22 +00:00

(Migrated from github.com)

Same crash here on an RX 6650 XT (RDNA 2, 8 GB), AMD driver 0x800161, Ryzen 7 5700X, Windows 11. It happened outside the Deku Tree too: in the Goron area of Death Mountain (Goron City / Dodongo's Cavern), after about 5 minutes of play at 60 fps.

Build: v2.0.2 with hookshot_vk.dll rebuilt with #700, #701 and #702. Those only change how pipelines are built, and nothing was compiling when it hung: no jobs queued, no draw waiting for a pipeline.

The GPU stopped answering first, and the driver crash came afterwards:

vk: a capture's wait for write-back 130627 timed out (done 130623)
nvn: GPU waits in 5 s: 1 sync waits (5525 ms), 0 polls timed out (0 ms), 5 queue finishes (2 ms)
vk: submit 130642 failed (-4)
vk: device lost: reading the fault info (RX_VK_CHECKPOINTS=1 for markers)
...
CRASH: exception 0xc0000005 (read 0x38, guest 0xfffff00000000038) at amdvlk64.dll+0x319b63
CRASH: host backtrace: amdvlk64.dll+0x319b63 amdvlk64.dll+0x31b9f9 amdvlk64.dll+0x2d8e21 amdvlk64.dll+0x2d8a24 amdvlk64.dll+0x25617b hookshot_vk.dll+0x18418b hookshot_vk.dll+0x17f7cf hookshot_vk.dll+0x17c210 ...

The crash address and the backtrace's driver frames are the same as in the report above. The amdvlk64.dll crash is the first call into the driver after the device was lost. The cause is the GPU hang before it.

Three places on RDNA 2 so far (Deku Tree, Kakariko, the Goron area) point to something common, not one room. Once #734 is in (RX_VK_CHECKPOINTS on AMD), a run with RX_VK_CHECKPOINTS=1 should name the program that was on the GPU when it hung.

Same crash here on an **RX 6650 XT** (RDNA 2, 8 GB), AMD driver 0x800161, Ryzen 7 5700X, Windows 11. It happened outside the Deku Tree too: in the Goron area of Death Mountain (Goron City / Dodongo's Cavern), after about 5 minutes of play at 60 fps. Build: v2.0.2 with `hookshot_vk.dll` rebuilt with #700, #701 and #702. Those only change how pipelines are built, and nothing was compiling when it hung: no jobs queued, no draw waiting for a pipeline. The GPU stopped answering first, and the driver crash came afterwards: ``` vk: a capture's wait for write-back 130627 timed out (done 130623) nvn: GPU waits in 5 s: 1 sync waits (5525 ms), 0 polls timed out (0 ms), 5 queue finishes (2 ms) vk: submit 130642 failed (-4) vk: device lost: reading the fault info (RX_VK_CHECKPOINTS=1 for markers) ... CRASH: exception 0xc0000005 (read 0x38, guest 0xfffff00000000038) at amdvlk64.dll+0x319b63 CRASH: host backtrace: amdvlk64.dll+0x319b63 amdvlk64.dll+0x31b9f9 amdvlk64.dll+0x2d8e21 amdvlk64.dll+0x2d8a24 amdvlk64.dll+0x25617b hookshot_vk.dll+0x18418b hookshot_vk.dll+0x17f7cf hookshot_vk.dll+0x17c210 ... ``` The crash address and the backtrace's driver frames are the same as in the report above. The `amdvlk64.dll` crash is the first call into the driver after the device was lost. The cause is the GPU hang before it. Three places on RDNA 2 so far (Deku Tree, Kakariko, the Goron area) point to something common, not one room. Once #734 is in (`RX_VK_CHECKPOINTS` on AMD), a run with `RX_VK_CHECKPOINTS=1` should name the program that was on the GPU when it hung.

Flo-za commented

2026-11-08 19:29:25 +00:00

(Migrated from github.com)

Same here on an RX 6800 (16 GB), Windows 11, Ryzen 7 5800X3D, v2.0.2, AMD driver 0x800161, so this looks like it affects RDNA 2 generally, not just the 6600 (and not an 8 GB VRAM limit).

Runs well up to this point (steady 60 fps in Kokiri Forest with ~1000 draws/frame). Inside the Great Deku Tree the frame rate drops to ~10 fps, then:

vk: a capture's wait for write-back 744650 timed out (done 744646)
nvn: GPU waits in 5 s: 1 sync waits (5133 ms), 0 polls timed out (0 ms), 1 queue finishes (1 ms)
vk: submit 744664 failed (-4)
vk: device lost: reading the fault info (RX_VK_CHECKPOINTS=1 for markers)

Same pattern as the RX 6650 XT report above. Happy to rerun with RX_VK_CHECKPOINTS=1 once #734 is in a release.

Same here on an **RX 6800 (16 GB)**, Windows 11, Ryzen 7 5800X3D, v2.0.2, AMD driver 0x800161, so this looks like it affects RDNA 2 generally, not just the 6600 (and not an 8 GB VRAM limit). Runs well up to this point (steady 60 fps in Kokiri Forest with ~1000 draws/frame). Inside the Great Deku Tree the frame rate drops to ~10 fps, then: ``` vk: a capture's wait for write-back 744650 timed out (done 744646) nvn: GPU waits in 5 s: 1 sync waits (5133 ms), 0 polls timed out (0 ms), 1 queue finishes (1 ms) vk: submit 744664 failed (-4) vk: device lost: reading the fault info (RX_VK_CHECKPOINTS=1 for markers) ``` Same pattern as the RX 6650 XT report above. Happy to rerun with `RX_VK_CHECKPOINTS=1` once #734 is in a release.

Flo-za commented

2026-11-08 19:58:04 +00:00

(Migrated from github.com)

Still happens on v2.0.3 (source 73ddf2ad), same RX 6800 / driver 0x800161. Robust buffer access on, default options. About two minutes after loading a save near the Deku Tree, running 45–55 fps with nothing compiling, then straight to:

vk: submit 51037 failed (-4)
vk: device lost: reading the fault info (RX_VK_CHECKPOINTS=1 for markers)

So the v2.0.3 fixes (buffer pointers, #487) don't cover this one.

Still happens on **v2.0.3** (source 73ddf2ad), same RX 6800 / driver 0x800161. Robust buffer access on, default options. About two minutes after loading a save near the Deku Tree, running 45–55 fps with nothing compiling, then straight to: ``` vk: submit 51037 failed (-4) vk: device lost: reading the fault info (RX_VK_CHECKPOINTS=1 for markers) ``` So the v2.0.3 fixes (buffer pointers, #487) don't cover this one.

Stickman803 commented

2026-11-09 00:53:03 +00:00

(Migrated from github.com)

Same family on an RX 6700 XT (12 GB), Windows 11, AMD driver 0x800161, v2.0.3 (source 73ddf2ad), Frame pacing On, Resolution 100%, Lanczos.

About 90 minutes into a session, in Kokiri Forest just outside the Great Deku Tree (right after his cutscene), running 47-50 fps with nothing compiling. No device lost this time: a silent hang. The Presentation Thread stops logging entirely, the GPU goes idle (0% 3D), audio/vibration threads keep going, and the last line from the main thread is:

[hos sead::MainThread] nvn: CommandBufferWaitEvent #5550000: event 0x100d6c802c mode 0 value 4196824 (now 4196805) (lr 0x8028c554)

The last frame before it reported 232680 presents, 50.0 fps; 669 draws (0 skipped) ... 3098 pipelines, 2.0 draws left out (not ready), 52 jobs queued. Window stayed responding; only a kill recovered it.

Log (first 300 and last 4000 lines): https://gist.github.com/Stickman803/d63824e10425a40739840d69e02fbc93

Now on v2.0.5; will report whether it recurs.

Same family on an **RX 6700 XT (12 GB)**, Windows 11, AMD driver 0x800161, **v2.0.3** (source 73ddf2ad), Frame pacing On, Resolution 100%, Lanczos. About 90 minutes into a session, in Kokiri Forest just outside the Great Deku Tree (right after his cutscene), running 47-50 fps with nothing compiling. No device lost this time: a **silent hang**. The Presentation Thread stops logging entirely, the GPU goes idle (0% 3D), audio/vibration threads keep going, and the last line from the main thread is: ``` [hos sead::MainThread] nvn: CommandBufferWaitEvent #5550000: event 0x100d6c802c mode 0 value 4196824 (now 4196805) (lr 0x8028c554) ``` The last frame before it reported `232680 presents, 50.0 fps; 669 draws (0 skipped) ... 3098 pipelines`, `2.0 draws left out (not ready), 52 jobs queued`. Window stayed responding; only a kill recovered it. Log (first 300 and last 4000 lines): https://gist.github.com/Stickman803/d63824e10425a40739840d69e02fbc93 Now on v2.0.5; will report whether it recurs.

pcornejov commented

2026-11-09 03:45:50 +00:00

(Migrated from github.com)

Same family on a Radeon 890M iGPU (Ryzen AI Z2 Extreme, ROG Xbox Ally X), Windows 11, AMD driver 32.0.32015.5008 (0x800196), v2.0.5, 8 GB UMA frame buffer (Vulkan reports a 10252 MB device heap).

Loading a save puts the GPU in a device lost. I tried 4 times, with different settings, and each time it happened within seconds of the load, while the area was still coming in. Before the load the game was fine: 60 fps at the title, 30-45 fps in Kokiri on a new game.

Run	Settings	What happened
1	Low (6GB) preset, 75%, handheld, frame generation 2x, `RX_VK_VRAM_MB=4096`, `RX_VK_MIRROR_MB=1024`	`slow submit: 25174.2 ms: slot wait 25176.3`, then `submit 16377 failed (-4)`. The whole system froze and needed a power-button reset (bugcheck 0x1C8).
2	Same, frame generation off, no `RX_VK_*` caps	`1 sync waits (2499 ms)`, then `submit 11558 failed (-4)`
3	Defaults (Custom)	Not a device lost: the process reached 23.8 GB private while running at 38 fps, and I closed it before the commit limit (31.6 GB at the time) ran out
4	Defaults, commit limit raised to 47.6 GB	`1 sync waits (2462 ms)`, then `submit 9269 failed (-4)` on the host thread, just after `slow submit: 110.2 ms: dispatch 110.1`

[hos host] vk: slow submit: 110.2 ms: dispatch 110.1
[hos sead::MainThread] nvn: GPU waits in 5 s: 1 sync waits (2462 ms), 0 polls timed out (0 ms), 1 queue finishes (0 ms)
[hos host] vk: submit 9269 failed (-4)
[hos host] vk: device lost: reading the fault info (RX_VK_CHECKPOINTS=1 for markers)

Other things I noticed:

Memory grows quickly after the device lost. The process goes from about 16 GB private at the title to 30-31 GB within a minute, while GPU time reads 0.0 ms a frame. With a 32 GB commit limit, that is what froze the whole machine in run 1.
Pressing F11 during play also caused one device lost (vkCreateSwapchainKHR failed (VkResult -4, extent 1920x1080 ...), after a 9.8 s queue submit). Starting with HOS_FULLSCREEN=1 works fine.
The Low/Balanced presets do not cap memory on this iGPU. preset_caps_memory() compares against the 10252 MB device heap, so on an 8 GB UMA setup no preset below High applies its budgets.
Earlier report: I first reported the white-silhouette Link on 2.0.2 in #224.

I haven't run with RX_VK_CHECKPOINTS=1 yet. I can do that, or test #886 (native float atomic add) if a build is available.

Same family on a **Radeon 890M iGPU** (Ryzen AI Z2 Extreme, ROG Xbox Ally X), Windows 11, AMD driver 32.0.32015.5008 (0x800196), **v2.0.5**, 8 GB UMA frame buffer (Vulkan reports a 10252 MB device heap). **Loading a save puts the GPU in a device lost.** I tried 4 times, with different settings, and each time it happened within seconds of the load, while the area was still coming in. Before the load the game was fine: 60 fps at the title, 30-45 fps in Kokiri on a new game. | Run | Settings | What happened | | --- | --- | --- | | 1 | Low (6GB) preset, 75%, handheld, frame generation 2x, `RX_VK_VRAM_MB=4096`, `RX_VK_MIRROR_MB=1024` | `slow submit: 25174.2 ms: slot wait 25176.3`, then `submit 16377 failed (-4)`. The whole system froze and needed a power-button reset (bugcheck 0x1C8). | | 2 | Same, frame generation off, no `RX_VK_*` caps | `1 sync waits (2499 ms)`, then `submit 11558 failed (-4)` | | 3 | Defaults (Custom) | Not a device lost: the process reached 23.8 GB private while running at 38 fps, and I closed it before the commit limit (31.6 GB at the time) ran out | | 4 | Defaults, commit limit raised to 47.6 GB | `1 sync waits (2462 ms)`, then `submit 9269 failed (-4)` on the host thread, just after `slow submit: 110.2 ms: dispatch 110.1` | ``` [hos host] vk: slow submit: 110.2 ms: dispatch 110.1 [hos sead::MainThread] nvn: GPU waits in 5 s: 1 sync waits (2462 ms), 0 polls timed out (0 ms), 1 queue finishes (0 ms) [hos host] vk: submit 9269 failed (-4) [hos host] vk: device lost: reading the fault info (RX_VK_CHECKPOINTS=1 for markers) ``` Other things I noticed: - **Memory grows quickly after the device lost.** The process goes from about 16 GB private at the title to 30-31 GB within a minute, while GPU time reads 0.0 ms a frame. With a 32 GB commit limit, that is what froze the whole machine in run 1. - **Pressing F11 during play also caused one device lost** (`vkCreateSwapchainKHR failed (VkResult -4, extent 1920x1080 ...)`, after a 9.8 s queue submit). Starting with `HOS_FULLSCREEN=1` works fine. - **The Low/Balanced presets do not cap memory on this iGPU.** `preset_caps_memory()` compares against the 10252 MB device heap, so on an 8 GB UMA setup no preset below High applies its budgets. - **Earlier report:** I first reported the white-silhouette Link on 2.0.2 in #224. I haven't run with `RX_VK_CHECKPOINTS=1` yet. I can do that, or test #886 (native float atomic add) if a build is available.

NotRexed commented

2026-11-09 05:53:57 +00:00

(Migrated from github.com)

Tracked in #996, follow there. That issue collects every report of AMD driver crashes, device lost and freezes on Windows, 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.

Tracked in #996, follow there. That issue collects every report of AMD driver crashes, device lost and freezes on Windows, 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`.