WARNING / DISCLAIMER
I am a Twinmotion user (architectural visualisation), not affiliated with Epic Games or NVIDIA, and this is an unofficial community workaround, not an official fix.
Credit where it is due: I did not work this out alone. I diagnosed it in collaboration with Anthropic’s Claude (an AI assistant), which analysed the actual crash files and Twinmotion log from my machine (an RTX 5080 laptop), identified the faulting component, and proposed the steps below. I provided the crash data, spotted that Twinmotion was deleting the config file between launches, and ran the testing that confirmed the fix holds. So this is a joint diagnosis rather than something I came up with from expertise of my own, and I would rather say so than take credit I am not owed.
So far, it has been completely stable for me across many launches, saves and quits, but please understand what it involves before you apply it: it edits a Twinmotion config file, sets that file to read-only so the app cannot regenerate it, and disables two NVIDIA features (DLSS Frame Generation and Reflex). Neither I nor an AI assistant can guarantee it will behave identically on every system, driver version or future Twinmotion build, so treat it as a starting point to test on your own setup rather than a guaranteed cure. Back up the file as described below, and apply this at your own risk. If anything seems off afterwards, it is fully reversible in seconds (see “To reverse” at the end).
TLDR
On RTX 50-series (Blackwell) cards, Twinmotion 2026 under DirectX 12 crashes when the viewport’s swap chain is torn down, which happens on saving a project and on quitting. The culprit is NVIDIA DLSS Frame Generation, loaded by default, hooking into the swap chain. The fix is to stop that plugin loading by adding two console variables to a per-user Engine.ini and setting that file read-only so Twinmotion cannot wipe it. You stay on DX12 and keep ray tracing and path tracing.
PROBLEM
Affected setup: Twinmotion 2026 (2026.1), DirectX 12 enabled, on an NVIDIA RTX 50-series (Blackwell) GPU. Multiple users have reported this across different 50-series cards.
Symptom: a fatal error that kills the app, reliably when you save a project and also when you quit. The crash text reads roughly:
Fatal error: [File:D:\build\TM+20261\Sync\Engine\Source\Runtime\D3D12RHI\Private\D3D12Util.cpp] [Line: 1030]
Result failed
at D:\build\TM+20261\Sync\Engine\Source\Runtime\D3D12RHI\Private\D3D12Viewport.cpp:572
with error 80004004
Viewport=..., Num=3, Size=(...), PF=18, DXGIFormat=0x18, Fullscreen=0, AllowTearing=1
Crash in runnable thread RHIThread
Two things to clear up first, because both send people down the wrong path:
- The reference to a
D:\build\...file on a D drive you do not have is a red herring. That is the path on Epic’s build server, baked into the binary when Twinmotion was compiled. It is not looking for anything on your machine. Everyone running this build sees the identical path regardless of their own drive letters. - The error code
80004004isE_ABORT, and the failing operation is the creation or teardown of the viewport’s swap chain on the render thread. That is the symptom, not the cause.
Root cause: Twinmotion 2026 loads NVIDIA DLSS Frame Generation by default (through the NVIDIA Streamline framework). Streamline inserts an interposer into the DXGI swap chain so it can present generated frames. Whenever the swap chain is torn down, which is exactly what happens on a save and on quit, Streamline throws an exception and the underlying D3D12 call aborts, and the RHIThread treats that aborted result as fatal. In the Twinmotion log you can see a Streamline exception (it writes its own sl-sha-...dmp minidump) firing immediately before the D3D12Viewport.cpp:572 failure. The project itself saves successfully first, then the app dies on the swap chain teardown, which is why the file is intact but the session is lost.
This is also why the common advice of switching to DirectX 11 “works”: DX11 disables Streamline and Frame Generation entirely. The downside is that it also strips out ray tracing and path tracing, so you lose the features you are on DX12 for. The fix below keeps you on DX12.
SOLUTION
The idea is to stop the Frame Generation (and Reflex) plugins loading at all, while staying on DX12. We do this with two console variables. Note that Twinmotion is a Shipping build, so the usual ConsoleVariables.ini is ignored; the method that works in a Shipping build is a [SystemSettings] block in a per-user Engine.ini.
There is one catch that will trip you up if you are not warned: Twinmotion regenerates the Saved\Config\WindowsEditor folder on launch and will overwrite your edited Engine.ini, stripping your lines. The result is that the fix works on the very next launch and then the crash returns on the launch after. The way around this is to make the file read-only so Twinmotion cannot rewrite it. That step is essential.
Steps:
- Fully close Twinmotion.
- In File Explorer, go to (replace the username with yours):
C:\Users\<YOUR_USERNAME>\AppData\Local\Twinmotion\Saved\Config\WindowsEditor - Look for
Engine.iniin that folder. If it is not there, create a new text file and name it exactlyEngine.ini(make sure Windows has not silently named itEngine.ini.txt). - Open
Engine.iniand add these three lines. If a[SystemSettings]section already exists, just add the twor.Streamline...lines under it rather than adding a second section header:
[SystemSettings]
r.Streamline.Load.DLSSG=0
r.Streamline.Load.Reflex=0
- Save and close the file.
- Make a backup copy of this
Engine.inisomewhere safe, so you can drop it back in if it is ever lost. - Right-click
Engine.ini, choose Properties, tick Read-only at the bottom, and click OK. This is the step that stops Twinmotion wiping your change. Do not skip it. - Launch Twinmotion, save a project, quit, then launch again. The second launch is the real test: previously it would have crashed by now.
To confirm it has actually taken effect, open the log at: C:\Users\<YOUR_USERNAME>\AppData\Local\Twinmotion\Saved\Logs\Twinmotion.log and search for “Streamline”. After the fix you should see lines reading “Skipping loading Streamline DLSS-FG” and “Skipping loading Streamline Reflex”. Before the fix those same lines read “Loading…”. If they still say “Loading”, the file was not read in time, usually because the read-only step was missed or the file is in the wrong folder.
Optional, belt and braces: in Edit > Preferences > Quality, set Resolution scaling mode to Temporal super resolution. This keeps you off the NVIDIA upscaling path entirely. It is not strictly required once the Frame Generation plugin is blocked, since Frame Generation is the crash-relevant component, but some prefer it.
What this does and does not cost you:
- It disables DLSS Frame Generation and Reflex. DLSS Super Resolution (upscaling) still works if you want to use it.
- It does not affect export quality. The Quality tab governs the viewport only; Twinmotion always exports images, video, panoramas and sequences at Ultra regardless of these settings.
- You remain on DirectX 12, with ray tracing and path tracing intact.
A note on updates: keep that backup. A point update should leave your Saved folder alone, but if a future version ever starts crashing on save again, the first thing to check is that this Engine.ini still exists, still contains the two lines, and is still read-only. A major new version (for example a future Twinmotion 2027) would use a different Saved folder, so you would recreate the file there.
To reverse this completely: untick read-only on Engine.ini and delete the two r.Streamline... lines (or delete the file), and Twinmotion returns to its default behaviour on the next launch.