MCD2: intermittent exit AV with ReShade 6.8.0 + Blueprint Loader 2.6

I found an intermittent shutdown access violation in Minecraft Dungeons II while qualifying a graphics mod. The same fault family also reproduced with our mod completely removed, leaving only official ReShade and Blueprint Loader. I am reporting an unresolved compatibility finding, not attributing the cause to either component.

Environment:
- Steam build 25910487; Windows 11 build 26200.
- AMD Radeon 860M; driver 32.0.32015.7029; 1920x1200 SDR.
- Blueprint Loader 2.6, Nexus main file 506.
- Official ReShade 6.8.0 full add-on build, file version 6.8.0.2155.
- ReShade64.dll SHA-256: 0cee63f9c9f13f3ac909c5b4903f4dbb4b719a7ab3b4f13b0deaf83c814b94f7.
- Game executable SHA-256: 3842102bb05fc532b22e97992d61c2248d115be80ff752ff9b6843bf4acd7005.

I downloaded ReShade_Setup_6.8.0_Addon.exe from reshade.me on 23 October and inspected its appended archive without running the setup. Its ReShade64.dll matches the failing reduced-control proxy exactly. Setup SHA-256: afe4c8f13048306307983b8b3d41d5bf00a86820440b0e57dea10950e1176445.

Reproduction attempted:
1. Keep Steam running and launch normally with ReShade and Loader installed.
2. Enter the hub and remain observed for at least 90 seconds.
3. Close normally using Alt+F4.
4. Inspect the held process exit status and Windows Error Reporting.

Expected: shutdown completes without an access violation.
Observed: one of two ordinary runs returned 0xC0000005 with a WER minidump; the other returned 0. No debugger or Application Verifier was attached. A read-only Windows display report completed before the failing close.

Small ordinary control matrix, using the same game/hub/close route:
- Clean game, system DXGI, no Loader: 0, 0.
- Official ReShade plus Loader 2.6: 0, C0000005.
- Loader only, system DXGI: 0, 0.
- Official ReShade only, no Loader: 0, 0.

File hashes and loaded-module checks confirmed the layouts. Our graphics UI, native addons, modified framework, FSR/Streamline and RenoDX were absent from the failing reduced control. These two-run samples do not establish failure rates, prove an interaction defect, or exonerate any component. No ordinary base-game-only crash is claimed.

Offline analysis places the fault in the game-worker/CRT-exit wait family also seen with the full candidate. A separate instrumented full-candidate capture establishes a freed-block read during shutdown, but does not establish the owning source component or complete worker-stop order. It is excluded from the ordinary counts above. A later ordinary full-candidate failure targets null in the same unwind/caller family; an identical allocation cause is not claimed. The previously corrected descriptor-heap corruption is a separate issue and is not presented as this crash's repair.

Sanitized ordinary matrix:
github.com/SpinGiantCRM/mcd2-graphics/bl...rols-2026-10-23.json

Separate diagnostic summary:
github.com/SpinGiantCRM/mcd2-graphics/bl...exit-2026-10-23.json

Additional bounded integration comparisons and limitations:
github.com/SpinGiantCRM/mcd2-graphics/bl...tion-2026-10-23.json

Related Blueprint Loader report: issue 1156615 on www.nexusmods.com/minecraftdungeons2/mods/2?tab=bugs

Raw dumps and proprietary disassembly remain private. No save corruption, device reset or system crash has been demonstrated. Is there a known Loader/ReShade shutdown interaction, or a supported source-level boundary that would help identify the worker owner and shutdown ordering?