Sometimes a stream closes by itself in the middle of a session, with nobody touching anything, while the same application works fine for everybody else. The cause is a bug in NVIDIA's graphics driver, set off by the viewer's internet connection rising and falling. On Unreal Engine 5.8 it is already fixed on Eagle 3D Streaming. On Unreal Engine 5.7 there is no fix, but there are two ways around it.
| Your application is built on | Can it crash this way? | What to do |
|---|---|---|
| Unreal Engine 5.8 | It could, but Eagle 3D Streaming prevents it. |
Nothing. The fix has been switched on automatically for every
Unreal Engine 5.8 application on Eagle 3D Streaming since
Saturday 26 September 2026.
Possible side effect: Epic Games says the fix may cause visual glitches (artefacts) in some applications. None have been seen on Eagle 3D Streaming so far — see How Unreal Engine 5.8 avoids it. If you notice any, kindly inform support@eagle3dstreaming.com. Eagle 3D Streaming is actively looking for any side effect, to weigh it against the fix. |
| Unreal Engine 5.7 | Yes. No fix exists for this version. | The best solution is to upgrade to Unreal Engine 5.8. Until then, most viewers will never see it. If a client of yours does report streams closing by themselves, give that client a link that uses the VP9 video format, or one that runs the application on DirectX 11 — see If your application is on 5.7. |
| Unreal Engine 5.6 or earlier | Not seen. None of 5,849 sessions on these versions has ended this way. | Nothing. |
Moving to Unreal Engine 5.8 is the one change that removes the problem for good on Eagle 3D Streaming.
Pixel Streaming sends the video to the viewer over WebRTC, the browser technology for live video. Here is what happens, in order:
NVIDIA's finding. A report on NVIDIA's developer forum, which NVIDIA is tracking internally as 6241525, measures about 3.2 MB of memory lost on every encoder adjustment — only for H264 video on the Direct3D 12 route. The same adjustment through Direct3D 11 or CUDA loses nothing, and the lost memory is not given back even when the encoder is shut down. Read the report
Epic Games' finding. Epic's Pixel Streaming bug report measures the application's reserved (committed) memory growing by many gigabytes within minutes, faster when the viewer's connection is poor, and not at all with VP9. An Epic team member confirmed it is a known fault in NVIDIA's drivers, that no driver version is free of it, and that Unreal Engine 5.8 added a way around it while NVIDIA works on a fix. Read the report
Eagle 3D Streaming's finding. Forcing the adjustments on purpose
crashed the application thirteen times out of thirteen, after between about 750 and
2,100 of them. Almost every crash ended with the same Windows exit code, 0xC0000409,
which means the application stopped itself on a fatal error. Windows' own crash report
names where it happened: the faulting module is nvEncodeAPI64.dll,
NVIDIA's video encoder — not the application's code. With Unreal Engine 5.8's
way around it switched on, the same test ran more than 4,500 adjustments without a
crash.
The question is how often WebRTC asks Unreal Engine to change. Every change is one adjustment, and a crash needs a very large number of them: in Eagle 3D Streaming's tests, between about 750 and 2,100, most often around 1,800. The exact number varies from application to application, with its size and how much of the machine it uses.
That is why a short session is almost always fine. Three or five minutes of streaming is nowhere near enough changes, unless the viewer's connection is jumping up and down constantly. To reach the crash, the changes have to keep coming for a long time.
It is also why the crash almost never shows up when a developer tests the application on their own machine: a local test has a perfect, steady connection, so the changes barely happen.
The most common cause is a poor or unstable connection — mobile data, hotel Wi‑Fi, a busy shared line — because it changes all the time. But a connection does not have to be bad. Here is one example, and it is only one of many ways this can happen:
A viewer whose connection sits at 20 Mbit/s, drops to 13, comes back to 20, drops to 13 again, and keeps doing that through a long session, has a perfectly usable connection at both levels — and can still reach the crash, because what matters is how many times the connection changes, not how fast it is.
Every one of those changes goes once round this chain:
How the test was done. To reproduce it on purpose, the test forced a change five times every second — far more often than a real connection changes. At that rate the application crashed every time, thirteen runs out of thirteen, after between about 750 and 2,100 changes — most often around 1,800, roughly six minutes in. A real viewer's connection changes much less often, so reaching the same number takes much longer. Real viewers' sessions on both Unreal Engine 5.7 and 5.8 have ended this way.
The real fix has to come from NVIDIA, in the driver. It has not arrived. Epic Games, who knew about the fault from Unreal Engine 5.7, added a way around it in Unreal Engine 5.8 instead: a setting that sends the video down a different route through the graphics card, one that does not have the leak.
That setting exists only in 5.8 and later. Eagle 3D Streaming switches it on automatically for every Unreal Engine 5.8 application, and has done since Saturday 26 September 2026. There is nothing to set.
A possible side effect. The video now takes a longer route through the graphics card, and Epic Games says this may cause visual glitches (artefacts) in some applications — those built in a particular way with DirectX 12. None have been seen on Eagle 3D Streaming since it was switched on, across the whole fleet. If you notice anything wrong with your picture, kindly inform support@eagle3dstreaming.com. Eagle 3D Streaming is actively looking for any side effect, to weigh it against the fix.
Seeing artefacts? The fix is applied to every Unreal Engine 5.8 application, and there is no setting to turn it off for one application today. If you see glitches in the picture, report them to support@eagle3dstreaming.com, with the application name and what the glitch looks like.
The best solution is to upgrade to Unreal Engine 5.8. Until then, 5.7 does not have the 5.8 setting, so it cannot be protected the same way — but there are two ways around the leaking part of the driver. Both cost something, which is why neither is switched on for everybody.
| Way around it | How it avoids the bug | What it costs |
|---|---|---|
| 1. VP9 video format | Uses a different video format instead of H264, which does not go through the part of the driver that leaks. | The picture is slightly less sharp, and VP9 is encoded on the streaming machine's CPU rather than its GPU. |
| 2. DirectX 11 | Runs the application on DirectX 11 instead of 12. The driver does not leak on that route. | Some applications use features that only work on DirectX 12, such as Nanite or hardware ray tracing. In those applications, those parts stop working or look different. Applications that do not use them are unaffected. Check the application on DirectX 11 before sharing it. |
Eagle 3D Streaming could switch every 5.7 application to one of these, and chose not to. Only a small share of viewers ever run into this crash — a few sessions in every hundred — while either way around it costs every viewer something. Lowering the quality for everybody to protect a few is not a good trade.
So use one only where it is needed. If a client of yours reports streams closing by
themselves, give that client alone a second configuration on VP9 — the steps
are on the Codec page — or one with
-dx11 in its Parameters To Pass To App field on the
Developer tab (turn on Advanced Options first, or the Developer tab
is hidden; see Command-line
parameters). Everyone else keeps the default, sharper picture.
The rest of this article is the full technical story — how the crash was reproduced, what the exit code means, and how to test for it yourself. None of it is needed to act on the sections above.
This needs nothing from Eagle 3D Streaming. It crashes an Unreal Engine 5.7 or 5.8 application running on your own machine — 5.8 too, because the fix is only switched on by Eagle 3D Streaming, not by Unreal itself.
Launch the app with -AllowPixelStreamingCommands.
Without it, the app refuses the commands this test sends, nothing happens, and
the crash cannot be reproduced.
-AllowPixelStreamingCommands.
player.html in Notepad. It is at
<build>\<Project>\Samples\PixelStreaming2\WebServers\SignallingWebServer\www\player.html,
in the packaged build from that guide.
</body>
and save. The whole file is one long line: use Notepad's Find
(Ctrl+F) to locate </body>.
http://127.0.0.1 (or http://localhost) and press
CLICK TO START. The script starts by itself: a counter appears
in the top-left corner once the video is playing.
player.html afterwards.
<script>
// Crash test: asks Unreal to change the video bitrate five times a second,
// as a viewer's changing connection would. Starts by itself.
(function () {
var HIGH = 8000000, LOW = 1000000, EVERY_MS = 200;
var count = 0, high = false;
function start() {
var box = document.createElement('div');
box.style.cssText = 'position:fixed;top:8px;left:8px;z-index:99999;padding:6px 10px;' +
'background:rgba(0,0,0,.75);color:#fff;font:14px sans-serif;border-radius:6px';
box.textContent = 'Crash test: waiting for the video...';
document.body.appendChild(box);
setInterval(function () {
var ps = window.pixelStreaming;
if (!ps) return;
high = !high;
var value = high ? HIGH : LOW;
// Older plugin, then Pixel Streaming 2: whichever the app uses takes effect.
var a = ps.emitConsoleCommand('PixelStreaming.WebRTC.MaxBitrate ' + value);
var b = ps.emitConsoleCommand('PixelStreaming2.WebRTC.MaxBitrate ' + value);
if (!a && !b) {
if (count === 0) box.textContent = 'Crash test: waiting for the video... ' +
'(stuck? add -AllowPixelStreamingCommands)';
return;
}
count++;
box.textContent = 'Crash test running: ' + count + ' changes sent';
}, EVERY_MS);
}
// Works wherever it is pasted: waits for the page body if it is not there yet.
if (document.body) start(); else document.addEventListener('DOMContentLoaded', start);
})();
</script>What happened when Eagle 3D Streaming ran it. The application closed every time, thirteen runs out of thirteen, after between about 750 and 2,100 changes — most often around 1,800, roughly six minutes in. The first seven runs alone spanned four machines, three graphics driver versions and two graphics card generations. The same test with no changes did not crash. A real viewer's connection changes far less often than five times a second, which is why real sessions take much longer to get there. Re-checked on 29 September 2026 with Epic's own page and this exact script, on an Unreal Engine 5.7 application: it closed after about 2,700 changes, nine minutes in, with exit code 0xC0000409.
If it does not crash: check that the counter is climbing, and that
the delivered bitrate in the player's statistics panel drops to about
1 Mbit/s. If the counter is stuck at "waiting", the app was not launched with
-AllowPixelStreamingCommands.
Almost every one of these crashes ends with the same exit code. If an application is stopping by itself with this code, this article is very likely about it:
exit code 3221226505 (the same number written in hexadecimal: 0xC0000409)
name STATUS_STACK_BUFFER_OVERRUNIt means the application ended itself through Windows' fail-fast mechanism, which stops a process at once on a fatal condition. Many different faults end this way; the name STATUS_STACK_BUFFER_OVERRUN is historical and does not mean a buffer was actually overrun. That is why it vanishes with no crash dialog and often nothing in its own log.
Occasionally the same fault ends with plain exit code 3 instead. Different route, same event.
Once the crash reproduces, stop it by adding one more argument to the same launch line you used for the test, then run the whole test again.
Add this to the launch line — it is the way around the bug that Epic Games provides:
-AVCodecs.NvEnc.D3D12UsesCUDA=true
To build it into the application instead, so it also applies when you stream
outside Eagle 3D Streaming, add this to Config/DefaultGame.ini and
repackage:
[AVCodecs.NvEnc]
D3D12UsesCUDA=TrueRun the same test again. The application should no longer crash. In Eagle 3D Streaming's tests, with this argument added the same machines ran more than 4,500 changes without a crash, where they had crashed at about 1,800 without it. Those tests were on RTX 50 series cards. The crash also happens on RTX 40 series, where the argument has not been measured yet.
If you notice any visual glitches (artefacts) in the picture with it on, please tell support@eagle3dstreaming.com. Epic Games warns this can happen, and Eagle 3D Streaming is still looking out for it.
The argument above does not exist in 5.7. Add one of these instead, and run the test again:
-PixelStreamingEncoderCodec=VP9streams in VP9 instead of H264 (slightly less sharp, and encoded on the CPU rather than the GPU), or
-dx11runs the application on DirectX 11 (features that need DirectX 12, such as Nanite, stop working or look different).
Updating the graphics driver does not fix it. The newest driver tested, newer than the one in NVIDIA's report, still crashed.
Please send your results to support@eagle3dstreaming.com — whether it crashed, after how long, and whether the argument stopped it. Eagle 3D Streaming is keen to know how well this helps others reproduce the issue and get familiar with it, and whether you found anything these tests missed.
Last updated