Developers that are using Macs are fine and there are no loading issues or crashes. However, most people on Windows are experiencing a lot of issues (although not all people on windows are experiencing issues). On windows, studio often crashes randomly, and starting a playtest takes a very long time to load. It either doesn’t load at all, loads but everything is erroring because it took so long, or Studio crashes entirely.
Expected behavior
Studio hopefully shouldn’t crash randomly and starting playtests in studio should be fine
We investigated your crash dump very deeply, thank you for reporting it. This appears to be a NVIDIA driver issue, your driver version (591.86) is the single most affected version, accounting for ~300 crashes across our player base in the past two weeks. Updating to driver 610+ reduces the likelihood by about 6x.
Root cause: Your Studio freeze is a lock convoy triggered by NVIDIA’s shader cache driver (NvMemMapStoragex.dll) stalling on a memory-mapped file I/O operation.
Studio’s RenderJob acquires the DataModel Arbiter lock (a global write lock used to synchronize the render thread with the scene graph)
During rendering, D3D11 issues a GPU resource operation that enters NvMemMapStoragex.dll — NVIDIA’s on-disk shader cache backed by memory-mapped files
The memory-mapped read/write stalls indefinitely (in your case, likely STATUS_DEVICE_DATA_ERROR — a failed page-in from the shader cache file on disk)
Because the render thread holds the Arbiter lock while stalled in the driver, every other thread that needs the Arbiter queues up behind it (28 threads in your dump, all blocked on NtWaitForAlertByThreadId)
The UI thread calls RenderJob::waitForLock() which is an unconditional infinite wait (CEvent::Wait() with no timeout) — it will never return because the render thread never signals it
The HangMonitor detects the UI thread is unresponsive after a timeout and fires a simulated exception (0x0517A7ED) to generate this dump
Why your driver version: You’re on NVIDIA 591.86, which has a 5.2x higher rate of NvMemMapStoragex failures compared to the 610.xx branch. NVIDIA appears to have improved error recovery in 610+ (graceful shader recompile fallback instead of stalling on a failed page-in).
Why the engine can’t recover: waitForLock() has no timeout — once the UI thread commits to waiting, there’s no bailout path. The device-lost recovery code (checkDeviceRemoved) can’t help because it requires the GPU call to return — a stall means it never returns.
tl;dr update your drivers (I know this is sad, but that’s all we’ve got right now!) Your disk may also be close to full, in which case that would cause an increased instability.