Hi, I’m experiencing an error when loading in the game to download new mods (application: Curse Forge) - it’s throwing an error saying I don’t have memory even though I have 170 GB and I don’t know what to do
How many active mods do you have? What are the specifications of your RAM and graphics card?
Isn’t this problem similar?
Yes, it’s similar, I think.
To the team: Can you please merge those two threads + keep the main thread from closing, as the issue seems to continue? Thank you in advance 
Hello Damianina,
I’ve merged your post into this thread since it relates to the same issue. Thanks 
.
I’m also still having this issue
@wuvmoo - could you please remove the solution, because apparently numerous other players are still experiencing the issue, so it’d be best to keep this thread open for now 
Yeah the memory goes up really high for me. Im able to get in after resetting both mods folder but it crashes because of how much memory the new curseforge is using. I never had this issue with the old version of curseforge.
So far there were about 200 active mods because that’s all I managed to download @Mazikeen and after the update it’s garbage 
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:
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.
https://drive.google.com/file/d/1xTOmH2kAuBPsKO2483ManocNymyuC3HM/view?usp=sharingDetails:
Dates/times of the 4 crashes: 2026-07-02 13:32, 2026-07-02 15:17, 2026-07-0222: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.PoolSizewas 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=6144andr.Streaming.UseFixedPoolSize=1via Engine.ini (confirmed applied — CVars dump shows the new values sourced fromSystemSettingsIni), 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.jsoncan retain far more entries thanlocal_user_info.json/ actual installed files, especially post-migration. - A way to install Curseforge mods outside of Inzoi (like Canvas website)
Hi jadajpeg! Thanks for your report.
I’m going to merge your post with an existing thread since it’s related to the CurseForge issue. This helps keep all reports and updates about the same problem in one place, making it easier for the team to track and investigate.
Thank you! 
Thank you so much! It helps me too <3
(post deleted by author)