MagicBeanDev/Hookshot

Archived

Watch

Fork 0

Three Windows BSODs (0x154 / 0x139 / 0x3B) after VRAM goes over the driver's allowance, each 31-53 s after the log stops #2749

Open

opened 2026-11-12 11:35:41 +00:00 by github-sync · 1 comment

github-sync commented

2026-11-12 11:35:41 +00:00

Owner

@xyh67 opened on GitHub · 2026-11-12 10:49 UTC · original

Hookshot version

v2.1.0 (source e099bbca)

What kind of problem

Crash, freeze or black screen

What happened

Three Windows BSODs over ~26 hours of play, each within 31–53 seconds of a log stop, and each preceded by VRAM going over the driver's allowance. Related to #993 (VRAM/RAM fill up over play time) and #1861 (the same 0x3B + 0xC0000005 on an AMD card).

I am reporting this because the BSODs are a different symptom from the texture corruption in #993, and because each one has a minidump I could decode plus the exact VRAM state from hookshot_log at the moment of the crash.

System

OS: Windows 11 25H2, build 26200.9974
CPU: AMD Ryzen 9 9950X3D (16C/32T)
GPU: NVIDIA GeForce RTX 5080 16 GB, driver 621.14 (32.0.16.2114, 2026-10-27)
RAM: 48 GB DDR5-6000 (2 × 24 GB, EXPO on, 1.1 V)
Pagefile: 18 GB, system managed, on an NVMe SSD
Motherboard: MSI B850MPOWER, BIOS 1.A33 (2026-06-25)
No overclock: MSI Afterburner is installed but its [Startup] profile section is empty, so nothing is applied at boot. Measured GPU clock stays at the card's stock boost behaviour.

Settings

quality_preset=0
frame_generation=0
frame_pacing=0
nvidia_reflex=1
output_res=2560x1440
dlss=2
dlss_model=0
resolution=9
upscaling=2
sharpness=80
anisotropic_filtering=4

The three crashes

#	Bug check	Time	Log last written	Gap
1	`0x154` UNEXPECTED_STORE_EXCEPTION	15:53:32	15:52:54	38 s
2	`0x139` KERNEL_SECURITY_CHECK_FAILURE	16:59:47	16:59:04	43 s
3	`0x3B` SYSTEM_SERVICE_EXCEPTION	18:11:55	18:11:24	31 s

Crashes 2 and 3 are 1 h 12 min apart.

What the dumps show

I decoded the minidumps by hand (no WinDbg/symbols available at the time), so the parameters below are read straight out of the PAGEDU64 triage structure.

0x139 (crash 2)

BugCheck 0x139  P1=0x3  P2=0xFFFF9109994BF740  P3=0xFFFF9109994BF698  P4=0x0

