D5 closed itself twice tonight while I was working, with no warning and no crash dialog. I dug into the logs and I think I have something useful for you, because the two crashes are byte-for-byte identical even though the models involved were completely different.
Setup: D5 Render 3.1.1.0755 (fusion d5_fusion-cn2-3.1.0.1195, launcher 3.1.0.1158), Rhino 8.34.26223.11001, D5 LiveSync for Rhino 1.1.3.0016. Windows 10 Pro 19045, i9-9900, 96 GB RAM, RTX 5070 Ti 16 GB.
Crashes: 2026-10-20 at 21:29:04 and 21:38:30 local time (UTC+2).
Both times the exception is exactly the same, down to the address:
Unhandled Exception: EXCEPTION_ACCESS_VIOLATION reading address 0x00000001e3000010
And both times the last thing D5 does is finish loading a Rhino model and then destroy the refresh task:
LogD5: [RhinoLoader::ProcessMaterialData:728] ...
LogD5: [RhinoLoader::ProcessLayerData:857] ...
LogD5: [RhinoLoader::ProcessMeshData:889] RhinoLoader::LoadMesh mesh section
LogD5: [RhinoLoader::ProcessMeshData:921] bounding box: IsValid=true, ...
LogD5: Request: d5.CMessageModelRefreshProcess ... percent: 1
LogD5: [CRefreshModelTask::~CRefreshModelTask:46] ~CRefreshModelTask()
LogD5: [CCommonTask::~CCommonTask:19] ~CCommonTask()
LogWindows: Error: === Critical error: ===
LogWindows: Error: Unhandled Exception: EXCEPTION_ACCESS_VIOLATION reading address 0x00000001e3000010
The crash lands 200-340 ms after ~CRefreshModelTask().
Call stack (identical in both crashes):
0x00007ffa566ec887 VCRUNTIME140.dll
0x00007ff67d33f7b9 d5_immerse.exe
0x00007ff67d342a0f d5_immerse.exe
0x00007ff678815395 d5_immerse.exe
0x00007ff678821e2e d5_immerse.exe
0x00007ff67882861d d5_immerse.exe
0x00007ff67b524c14 d5_immerse.exe
0x00007ff67b525a74 d5_immerse.exe
0x00007ff67b05cef9 d5_immerse.exe
0x00007ff67aee3dfe d5_immerse.exe
0x00007ff67d0fe0f2 d5_immerse.exe
0x00007ff67b663895 d5_immerse.exe
0x00007ff67b66b6bc d5_immerse.exe
0x00007ff67b66b73a d5_immerse.exe
0x00007ff67b66c78c d5_immerse.exe
0x00007ff67b675034 d5_immerse.exe
0x00007ff67fbbf212 d5_immerse.exe
0x00007ffa73977374 KERNEL32.DLL
Why I think this is not a bad file on my side: the two models have nothing in common.
- Crash 1 (21:38:30) - a site hut: layers
ASEOS,LOGO,TEXTO H,VIDRIO,FRENTE,ACERO,MANILLA. Bounding box Min=(-3.607, 0.000, -14.140) Max=(258.221, 644.876, 279.140). - Crash 2 (21:29:04) - a cleaning boat: layers
FASES,BARCO LIMPIEZA,AZUL,MALLA,negro,CUBIERTA. Bounding box Min=(-776.985, -897.323, -10.572) Max=(-0.000, 146.198, 367.014).
Different geometry, different materials, different layer names, different sizes - and the faulting address is the same value both times. That looks like a pointer/offset computed wrong inside the refresh path rather than something driven by the model data.
It is not a resources problem either: 65 GB of 96 GB RAM free, and VRAM at 3.8 GB of 16.3 GB.
Two notes that may help other users find their own logs, because at first it looks like D5 leaves no trace at all:
- There is no
Saved\Crashesfolder and nothing in the Windows Event Log, because D5 catches the exception itself (LaunchWindowsStartup.ExceptionHandler→StaticShutdownAfterError→FPlatformMisc::RequestExit) and exits. - The log is rotated on every launch, so the crashed session is NOT in
d5_immerse.log- it is in%LOCALAPPDATA%\d5_immerse\Saved\Logs\d5_immerse-backup-<date>-<time>.log, and those timestamps are in UTC, not local time. That cost me a while.
I still have both backup logs. Tell me where to upload them and I will send them privately, along with the two Rhino files if that helps.
Is there anything I can do meanwhile? Refreshing/replacing a linked Rhino model is part of my normal workflow (I work in construction phases and I have to re-link the model fairly often), so right now I am saving the project before every refresh in case it goes down.