[Tracking] AMD on Windows: driver crash, device lost or freeze (RX 5000-9000, Deku Tree / after cutscenes) #996
Labels
No labels
accessibility
autorelease: pending
autorelease: tagged
bug
dependencies
documentation
duplicate
enhancement
github_actions
good first issue
help wanted
invalid
question
testing wanted
wontfix
No milestone
No assignees
2 participants
No due date set.
Dependencies
No dependencies set
Reference
MagicBeanDev/Hookshot#996
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This issue collects every open report of AMD driver crashes, device lost and freezes on Windows, so there is one place to follow it. The individual reports were closed pointing here; their logs, screenshots and discussion stay in each linked issue.
Summary
What happens: an AMD driver timeout (black screen, "AMD driver error", sometimes a full system reset),
VK_ERROR_DEVICE_LOST, or a picture freeze while the audio continues.When it happens:
Mostly RDNA2 cards (RX 6600 / 6650 XT / 6700 XT / 6800 / 6900 XT) on driver 0x800161 (26.10.1 / 26.10.2), and also RX 7600 and RX 9060 XT / 9070 XT.
Affected GPUs and versions
Evidence from the logs
submit N failed (-4)) after minutes of play: #708 (7 people), #150 (the older device-lost thread, 30 people).graphics pipeline for 5fa56485a6b07619 / 6eaa646d07ea4e43 not made (-13)in #305, #360, #461, #916, and #935 (4e5ce183 there too). On v2.0.2, "Preparing shaders" hung at 99% on it; v2.0.3 lets the game start anyway.RX_VK_NO_MESH=1avoids it, so the hang is on the mesh path. The log showsstorage buffer NOT boundfor 68642bb8, 6b4dea60, 51183fe7 (c5+0x1d0), 739acd67 and d905f52b (c5+0x60). AMD gives no checkpoints.Workarounds
RX_VK_PRECOMPILE=0: avoids the 99% "Preparing shaders" hang (#305).RX_VK_NO_MESH=1: avoided the first-frame device lost in #602.RX_VK_KEEP_RETIRED=1: stopped the crashes in #571, but grass and trees flickered.HOS_NO_RENDERER_WAIT=1: fixes the AMD black 3D in #120 (see the black-screen tracker).Reports merged here (23 issues, about 71 people)
9bb52a9table ordering (device-lost-fix), retired pools kept on Windows (fast-updates), bounded CAS loops (v2.0.2). Still: RX 6900…Adding a report
Please update to v2.0.6 first (https://github.com/NotRexed/Hookshot/releases/tag/v2.0.6; Update next to Play in the launcher). Please add: GPU, driver version, where it happens, and every
hookshot_log*.txtfrom that session (the-4/-13lines and the last lines matter).All tracking issues
Reproducible trigger on RX 6800 (16 GB), Adrenalin 26.10.1 (driver 0x800161), Windows 11, Ryzen 7 5800X3D, v2.0.7 (source 9b541c9c), default options: burning the spider web at the bottom of the Great Deku Tree (after lighting the first torch). The picture freezes, goes black, and Windows drops back to the desktop (driver reset). The game keeps running with no window: audio continues and the log keeps writing, so it has to be ended in Task Manager.
Log at the hang:
Preparation on this driver: 38809 programs, 165 failed. Same crash earlier on v2.0.2/v2.0.3 (my comments on #708).
Update:
RX_VK_NO_MESH=1works around it. Same save, same spot: with it set, burning the web goes through fine, no device lost, steady ~60 fps afterwards (and almost no mesh draws in the log). So on RDNA2 / RX 6800 the hang is on the mesh path, matching #602.Crash on our test system. Going past Title Screen > Intro > Kokiri Forest, Black Screen with Triforce loading, crash back to desktop with no warning.
hookshot_log.txt
White screen in cutscene after ghoma on version 2.0.7
hookshot_log.txt
RX_VK_NO_MESH=1also works around it on a Radeon 890M iGPU (Ryzen AI Z2 Extreme, ROG Xbox Ally X), Windows 11, AMD driver 32.0.32015.5008 (0x800196), 8 GB UMA. This is the same report as my comment on #708.On v2.0.5 with default options, every run ended in
submit N failed (-4)and a device lost: 3 runs after loading a save and 1 during the Deku Tree's dialogue on a new game. One of them took the whole system down (power-button reset).On v2.0.7 with
RX_VK_NO_MESH=1inhookshot_env.txt, the same save loaded fine. I played for several minutes in Kokiri at about 33-48 fps: 0 device lost, 0 skipped draws and about 14,000 presents. So on this RDNA 3.5 iGPU the hang is on the mesh path too, as Flo-za found on the RX 6800 and as #602 reported.What is left on this machine is memory, not the GPU. The process reaches about 28 GB private, but Windows has only 15.6 GB of RAM (8 GB is carved out for the iGPU), so 5.6 GB ends up in the pagefile and play stutters. On v2.0.5 (#708), the device lost also made private memory jump from about 16 GB to 31 GB within a minute.
Log: hookshot_log.v2.0.7-nomesh.txt (can attach if useful).
RX 9070 (RDNA4): device lost at the first draw of any task+mesh program, while mesh-only programs run
Diagnostics from an RX 9070 with the same crash as this issue: right after the intro, at the first gameplay frame.
System
What happens
submit N failed (-4)and device lost at the first gameplay frame after the intro.RX_VK_NO_MESH=1runs fine.RX_VK_CHECKPOINTS=1(VK_AMD_buffer_marker) the result is the same every time:RUNNING after: marker ... (draw of program a5da9f84b72d1471). The markers before it are a dispatch of499dbfd0721d2858and draws of155b02322a3ee490. It is the first task/mesh draw of the session (vkCmdDrawMeshTasksEXT(2, 1, 1)).a5da9f84b72d1471:DispatchMesh(ThreadGroupCount=[2,1,1]).Ruled out - each of these still hangs at the same draw:
RX_VK_MESH_OPT=1(the driver's optimizer on).mainis onlyOpEmitMeshTasksEXT 0 1 1 %payload. It still hangs at the first draw. The mesh stage never runs, so the task code itself isn't the cause.VK_PIPELINE_STAGE_2_TASK_SHADER_BIT_EXTout of their stage masks.a5da9f84b72d1471passspirv-val --target-env vulkan1.3 --scalar-block-layout.What works
So on this card, any Hookshot pipeline with a task stage hangs at its first draw, even with a task shader that starts no mesh workgroups, while mesh-only pipelines run. AMD runs task shaders on a compute engine beside the graphics one, and the graphics side waits for the task side's output. With no wave in flight, the task side apparently never ran.
Suggestion
Until the cause is found, on RDNA4:
The attached patch against v2.0.9 is the test build I used.
RX_VK_SKIP_TASK_DRAWS=1is the workaround. The other switches are the diagnostics above:RX_VK_LANES_TASK/RX_VK_LANES_MESH,RX_VK_STUB_TASK/RX_VK_STUB_MESH,RX_VK_NO_TASK_SYNC,RX_VK_TASK_NO_PUSH_DESCRIPTORS/RX_VK_TASK_NO_PUSH_CONSTANTS,RX_VK_SPV_DUMP, and a mesh limits check.I'm happy to run more tests on this card.
rdna4-task-test-build.patch
Still the same issue as #722 with version 2.0.11 (Clicking the hookshot desktop shortcut opens a black command window for 2 seconds then it closes. The game (OOT) does not start and there is no process in Task Manager)
hookshot_log.txt
Processor AMD Ryzen 7 7800X3D 8-Core Processor 4.20 GHz
Installed RAM 32.0 GB (31.4 GB usable)
Storage 932 GB SSD WD Green SN350 1TB
Graphics Card AMD Radeon RX 6750 XT (12 GB)
Hookshot v2.0.11
TITLE: Crashing in kokiri forest after talking to Saria and caching new actions or items
hookshot_log.txt
Crashes consistent through these symptoms, walking away from saria on the road in front of your house, breaking pots, stalling when caching data long pauses up to 20 seconds or more
RX 6400 4GB on latest Adrenalin 26.10.1
Ryzen 5 5600G with 16GB RAM running Hookshot v2.0.11 on Windows 10
It was running fairly well considering the limited memory (in handheld mode) until I reached halfway through the tree, where it started to randomly crash the GPU driver (device lost).
hookshot_log.txt
RX 6700 XT on v2.0.11, 1 hour: no crash or device lost, but 5 freezes at boss fights, cutscenes and area changes
hookshot v2.0.11 (source d6369f1e)RX_VK_CHECKPOINTS=1, plus the #1004 lighting workaround (RX_VK_TAAU_KEYS=-,RX_VK_MMA_SOFTWARE=1). No overlays or injectors.Result: about 1 hour (Fire Temple, Volvagia, Great Fairy Fountain, Biggoron). No crash and no
-4/ device lost anywhere in the log; I closed the game myself. Much more stable than rc.5. But the game froze five times and recovered on its own each time:| Time | Where | Freeze (from the log's 5 s frame reports) |
| ~00:04 | Fire Temple, Flare Dancer fight | ~14 s |
| ~00:20 | Volvagia intro cutscene starts | ~107 s (
1.7 fps over the last 107.4 s,the game read no controller for 103.6 s) || ~00:22 | Volvagia fight | ~11 s |
| ~00:25 | Volvagia death cutscene | ~25 s |
| ~00:33 | Entering the Great Fairy Fountain | ~31 s (this one wrote the hang dump, 154543 presents) |
There was also some stutter (not a full freeze) in the Biggoron cutscene.
What I see in the log: right before the two longest freezes (00:20 and 00:33) there are new
vk: in play: graphics ...lines (pipelines built during play), and during the long Volvagia freeze VRAM was nearly full (VRAM: 9820 MB used of 10846 MB allowed). Not sure if either is the cause.At start-up, 4 graphics pipelines failed with
-13, including5fa56485a6b07619and6eaa646d07ea4e43, the same two listed for #461 (RX 6700) in the table above. The other two are4e5ce183a33b0855andf0bdd28d1b029606. The start-up line also says151 failedout of 38809 shader programs.hang_v2011_lighttest_20261110_0033.txt
hookshot_v2011_lighttest_20261109_233707.txt
@Leontfk I am trying the above, I have a similar build, Ryzen 7 9800X3D / RX6800
I tried with RX_VK_SKIP_TASK_DRAWS=1 as mentioned at the above but did not resolve the crashes for me;
Testing the following env options and will update.
RX_VK_SKIP_TASK_DRAWS=1
RX_VK_CHECKPOINTS=1
RX_VK_TAAU_KEYS=-
RX_VK_MMA_SOFTWARE=1
Edit: Still crashing at times
White screen stuck after Deku Tree’s Triforce story — AMD RX 7700S (v2.0.11)
I’m experiencing a reproducible cutscene issue on Hookshot v2.0.11.
After the Great Deku Tree finishes explaining the Triforce, the game intentionally transitions to a white screen before showing Ganondorf.
However, the screen stays completely white indefinitely instead of transitioning into the Ganondorf scene.
I can hear what sounds like Ganondorf’s loud footsteps during the white screen, suggesting that at least part of the next cutscene is progressing, but the visuals never appear.
System:
Troubleshooting attempted:
The white-screen transition problem occurs consistently at the same point.
Is this specific cutscene transition issue already being tracked, and is there a known fix or workaround?
Had this problem, then retried and waited a few minutes, eventually it got past the white screen.
I'm using no hookshot_env file. System specs at #996
hookshot_log.txt
same here. crashing while walking on lon lon ranch...
Folded in: #1015 (RX 6700 XT on v2.0.5+: freeze / device lost at every Kakariko to Death Mountain Trail transition), a reliable repro for this family, plus #1465 and #1479 earlier.
Follow-up from my RX 6800 report above, now on v2.0.11 (source d6369f1e), still Adrenalin 26.10.1 (0x800161), with
RX_VK_NO_MESH=1.The no-mesh workaround keeps holding against the device lost: ~42 minutes of play (about 150k presents) at 55–60 fps, no
failed (-4)ordevice lostat all.But a different hang in the Sacred Forest Meadow maze, right after the arrival cutscene, when approaching the first enemy (it renders as a bright white silhouette, see #1006): the picture freezes while the music keeps playing, and the game has to be closed. The log shows no device lost, no GPU waits or timeouts. The presentation and main threads simply stop logging while the vibration thread carries on for ~43 s until I closed the window (
display: window closed, exiting). Last frames were ~56 fps with ~2100 draws.Also earlier in the same session:
graphics pipeline for 5fa56485a6b07619 not made (-13)and6eaa646d07ea4e43 not made (-13), the same pipelines as in #305 / #360.For RX 5000 cards (no mesh shaders): part of the multi-second freezing came from the mesh fallback compiling its compute pipelines inside the draw, which took up to 12 s each on the AMD driver. #1512 moves that to a worker and to the precompile. Tested on an RX 5500M.
Still happens on v2.0.12: the game freezes after closing the in-game menu (RX 6650 XT, Windows).
Hookshot version: v2.0.12 (source 3f168e10)
GPU / driver: AMD Radeon RX 6650 XT (8 GB), Adrenalin 26.10.1, log says driver 0x800161, Vulkan 1.4
CPU / RAM / OS: [CPU], 16 GB (log: 15989 MB, 24517 MB swap), Windows [10/11]
Output: fullscreen 2560x1440 swapchain, game resolution 2048x1152, render targets 1536x864 (I lowered the render scale to 75%)
What happens
I open the Settings menu (same thing also happens in inventory menu ) in Hyrule Castle. The menu works, but when I close it the game freezes and never comes back (I waited about 5-10 minutes). The music stops but the water sounds continues. It happens every time since last update. In the previous versions this bug was there but it was happening rarely but now in v2.0.12 it happens every time.
Since the update and the lower resolution the earlier "device lost" crashes no longer happen for me, so this is a different problem.
hookshot_log.txt
What the log shows (hookshot_log.txt attached, whole session)
longjmp to 0x81681690 (value 1, 0 slots above dropped)lines during that time: ModuleSystemWorker2 at ~8448 and ~8655, sead::MainThread at ~8880. (My v2.0.11 log has the same longjmp once around an area load, so it may be unrelated.)9000 presents, 60.0 fpsline is the final one: after it there are no moreN presentslines (every 120) orvi: N frames presentedlines. Only rmbl::VibrationThread lines continue for roughly 20 s, untildisplay: window closed, exiting, which is me closing the window.device lost, nosubmit ... failed, nocapture's wait for write-back ... timed out, and nomutex ... waiting 10 swatchdog line (that watchdog did print one for nn.npln.Worker at startup). VRAM was not near the limit:5327 MB used of 6286 MB allowed.So this looks like a CPU-side stall when the menu closes, not the GPU hang from #150. Same symptom as #749, #872 and #938. The table here says the earlier logs for the menu freeze only covered the preparation phase; this one covers the freeze itself.
Happy to test builds or run with extra logging (e.g. RX_VK_CHECKPOINTS=1).
v2.0.12: repeated VK_ERROR_DEVICE_LOST while walking in Hyrule Field — RX 6800 XT / Windows 10
I am getting repeated crashes to desktop while walking around Hyrule Field. This looks similar to #1492, which was routed here, but my logs are already from v2.0.12 (source 3f168e10).
System
0x800161as reported by Hookshot. The Adrenalin package version has not been confirmed.What the five logs show
Four logs end with
submit ... failed (-4)and the fatalVK_ERROR_DEVICE_LOST. Before each fatal error there are repeateda capture's wait for write-back ... timed outmessages and roughly 250 ms memory-sync stalls, followed by a multi-second GPU/slot wait.hookshot_log.txthookshot_log.2.txthookshot_log.3.txthookshot_log.4.txthookshot_log.1.txtends withdisplay: window closed, exitingrather than a fatal device-lost message. It also has write-back timeouts earlier, so those timeouts alone do not distinguish the crashing runs. The last recorded VRAM values do not show the card reaching its reported budget; there is no out-of-memory error in these logs.All five logs also contain the same two startup pipeline failures already mentioned in this tracker:
I cannot tell whether those startup failures are related to the later GPU hang.
End of the latest crash log (hookshot_log.txt)
The exact position/route and time of day have not been isolated. No workaround has been verified on this PC yet. Is there a targeted test or capture that would help identify the remaining RDNA2 GPU hang?
Log availability: the five logs were inspected locally; the table and excerpts above come from them. Full-file attachment upload was blocked by the browser extension's local-file permission, so the complete logs are not attached to this comment. Redacted copies have been preserved.
@NotRexed linking PR #1657 for the RDNA 1 / RX 5000 reports collected here.
It corrects stage-specific wave32/wave64 assumptions and the AMD proprietary fragment-shuffle path, with cache invalidation when the subgroup profile changes. It overlaps the related work in #1507, which is acknowledged in the linked discussion on #1001.
The renderer build and targeted CPU/SPIR-V checks passed locally. Testing this exact current-main build in-game is still pending, so this does not yet establish a fix for the driver timeouts, device-lost errors or reboots in this tracker. The PR includes a clearly identified historical RX 5500 XT screenshot and the validation details. Its CI workflows currently need maintainer approval.
One data point for this tracker, from an RX 7800 XT (16 GB, Windows 11, driver 0x8001a0), with the caveat that my build is not stock:
release/v2.0.12+ PR #1130 + local changes, and the crash happened with an experimental, off-by-default 16x16x16 cooperative-matrix switch turned on (see #1284), at 2560x1440 render scale 100%.About 1.5 minutes after start, right after the scene load: Windows logged
LiveKernelEvent 141(GPU hang) and the game printedVK_ERROR_DEVICE_LOST. The log before it:write-back diff: VRAM 14704 of 14832 MB: the shadows given back (352 MB), threea capture's wait for write-back N timed out (done N-4)(250 ms each),slow submit: 12196 ms: slot wait,submit 27420 failed (-4), then the FATAL line. So the GPU stopped making progress at one submission and everything waited behind it.Controls: I could not reproduce it in a scripted headless run (VRAM 7.5 GB in that scene). A 19-minute normal session with the same 100% / 1440p settings and the matrices switch off reached
VRAM 14849 MB used(the allowed value, 14834 MB) and had no device lost. So VRAM at the limit alone did not hang the GPU there; the experimental matrix path may be involved, but I have not isolated it. I will post the result of a clean repeat.For VRAM accounting on this card (same scene, several configurations): textures 3.0-4.2 GB, and 3.5-3.9 GB of VRAM that is not textures whatever the image block size (64 or 128 MB) or whether the image pool is preallocated; the mirrors are about 2.1-2.4 GB of it. Outside the game, DWM holds 838 MB and Radeon Software 325 MB, and the allowed value the game sees dropped from 15408 to 14785 MB during one session.
v2.0.13 : hookshot_log.txt
v2.0.13 : coredump.txt
I think it's not windows precific I have the same with :
Ubuntu 26.04:
AMD RX 6700XT 12G, Core i7 32Gb
Core dump
The crash occurs during the intro when Navi is in the village. The specific scene is the one with Saria and her ocarina.
@NotRexed
GPU hang / device lost on desktop AMD (amdvlk) — same task shader as #817
System
What happens
The GPU hangs (driver timeout / device lost) and the game then crashes with an
access violation inside amdvlk64.dll (amdvlk64.dll+0x319b63 on v2.0.5), inside
vkQueueSubmit, so the checkpoint report never runs. Right before it the fps drops
to ~3 for several seconds.
Not VRAM related (it hung at ~73% VRAM use).
What I found
The program running at the hang was 136d9555efa9a389 on v2.0.11, task shader code
key 2c56dc1006942f74 — the same one as #817 (Steam Deck), so it doesn't look
Deck/RADV specific.
still hangs at ...]
Suggestion
If NOCULL is confirmed on both RADV and amdvlk, maybe enable it by default for this
task shader on AMD.
Log attached (hookshot_log.txt from a session that hung).
Additional AMD GPU driver crashes — Hookshot v2.0.13
I’m reporting reproducible graphics-driver crashes across three separate AMD-powered Windows systems, while the same game runs without these crashes on an NVIDIA laptop.
Affected hardware
System 1 — AMD Radeon RX 6800
System 2 — AMD Radeon RX 6800 XT
System 3 — ASUS ROG Xbox Ally X
Windows crash evidence
Windows recorded:
These observations are consistent with an AMD graphics-driver timeout or GPU hang, although the exact triggering rendering operation has not been identified.
Troubleshooting already attempted
NVIDIA comparison
MSI laptop — NVIDIA RTX 3080 Ti 16 GB
Hookshot runs considerably more reliably on this system, without the AMD-style driver crashes experienced on the three other machines.
Observations
The issue does not appear isolated to a particular AMD GPU or a single installation.
The RX 6800 and RX 6800 XT exhibit similar camera-rotation-related crashes, while the Ryzen Z2 Extreme experiences crashes during area transitions.
These different triggers could involve shader compilation, graphics pipeline creation, resource synchronization, or other Vulkan rendering operations. These are possible explanations, not confirmed root causes.
Request to developers
Could the AMD Vulkan rendering path be investigated for the camera-rotation and area-transition crashes, particularly on RDNA 2 and Ryzen Z2 Extreme hardware?
The issue persists through Hookshot v2.0.13.
I can provide additional reproduction details if needed. No renderer logs or crash dumps are attached to this report.
crashing on 6800 xt , ryzen 5700x 3d
hookshot_log.txt
crashing in hyrule field
thanks for everything
freeze few second after entering gameplay
hookshot_log.1.txt
hookshot_log.2.txt
hookshot_log.3.txt
hookshot_log.4.txt
hookshot_log.txt
Freezes after closing menu in Kokiri Forest
v2.0.13: hookshot_log.txt
RX 6650XT, Ryzen 5600 16GB, Windows 11
RX 6600 8 GB, Windows 11, v2.0.13. Device lost every few minutes (Hyrule Field, Zora's River, Death Mountain Trail); audio keeps playing, then amdvlk resets the GPU. Two causes found, both fixed locally (30k+ frames without a hang; before it was ~4k):
1.
RX_VK_MESH_NOCULLdoes not remove the grid walk.mesh_nocull()forces the culling answer, butDeadCodeEliminationPasskeeps the loops: the task shader2c56dc1006942f74(1078 programs here) still has both loop nests in its SPIR-V, bounded only by the 0x2000 safety counter, so a draw still ran past the driver timeout (hung with NOCULL applied, e.g. program7c2b0903f0abf0e2). Fix: whenmesh_nocullapplied, emit that task shader with a loop safety counter of 0 (one pass each).2. Scene lighting fragment shaders (e.g. programs
8d944be587ec7082,e0a3c4b90331191e) loop over a light list whose count is read from a storage buffer. With a garbage count each pixel runs up to 0x2000 passes of a ~2000-instruction body. Fix: a loop safety counter of 32 for fragment stages (256 still hung).Both are the
Repeatnode's safety counter inemit_spirv.cpp.Also useful for diagnosis: a watchdog thread that logs the buffer markers when the timeline has not advanced for 1.5 s while a marker is reached but not finished. On amdvlk the reset closes the window before any submit returns
VK_ERROR_DEVICE_LOST, so the marker report was never written.Unrelated to the hang: on this card program
53509044401d78d2leaves glowing white/green/red triangles on Hyrule Field terrain;RX_VK_SKIP_PROG=53509044401d78d2removes them.Tested on one machine only. I can share the patches.
hookshot_log.txt
on steam deck crashes after intro cutscene (v2.0.14)
Update 2.0.13 and 2.0.14 brokes the "RX_VK_NO_MESH=1" workaround
hookshot_log.txt
hookshot_log.1.txt
hookshot_log.2.txt
hookshot_log.3.txt
The issue is still occurring in version 2.0.14.
This time, the game crashes in the Death Mountain area. I also tested the game with all graphics settings set to the lowest possible settings, but the crash still happened exactly the same way.
The log again shows a Vulkan GPU device loss:
vk: submit 7906 failed (-4)vk: device lostVK_ERROR_DEVICE_LOSTSo lowering the graphics settings does not seem to prevent the crash. The issue is still present in version 2.0.14 and appears to be related to the Vulkan/AMD GPU device loss.
hookshot_log.1.txt
hookshot_log.txt
@rbx-br thanks for the logs. We checked what changed: the code that reads
RX_VK_NO_MESHand the one that loads hookshot_env.txt are identical in v2.0.12 and v2.0.14 (between those releases only the menu, the game clock and the build's patches changed, nothing on the GPU side). Your log (RX 6900 XT, driver 0x800161) ends in a device lost after "pool ... remade larger", but it can't show whether the switch was set, because nothing is printed when it is. Could you check three things?binfolder)?same here, 6800 xt ryzen 5700x3d. gpu losing signal, black screen.
@NotRexed Sorry. I recompiled everything from scratch and lost the previous logs, but I can confirm that the workaround works with FG disabled, by using "RX_VK_NO_MESH=1" and "RX_VK_FSR_FG=0" in the .bat file. There is a new bug when opening the inventory: the game freezes.
hookshot_log.txt
Im having the load game crash issue with a RX 6700 XT. The thing is that is was playing normally and i decided to manual save and close the game. After that, im not able to load the manual save file or even the autosaves. I leave attached some logs.
Thanks a lot!
hookshot_log.2.txt
hookshot_log.txt
hookshot_log.1.txt
Crashing when approaching the Zora Domain entrance. RX6800
hookshot_log.1.txt
[RX 6950 XT / Navi 21] Reproducible VK_ERROR_DEVICE_LOST after new-game intro — native and compute mesh paths (v2.1.0)
Hi! I'm experiencing a consistently reproducible crash on an AMD RX 6950 XT under Windows 11. The game exits immediately after the opening cinematic of a new game.
I tested both native mesh shaders and the compute fallback, but both result in
VK_ERROR_DEVICE_LOST.System specifications
0x800161(as reported by Hookshot)633eb435Steps to reproduce
The crash occurs consistently at this transition, before I can begin normal gameplay.
Tests performed
Test 1 — Native mesh shaders
Relevant log entries:
Test 2 — Compute mesh shader fallback
The log confirms that the compute path was active:
The precompilation phase also reports 986 mesh fallback programs.
Immediately before the crash:
Test 3 — Compute fallback with AMD Anti-Lag 2 disabled
Memory observations
In the compute fallback log, shortly before the crash:
VRAM exhaustion therefore seems unlikely.
Both attached logs show the crash occurring shortly after GPU memory pools are imported or resized and mesh draws are submitted.
Additional observations
The behavior resembles #150, particularly the
VK_ERROR_DEVICE_LOSTfollowing GPU memory pool operations.Attachments
hookshot_native_sanitized.log— Native mesh shaders, Anti-Lag 2 enabled.hookshot_compute_sanitized.log— Compute fallback, Anti-Lag 2 enabled.The Windows username and save identifier have been redacted from both logs.
Please let me know if there are specific diagnostic flags or a newer build you would like me to test.
Thanks for your work on Hookshot
RX 6600 (Windows 11, v2.0.13): device lost, buffer markers point at lighting program
e0a3c4b90331191eSame hang as @dynamo18 described above (cause 2, the scene lighting fragment shaders), on the same card, this time with the marker report written to the log.
System
robust_buffers=1What happens
A hitch of about 4 seconds, the window closes and the AMD driver resets. It crashes every time at the same place: Death mountain trail. Five sessions in a row ended this way.
It also happened with frame generation on, with
robust_buffers=0and in fullscreen. With frame generation on, one run ended in an access violation insideamdvlk64.dll+0x319b63after the same hang instead of a device lost.Markers (
RX_VK_CHECKPOINTS=1)vk: a capture's wait for write-back 19029 timed out (done 19025)
nvn: GPU waits in 5 s: 1 sync waits (4866 ms), 0 polls timed out (0 ms), 2 queue finishes (10 ms)
vk: submit 19044 failed (-4)
vk: device lost: 565222 markers set, 62700 reached; the last whose earlier work all finished: 562343
vk: finished before: marker 562342 (draw of program 805756a6a63b9ee7, frame 2718)
vk: RUNNING after: marker 562343 (draw of program e0a3c4b90331191e, frame 2718)
vk: running: marker 562344 (draw of program e0a3c4b90331191e, frame 2718)
vk: reached, earlier work unfinished: marker 562344 ... 562355 (all draws of program e0a3c4b90331191e, frame 2718)
Other details
Logs attached: the session with markers, and an earlier one without.
hookshot_log.1.txt
hookshot_log.txt
I tested the game on version 2.1.0 after enabling the new option.
This time, the game did not crash, and I also did not get the AMD driver error that previously appeared after the crash.
However, I initially noticed a significant increase in the game's RAM usage. The game was using around 22 GB of RAM.
After restarting the game, its RAM usage dropped and is now around 14–15 GB.
Test system:
So far, the previous crash/AMD driver reset did not occur during this test. The game initially used around 22 GB of RAM, but after restarting, it is now using approximately 14–15 GB.
On the RAM observation above (about 22 GB, then 14-15 GB after restarting the game): we measured the same shape on an RX 9070 XT, 32 GB RAM, Windows 11, v2.1.0, and it follows which start built the shader programs.
Same save, same spot, 3840x2160:
0 program keys kept, thenprepared 38809 shader programs)46604 program keys kept)So the heavy run is the one start that builds the programs (the first after an update, or after the store was emptied), and the next start is the light one. The trim that gives this memory back after translation is Linux-only in the source. Runs, tables and two things we tried on Windows (emptying the working set once after the build; the game starting itself again after the build) are in #2180:
#2180
#2180
hookshot_log_goron_city_crash.zip
v2.1.0: still device lost on RX 6800, but much later. Automatic picks the native path, not the task+mesh fallback
End of the log:
Possibly useful: on start-up the log shows
So the task+mesh compute fallback from #1747 doesn't seem to turn on automatically on the RX 6800 (that PR was tested on an RX 6700 XT). I'm now testing with
RX_VK_TASK_MESH_FALLBACK=1in hookshot_env.txt and will report back.Log excerpt (start-up + the lines before the crash):
hookshot_log_goron_city_crash_excerpt.txt
Update: with
RX_VK_TASK_MESH_FALLBACK=1set, start-up had to prepare all the shaders again: over an hour to reach 36% on the RX 6800 (the native-path preparation on v2.1.0 was much quicker). Will report once it finishes and I've played through Goron City again.More reports of this, collected here:
v2.1.0, RX 6800,
RX_VK_TASK_MESH_FALLBACK=1: Goron City now OK, but shader preparation took ~4–5 hoursFollow-up to my Goron City report above. With the task+mesh fallback forced on in hookshot_env.txt:
So the fallback looks like it fixes the crash on the RX 6800, but if it becomes the automatic choice for Navi 21 (the RX 6900 XT commits above), other RDNA2 users will likely hit the same multi-hour first start.
More reports of this, collected here:
I am having freezing followed by black screen, then crash issues. This happened at different spots, sometimes right after loading a game save, cutscenes, walking around, or entering a new area in a dungeon, to include right after the initial cutscene, first entering Mt. Doom, Kakariko Village just walking around after spending 10 minutes there, and others. Also had issues with pipeline installation. I used AI to help troubleshoot and test because I am NOT a programmer. Here are my testing results. Also, I am willing to run more A/B tests on request.
hookshot-996-comment.md
hookshot_log.txt
Mesh shaders setting test: I changed only Mesh shaders to Compute in the Graphics settings. The game ran until I completed the torch puzzle in Dodongo’s Cavern. Then a large Dodongo monument started rotating, and the game crashed.
I’m attaching the log from this run. It identifies Hookshot v2.1.0 and an AMD Radeon RX 6600 with Vulkan 1.4, driver ID 0x800161. The log confirms that the Compute mesh-shader path was active. Near the end, it reports VRAM: 6943 MB used of 6943 MB allowed. The last entries before the crash were:
text
vk: pool 0x7f9fa9b400+0x1644 imported in 106.9 ms as 0x7f9d000000..0x7fa6000000 (71 imports, 1564 ms in all)
vk: pool 0x7f9d000000..0x7fa6000000: mirror made with the GPU's contents of 1 retired pool(s)
CRASH: exception 0x20474343 (read 0, guest 0xfffff00000000000) at KERNELBASE.dll+0xc569a
CRASH: host backtrace: KERNELBASE.dll+0xc569a hookshot_vk.dll+0x3f951d hookshot_vk.dll+0x3f79fa hookshot_vk.dll+0x3f750e hookshot_vk.dll+0x272f02 hookshot_vk.dll+0x339778 hookshot_vk.dll+0x2d79a3 hookshot_vk.dll+0x2dd8ef hookshot_vk.dll+0x2d5828 hookshot_vk.dll+0x2d4726 hookshot_vk.dll+0x2d4155 hookshot_vk.dll+0x2d2728 hookshot_vk.dll+0x2ce270
I did not find an explicit VK_ERROR_DEVICE_LOST in this log. Changing Mesh shaders to Compute let me get farther, but the game still crashed when the monument started rotating.
Thought I would share my experience
AMD 9070XT / Windows 11
Initial run failed after intro cutscene, adding
HOS_NO_RENDERER_WAIT=1to environment did not fix, however, after inspecting the crash, I saw a failure in amdvlk64.dll which was subsequently fixed by usingRX_VK_NO_MESH=1.The game was playable for me after this, however, invisible doors and missing foliage/scenery.
github-sync referenced this issue2026-11-12 06:22:54 +00:00
RX 6600 (Windows 11, driver 26.10.x / 0x800161), v2.1.0 — what the hang is, and a way to use the compute path without re-preparing the cache
I could reproduce the device lost on a save within 2k–13k frames (three times), with
RX_VK_CHECKPOINTS=1and a small local patch that records each marked draw's arguments. What I found:55f9da6996166520,6f9142def3b6a978), right after the dispatch942cd7b4eb041596. Not an indirect draw, no garbage count.RX_VK_FAULT_INFO=1reports "No fault detected", so it is not a bad pointer / page fault.So on this card it looks like the driver itself hanging in native task + mesh draws, the same as the Navi 22 case, not a time-out from too much work.
What works here:
RX_VK_TASK_MESH_FALLBACK=1. Same save: ~69k frames so far with no device lost (one session only, so not proven yet). Some texture/geometry errors, VRAM is tight on 8 GB (6.5 of 6.85 GB at the worst).Avoiding the 4–5 hour preparation: the fallback bit is part of the cache stamp, so turning it on starts the whole program cache again. Locally I changed
vk_shader.cppso that:disk_stamp()no longer includesdev.task_mesh_fallback;program_cache_read()refuses a native record that has a task stage when the compute path is on (and a fallback record when it is off).The 6.6 GB cache is kept, and only the task + mesh programs are translated again, on demand in play (their draws are left out until the compute pipelines are ready). Start-up is immediate.
Maybe worth considering RX 6600 (device 0x73ff) for the automatic list, and keeping the cache across the mesh mode switch.
GPU: RX 6900 XT
driver: 26.10.1
OS: win 11
hookshot version: 2.1.0
where it happens: when going towards and near the door on the house in hylia lake, this happens consistently across runs
hookshot_log.txt
Blackscreen into crash, GPU reset (KDE plasmashell, steam, etc. crash & visual bugs)
GPU: RX 6600
OS: Linux (Bazzite)
hookshot version: 2.1.0
where it happens: after the intro cutscene title card cuts into black
hookshot_log.txt
Tracker upkeep note (merged pull requests and code checked against main
51da0464; no new test run was made for it).The tracker can distinguish the merged Windows Navi21/22 task-and-mesh fallback policy (#1747, #1992 and #2215) from the compiler-fault quarantine in #1823. Both are present on main
51da0464, but they address different failure modes. Linux AMD's Automatic mode now chooses full Compute through #2362; that does not change the Windows policy. Recent RX6600 and RX6950XT reports also fail with Compute, so this is not a whole-tracker fix. Please retain those reports and request their missing crash/driver evidence rather than closing the aggregate or treating every failure as the original native-mesh hang.Exactly the same
CachyOS
KDE Plasma 6.8.2
Linux 7.3.3-1-cachyos
AMD Ryzen 5 5600
AMD Radeon RX 6900 XT
mesa-git 27.0.0_devel.232438.f7dd61f78f8-1
Hookshot 2.1.0
Follow-up, RX 6600 (device 0x73ff), Windows 11, v2.1.0: the compute path for task + mesh fixes the hang here
My earlier comment said "one session only, so not proven yet". It held up since then:
RX_VK_TASK_MESH_FALLBACK=1: several sessions on the same save, the longest ~105k frames, through the Deku Tree and Gohma, no device lost.VK_ERROR_DEVICE_LOSTafter ~30.5k frames, with a 3.8 s GPU sync wait right beforesubmit ... failed (-4). Same signature as before.So on this card the native task + mesh draws are the cause, the same as the Navi 22 case. I can't speak for the RX 6600 reports that still fail with Compute (those look like a different failure; mine has VRAM at the allowance but no loss).
Two requests:
0x73ff) to the cards that get the task + mesh compute path automatically on Windows.gpu/vk/vk_shader.cpp; only the task + mesh programs get translated again, on demand in play:Start-up is immediate with the existing 6.6 GB cache; the cost is some stutter in the first minutes while those programs are rebuilt. Happy to test a build or send logs.
My issue was moved here, but this is a AMD specific report. I had mentioned in the original issue report that I was using a Nvidia 1080TI, and thought that it was likely related to the lack of mesh shader support....
I experience the same device lost error within Hookshot's logs, despite having RX_VK_NO_MESH=1 set within a launch batch file.
Previously, I also experienced a Memory Management BSOD at the time of the crash, but that BSOD hasn't happened again in the latter versions. However the crash to desktop at the rendering stage still plagues me.
To corroborate with someone's else report here... hookshot_env.txt with the appropriate params written didn't change the crash outcome either.
I don't know if the property is just getting ignored, but it doesn't seem to work here... It just crashes prior to rendering anything at the end of loading a save or when starting a new game. The game used to work prior to the 2.06 update (obviously without foliage and other), but hasn't worked since updating. I'm on v2.1.0 currently.
hookshot_env.txt (with RX_VK_NO_MESH=1) placed within the root folder (not in any subdirectories) containing bin, prompts, romfs and user folder... (not working)
Batch file with: (also not working)
@echo off
set RX_VK_NO_MESH=1
start "" "Hookshot.exe"
In the meantime, how on earth do you downgrade Hookshot aha? The previous launcher versions (when manually downloaded) always downloads the latest - when starting from fresh... I was only trying to test the new fallback path, but I haven't seen it working yet. Curiously, the fallback path or implementation used by Lichii (the emulator) for rendering foliage works great.
hookshot_log.1.txt
hookshot_log.2.txt
hookshot_log.txt
System:
Intel i7-8700k CPU @ 5GHz
Patriot Viper Steel 32GB Ram
MSI Gaming X 1080Ti 11GB
Gigabyte Z390 AORUS PRO
Corsair RM750x PSU
Hookshot 2.1.0 – Persistent Hyrule Castle Town Freezes and Graphical Issues with Compute Mesh Shaders
System Specifications
Graphics Settings
Additional Testing – Compute Mesh Shaders
Following the suggestion to investigate the Mesh Shaders setting, I changed it from Automatic to Compute.
After changing this setting, Hookshot had to rebuild its shaders and pipelines. This process took approximately three hours to complete.
Hyrule Castle Town
The first attempt to enter Hyrule Castle Town still resulted in a crash.
After restarting the game, I managed to enter the area successfully. However, the game eventually froze again while I was inside Castle Town.
Therefore, switching to Compute did not resolve the freezing issue.
New Graphical Issues – Hyrule Field
After switching to Compute, I also noticed new graphical issues in Hyrule Field.
Several surfaces now have incorrect lighting or texture appearance, including:
These graphical issues were not present when using the Automatic Mesh Shaders setting.
I cannot confirm whether they are directly caused by the Compute setting, but they appeared after switching modes.
Frame Generation
The Castle Town freeze also occurs with Frame Generation disabled. This suggests that the issue is not directly related to Frame Generation.
Summary
Switching Mesh Shaders from Automatic to Compute did not fix the recurring freeze in Hyrule Castle Town.
Although the area loaded successfully on the second attempt, the game eventually froze again. Additionally, new graphical issues appeared in Hyrule Field, which I had not experienced with Automatic.
I am currently considering returning to Automatic, as Compute has not provided a clear stability improvement and introduced additional visual issues.
I hope these findings help narrow down the issue. Thanks for your continued work on Hookshot!
hookshot_log.txt
Documentation suggestion — VRAM presets
The Graphics menu already provides Low (6GB) and Balanced (8GB) quality presets. My RX 6600 has 8 GB of VRAM, but Hookshot’s log reported 6,878/6,878 MB available/used before the crash and later showed an “out of memory” warning.
Could the documentation explain when users with 8 GB cards should choose Low (6GB) instead of Balanced (8GB), especially when the game reports less usable VRAM than the card’s advertised capacity? It might also help to show an in-game warning or recommend the Low preset when VRAM usage approaches the available budget.
I have not yet confirmed whether switching to the Low preset prevents the crash; I’m suggesting this based on the memory figures in my log.
Thanks for the link. I checked issue #2507. Since my GPU is an AMD Radeon RX 6600 and the crash is a VK_ERROR_DEVICE_LOST on Windows, I’ll post my test results and updated logs in issue #996, which tracks AMD driver crashes and device-lost reports. I’ll avoid opening a duplicate report.
Another one for the collection, RX 6600 + driver 0x800161, Windows 11 build 26200, Hookshot v2.1.0 (source 633eb435).
Second session of the day, died at present 21261 while entering a heavy scene (1173 draws, 170 dispatches, fps dropping 57 → 42 → 32). Death sequence:
Just before it, the driver's shader compiler was hanging on compute pipelines:
SLOW compile, 45240 ms,41411 ms,33941 ms,32512 ms(the last one at the moment of death) — 54 slow compiles totalling ~357 s in that session. VRAM was at the allowance cap (6720 MB used of 6720 MB allowed) but not squeezed (room in the blocks).hookshot_log.txtattached.Notable: the same machine also crashes NX2navi 0.8.0/0.9.1 with the same
device lostsignature — 6/6 sessions across driver packages 26.10.1, 26.10.2 and a factory-reset rollback to 26.9.1,device fault: "No fault detected", no TDR — tangerineturtle1/NX2navi#602.New data point for the 0x800161 cluster: I tested all three Adrenalin packages (26.10.1 → 26.10.2 → 26.9.1 with factory reset) and the crash survives all of them, because all three ship the byte-identical Vulkan driver:
vk capsreportsversion 2.0.353, raw 0x800161on every package, and amdvlk64.dll is 9.2.10.353 / 102722576 bytes (SHA-2565C1581FB…, 27/08/2026) in all three — only the package label string differs. That likely explains why this cluster spans 26.9.x–26.10.x releases: rolling back doesn't actually change the Vulkan layer. Unless AMD ships a new amdvlk build, driver-version hopping can't fix it.Attached: hookshot-crash-2026-11-11-215830.log