P1 = 3 is FAST_FAIL_CORRUPT_LIST_ENTRY.
At file offset 0x010228 there is a __fastfail record: ExceptionCode = 0xC0000409, ExceptionAddress = nt!+0x8FBD31 (inside ntoskrnl's paged PAGE section), Param[0] = 0x3.
P2 and P3 are 0xA8 bytes apart, and the stack holds further pool addresses from 0xFFFF9109994BF800 to 0xFFFF9109994BF9C0 — an 808-byte span of one pool block was overwritten.
All 32 resolvable frames in the crash stack are inside ntoskrnl.exe. No third-party driver appears on it.

0x3B (crash 3)

BugCheck 0x3B  P1=0xC0000005  P2=0xFFFFF805EFE51740  P3=0xFFFFF18F6CD1EFE0  P4=0x0

The real EXCEPTION_RECORD sits at file offset 0x110E8, inside the captured stack: ExceptionCode = 0xC0000005, Param[0] = 0 (read), Param[1] = 0x510.
So the kernel read address 0x510 — a null base plus a +0x510 field offset.
Also all ntoskrnl on the stack; no GPU driver frames.

0x154 (crash 1) was a store-manager exception while handling compressed pages, again entirely inside ntoskrnl.

No WHEA records exist for any of the three. Memory diagnostics have never been run on this machine, so I am not claiming Hookshot is the sole cause — but the timing and the VRAM state below are consistent enough to be worth a look.

The part I think matters: VRAM over the allowance, then a frame-rate cliff, then the BSOD

Crash 3 (0x3B) is the clearest. About 40 seconds before the bugcheck, the frame rate collapses from a locked 60 to the high 20s and never recovers:

present 244440 -> 60.2 fps
present 244560 -> 60.0 fps     <- last normal
present 244680 -> 36.8 fps     <- first drop
present 245040 -> 41.8 fps
present 245160 -> 31.3 fps
present 245280 -> 29.0 fps     <- lowest
present 245400 -> 33.6 fps
present 245520 -> 50.0 fps
present 245640 -> 47.8 fps     <- last line written before the bugcheck

GPU time over the same window goes from 11.1 ms a frame to 19.1 ms a frame (longest submission 59.5 ms).

The last VRAM line before that crash:

vk: VRAM: 14620 MB used of 14421 MB allowed (4440 MB of it free in the blocks);
    textures 5284 MB (budget 6144 MB), 3081 textures
    (at the driver's limit, room in the blocks: not squeezed)

used is 199 MB above allowed, and the texture count has hit the driver's limit. The line just before it was already over budget:

vk: VRAM: 13680 MB used of 14465 MB allowed (...); textures 5404 MB (budget 6144 MB), 3545 textures

Crash 2 (0x139) shows the same pattern. Its last over-allowance line, shortly before the log stops:

vk: VRAM: 13958 MB used of 14302 MB allowed (5119 MB of it free in the blocks);
    textures 3998 MB (budget 6144 MB), 2065 textures (at the driver's limit, ...)

So in both crashes: VRAM over the driver's allowance with thousands of MB still free inside the blocks → WDDM starts paging to system memory → system commit climbs → the kernel faults.

Commit at the time was 53–56 GB against a 63.8 GB limit (≈ 88%). The Hookshot process itself held 32–34 GB of commit with an 18.7 GB working set, and an 18 GB pagefile.

Why I am reporting this rather than just tuning my settings

Both crashes happened while VRAM was over the driver's allowance with a large "free inside the blocks" figure — the same signature as the at the driver's limit reports in #993, but here it ends in a bugcheck rather than corrupt textures.
The 0x3B one has no GPU driver on the stack, so it is not a VK_ERROR_DEVICE_LOST / TDR path (that is #996). It is the kernel's own memory failing after the VRAM pressure started.
#1861 was closed into #996, but #996 is about DEVICE_LOST and driver timeouts and does not cover bugchecks, so the BSOD reports do not currently have a tracker.

Workarounds I am trying

RX_VK_COMPACT=1 in hookshot_env.txt, from the 12 GB Windows report in #993.
Enlarged the pagefile, since the commit limit (63.8 GB) was being approached.
Lower render resolution, to keep used under allowed.

I will report back whether the BSODs stop.

Question

Is a kernel bugcheck inside the scope you want to track, or should this be folded into #993? I have the three minidumps and the full logs and can attach whatever is useful (I have not uploaded them yet, and I have removed every path, account name and identifier from the excerpts above).

Where in the game

Hyrule Field and Kokiri Forest — normal play, no particular transition.

How often

Three times in about 26 hours of play, at 25 h, then 1 h 12 min apart. When it happens it is always after VRAM has been over the driver's allowance for a while.

Graphics card and driver version

NVIDIA GeForce RTX 5080 16 GB, driver 621.14

CPU, RAM and operating system

AMD Ryzen 9 9950X3D, 48 GB DDR5-6000, Windows 11 25H2 (26200.9974)

Changes from the defaults

hookshot_env.txt: HOOKSHOT_NO_UPDATE_CHECK=1, and now RX_VK_COMPACT=1
2560x1440 output, DLSS, resolution 9, upscaling 2 — the rest is at defaults

Other software hooked into the game

No overlay or injector attached to the game. Present on the system but not hooked into it: MSI Afterburner and RTSS (installed, idle), a vendor input-device utility, and a vendor virtual-display driver that fails to load at every boot (Kernel-PnP 219, status 0xC0000365).

hookshot_log.txt

I will attach the three session logs (about 14–34 MB each) if you want them — tell me and I will upload. The excerpts above are the only lines I pulled out, and I have stripped paths and identifiers from them.

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.

> [@xyh67](https://github.com/xyh67) opened on GitHub · 2026-11-12 10:49 UTC · [original](https://github.com/NotRexed/Hookshot/issues/2749) ### Hookshot version v2.1.0 (source e099bbca) ### What kind of problem Crash, freeze or black screen ### What happened **Three Windows BSODs over ~26 hours of play, each within 31–53 seconds of a log stop, and each preceded by VRAM going over the driver's allowance.** Related to #993 (VRAM/RAM fill up over play time) and #1861 (the same `0x3B` + `0xC0000005` on an AMD card). I am reporting this because the BSODs are a different symptom from the texture corruption in #993, and because each one has a minidump I could decode plus the exact VRAM state from `hookshot_log` at the moment of the crash. ### System * **OS:** Windows 11 25H2, build 26200.9974 * **CPU:** AMD Ryzen 9 9950X3D (16C/32T) * **GPU:** NVIDIA GeForce RTX 5080 16 GB, driver 621.14 (`32.0.16.2114`, 2026-10-27) * **RAM:** 48 GB DDR5-6000 (2 × 24 GB, EXPO on, 1.1 V) * **Pagefile:** 18 GB, system managed, on an NVMe SSD * **Motherboard:** MSI B850MPOWER, BIOS 1.A33 (2026-06-25) * **No overclock:** MSI Afterburner is installed but its `[Startup]` profile section is empty, so nothing is applied at boot. Measured GPU clock stays at the card's stock boost behaviour. ### Settings ``` quality_preset=0 frame_generation=0 frame_pacing=0 nvidia_reflex=1 output_res=2560x1440 dlss=2 dlss_model=0 resolution=9 upscaling=2 sharpness=80 anisotropic_filtering=4 ``` ### The three crashes | # | Bug check | Time | Log last written | Gap | |---|---|---|---|---| | 1 | `0x154` UNEXPECTED_STORE_EXCEPTION | 15:53:32 | 15:52:54 | 38 s | | 2 | `0x139` KERNEL_SECURITY_CHECK_FAILURE | 16:59:47 | 16:59:04 | 43 s | | 3 | `0x3B` SYSTEM_SERVICE_EXCEPTION | 18:11:55 | 18:11:24 | 31 s | Crashes 2 and 3 are 1 h 12 min apart. ### What the dumps show I decoded the minidumps by hand (no WinDbg/symbols available at the time), so the parameters below are read straight out of the `PAGEDU64` triage structure. **0x139 (crash 2)** ``` BugCheck 0x139 P1=0x3 P2=0xFFFF9109994BF740 P3=0xFFFF9109994BF698 P4=0x0 ``` * `P1 = 3` is `FAST_FAIL_CORRUPT_LIST_ENTRY`. * At file offset `0x010228` there is a `__fastfail` record: `ExceptionCode = 0xC0000409`, `ExceptionAddress = nt!+0x8FBD31` (inside ntoskrnl's paged `PAGE` section), `Param[0] = 0x3`. * `P2` and `P3` are 0xA8 bytes apart, and the stack holds further pool addresses from `0xFFFF9109994BF800` to `0xFFFF9109994BF9C0` — an **808-byte span of one pool block was overwritten**. * All 32 resolvable frames in the crash stack are inside `ntoskrnl.exe`. No third-party driver appears on it. **0x3B (crash 3)** ``` BugCheck 0x3B P1=0xC0000005 P2=0xFFFFF805EFE51740 P3=0xFFFFF18F6CD1EFE0 P4=0x0 ``` * The real `EXCEPTION_RECORD` sits at file offset `0x110E8`, inside the captured stack: `ExceptionCode = 0xC0000005`, `Param[0] = 0` (read), `Param[1] = 0x510`. * So the kernel read address `0x510` — a null base plus a `+0x510` field offset. * Also all ntoskrnl on the stack; no GPU driver frames. **0x154 (crash 1)** was a store-manager exception while handling compressed pages, again entirely inside ntoskrnl. No WHEA records exist for any of the three. Memory diagnostics have never been run on this machine, so I am not claiming Hookshot is the sole cause — but the timing and the VRAM state below are consistent enough to be worth a look. ### The part I think matters: VRAM over the allowance, then a frame-rate cliff, then the BSOD Crash 3 (`0x3B`) is the clearest. About 40 seconds before the bugcheck, the frame rate collapses from a locked 60 to the high 20s and never recovers: ``` present 244440 -> 60.2 fps present 244560 -> 60.0 fps <- last normal present 244680 -> 36.8 fps <- first drop present 245040 -> 41.8 fps present 245160 -> 31.3 fps present 245280 -> 29.0 fps <- lowest present 245400 -> 33.6 fps present 245520 -> 50.0 fps present 245640 -> 47.8 fps <- last line written before the bugcheck ``` GPU time over the same window goes from `11.1 ms a frame` to `19.1 ms a frame` (longest submission 59.5 ms). The last VRAM line before that crash: ``` vk: VRAM: 14620 MB used of 14421 MB allowed (4440 MB of it free in the blocks); textures 5284 MB (budget 6144 MB), 3081 textures (at the driver's limit, room in the blocks: not squeezed) ``` **`used` is 199 MB above `allowed`**, and the texture count has hit the driver's limit. The line just before it was already over budget: ``` vk: VRAM: 13680 MB used of 14465 MB allowed (...); textures 5404 MB (budget 6144 MB), 3545 textures ``` Crash 2 (`0x139`) shows the same pattern. Its last over-allowance line, shortly before the log stops: ``` vk: VRAM: 13958 MB used of 14302 MB allowed (5119 MB of it free in the blocks); textures 3998 MB (budget 6144 MB), 2065 textures (at the driver's limit, ...) ``` So in both crashes: **VRAM over the driver's allowance with thousands of MB still free inside the blocks → WDDM starts paging to system memory → system commit climbs → the kernel faults.** Commit at the time was 53–56 GB against a 63.8 GB limit (≈ 88%). The Hookshot process itself held 32–34 GB of commit with an 18.7 GB working set, and an 18 GB pagefile. ### Why I am reporting this rather than just tuning my settings * Both crashes happened while VRAM was over the driver's allowance with a large "free inside the blocks" figure — the same signature as the `at the driver's limit` reports in #993, but here it ends in a bugcheck rather than corrupt textures. * The `0x3B` one has no GPU driver on the stack, so it is not a `VK_ERROR_DEVICE_LOST` / TDR path (that is #996). It is the kernel's own memory failing after the VRAM pressure started. * #1861 was closed into #996, but #996 is about `DEVICE_LOST` and driver timeouts and does not cover bugchecks, so the BSOD reports do not currently have a tracker. ### Workarounds I am trying * `RX_VK_COMPACT=1` in `hookshot_env.txt`, from the 12 GB Windows report in #993. * Enlarged the pagefile, since the commit limit (63.8 GB) was being approached. * Lower render resolution, to keep `used` under `allowed`. I will report back whether the BSODs stop. ### Question Is a kernel bugcheck inside the scope you want to track, or should this be folded into #993? I have the three minidumps and the full logs and can attach whatever is useful (I have not uploaded them yet, and I have removed every path, account name and identifier from the excerpts above). ### Where in the game Hyrule Field and Kokiri Forest — normal play, no particular transition. ### How often Three times in about 26 hours of play, at 25 h, then 1 h 12 min apart. When it happens it is always after VRAM has been over the driver's allowance for a while. ### Graphics card and driver version NVIDIA GeForce RTX 5080 16 GB, driver 621.14 ### CPU, RAM and operating system AMD Ryzen 9 9950X3D, 48 GB DDR5-6000, Windows 11 25H2 (26200.9974) ### Changes from the defaults * `hookshot_env.txt`: `HOOKSHOT_NO_UPDATE_CHECK=1`, and now `RX_VK_COMPACT=1` * 2560x1440 output, DLSS, resolution 9, upscaling 2 — the rest is at defaults ### Other software hooked into the game No overlay or injector attached to the game. Present on the system but not hooked into it: MSI Afterburner and RTSS (installed, idle), a vendor input-device utility, and a vendor virtual-display driver that fails to load at every boot (`Kernel-PnP 219`, status `0xC0000365`). ### hookshot_log.txt I will attach the three session logs (about 14–34 MB each) if you want them — tell me and I will upload. The excerpts above are the only lines I pulled out, and I have stripped paths and identifiers from them. ### 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.

github-sync commented

2026-11-12 14:45:18 +00:00

Author

Owner

@mooki000 commented on GitHub · 2026-11-12 14:12 UTC · original

Thanks for keeping the crash times and memory figures. One small distinction: the quoted 0x139 sample is 13,958 MB used of 14,302 MB allowed, so it is below the allowance; the 0x3B sample is above it. Could you attach the full Hookshot log for the 0x3B session? That would help check the pressure timeline without assuming it caused the Windows bugcheck. No minidump is needed here.

> [@mooki000](https://github.com/mooki000) commented on GitHub · 2026-11-12 14:12 UTC · [original](https://github.com/NotRexed/Hookshot/issues/2749#issuecomment-6825956692) Thanks for keeping the crash times and memory figures. One small distinction: the quoted 0x139 sample is 13,958 MB used of 14,302 MB allowed, so it is below the allowance; the 0x3B sample is above it. Could you attach the full Hookshot log for the 0x3B session? That would help check the pressure timeline without assuming it caused the Windows bugcheck. No minidump is needed here.

Commenting is not possible because the repository is archived.