Mod UI (Curseforge) Not Opening Investigation

[jadajpeg]

• Game Version: 20260701.13568.W-298407 (Engine 5.6.1) [v0.9.3]

• Platform: Steam Windows

• Mods: Active

  Mod list: 700-786 mods installed depending on the session (exact count varies

  across the crashes below). The full list is too long to type out manually —

  attached are ModInfo.json (mod list from the affected save) and library.json /

  local_user_info.json (CurseForge library state at time of crash) which contain

  the complete list. Notably, the crash reproduces identically even with 0 active

  mods (all disabled), so this does not appear to be tied to which specific mods

  are active.

  Hardware Specifications & Operating System (OS version, CPU, GPU, RAM, storage…):

  • OS: Windows 11 25H2 (build 10.0.26200.8737)

  - CPU: AMD Ryzen 7 9850X3D 8-Core Processor

  - GPU: NVIDIA GeForce RTX 4070 Ti, 12GB VRAM, driver 610.62

  - RAM: 32GB system memory

  Steps to Reproduce:

  1. Have a CurseForge-managed mod library with roughly 770-790+ mods installed

     (active or inactive doesn’t seem to matter — reproduced with 0 active mods).

  2. Launch inZOI and reach Curseforge screen.

  3. Game hangs for several seconds (observed up to 16.6 seconds on one frame),

  then crashes with CrashType: GPUCrash (“GPU Crash dump Triggered”).

  This has now reproduced across 4 separate crashes on different sessions, with a

  consistent signature each time: VRAM usage spikes to ~17.5-18.75GB against a

  budget of only ~10-10.5GB, with ~15.8-15.9GB spilling into shared system memory.

  I also tried manually forcing the texture streaming pool from the default 800MB

  up to a fixed 6144MB (r.Streaming.PoolSize / r.Streaming.UseFixedPoolSize=1 via

  Engine.ini, confirmed applied in the crash’s own CVar dump) — this made no

  measurable difference to the crash, which suggests the Mod UI’s thumbnail

  loading may be bypassing the normal managed texture streaming system rather

  than the pool simply being undersized.

  Please provide the entire save file(s) from the date when the issue occurred.
  Attached Crash Files:
  https://drive.google.com/file/d/1xTOmH2kAuBPsKO2483ManocNymyuC3HM/view?usp=sharing

  Details:
  Please share the date, error message, or screenshots/videos for issue verification.
  Dates/times of the 4 crashes: 2026-07-02 13:32, 2026-07-02 15:17, 2026-07-02

  22:17, 2026-07-03 07:02 (all local time)

  Error message: CrashType: GPUCrash / ErrorMessage: “GPU Crash dump Triggered”

  D3D12 DRED diagnostic returned no breadcrumb/pagefault data each time, which is

  consistent with a driver TDR timeout (GPU stopped responding in time) rather

  than an actual memory access violation.

  Separately, one of the session logs showed 1,566 consecutive "Couldn’t find

  installed mod" errors at launch (from

  installed_mods_info_user_service_impl.cpp:303), which appears related to a

  prior library migration and may be inflating the “installed” mod count with

  stale/orphaned entries — flagging in case it’s relevant to reproducing this on

  your end

Key finding: this is NOT about active mod count

• Crash reproduced identically with 0 active mods (ActiveModCount: 0, ModEnabled: false), same VRAM signature as with 774 active mods.
• This strongly suggests the Mod UI enumerates/generates thumbnails for all installed mods, not just active ones, when the screen loads.

Key finding: increasing the texture streaming pool had no effect

• Default r.Streaming.PoolSize was 800MB (sourced from the Scalability system), while the engine’s own telemetry showed streaming demand of 14-15GB — already ~18x over the pool cap before any change was made.
• After forcing r.Streaming.PoolSize=6144 and r.Streaming.UseFixedPoolSize=1 via Engine.ini (confirmed applied — CVars dump shows the new values sourced from SystemSettingsIni), the crash reproduced with an almost identical signature (17.7GB VRAM used, 15.8GB shared spillover).
• This indicates the Mod UI’s thumbnail/preview loading is likely bypassing the managed texture streaming pool entirely (e.g., loading full-resolution images as unmanaged textures rather than through the mip-streamed system), which would explain why a 7.5x larger pool made no measurable difference.

Suspected root cause

The Mod UI appears to load full-size thumbnail/preview textures for every installed mod (not just active ones) synchronously/without a memory budget check when the screen opens. With a large enough library (~700-800+ mods), the combined VRAM demand for this exceeds both the GPU’s physical VRAM and the shared-memory fallback headroom, causing the frame time to spike into multi-second stalls (observed: 16.6 seconds in one capture) until Windows’ TDR mechanism kills the GPU device.

Additional context: library manifest desync (separate but related issue)

Separately, we found that library.json (shared CurseForge library cache) and local_user_info.json (per-account install record) can drift significantly out of sync — one crash session logged 1,566 consecutive “Couldn’t find installed mod” errors from installed_mods_info_user_service_impl.cpp:303 at launch, tied to a prior library migration (performedLibraryMigration: true). This may be inflating the effective “installed” count with orphaned/stale entries that no longer correspond to real files, which could be contributing to how quickly players hit the crash threshold described above.

What would help from the dev side

• Thumbnail loading in the Mod UI routed through the standard streaming/pool system (or explicitly paginated/lazy-loaded) rather than loading everything for every installed mod up front.
• Investigation into why library.json can retain far more entries than local_user_info.json / actual installed files, especially post-migration.
• A way to install Curseforge mods outside of Inzoi (like Canvas website)