Isolated Capture Worker

Isolated Capture Worker

Flashback runs the risky part of recording, the native capture and encoder code, in its own process. If a graphics driver or encoder misbehaves, that process is contained and replaced while the app you see keeps working. This page explains why, and what survives when something goes wrong.

The short version: capture, encoding and audio run in a small headless process with no window, network or updater. What you'll notice: if a driver or encoder hangs, the worst case is a short gap in the buffer; the window, hotkeys, library and the replay you already have keep working, and a clip never silently jumps across the gap.

Why a separate process

Screen capture and hardware encoding live in native code that talks to graphics drivers. Drivers can stall, leak or crash, and there's nothing an app can do to make that impossible. What it can control is how far the damage spreads.

With capture inside the main app, a stuck encoder could freeze your window, a leak would look like the whole app growing, and a crash would take your hotkeys and library with it. Flashback avoids that by giving capture its own process:

+--------------------------------------+        +-------------------------------+
| Desktop host (Flashback.exe)         |        | Capture worker                |
|                                      |  pipe  | (same Flashback.exe,          |
|  window, tray, hotkeys, voice        | <----> |  private headless mode)       |
|  settings, game detection            |        |                               |
|  confirmed replay history            |        |  display capture (D3D)        |
|  saves, trims, exports, library      |        |  Media Foundation encoder     |
|  updates, Cloud                      |        |  WASAPI audio capture         |
|                                      |        |  segment file output          |
+--------------------------------------+        +-------------------------------+
        survives a worker failure                    disposable, replaceable

The worker is the same signed Flashback.exe started in a private mode, so there's no second runtime to ship and the same signature covers both.

What the worker does and doesn't do

It does: display capture through Direct3D, Media Foundation hardware encoding, active audio capture, and writing and finalizing each segment file.

It doesn't: update itself, open network connections, hold a Cloud session, show a tray icon or write settings. A smaller job means less that can go wrong and nothing sensitive inside the process that's most exposed to drivers.

How the host keeps it honest

• Authenticated pipe. The host and worker talk over a named pipe limited to your Windows user. A random secret made for each launch, and checks on the process at the other end, tie the pipe to the exact worker the host started.
• Bounded messages. The protocol is versioned and size-bounded. Every command is matched to its reply and has a deadline.
• Heartbeats. While recording, the worker reports status, encoded-frame counts and resource snapshots at a low rate. The frame counter is lock-free and holds no images.
• Deadlines everywhere. Starting, rotating a segment, taking a screenshot and stopping all have time limits. If the worker misses a heartbeat or a deadline, or breaks the protocol, the host ends only the worker.

What survives a worker failure

Survives	Why
The window, tray, hotkeys and voice commands	They live in the host
Your library, editor and any export in progress	They live in the host
Every confirmed replay segment	The host owns the list of confirmed segments, not the worker
Your settings	Only the host writes them

What can be lost is the segment the worker was writing at that moment. A hard-killed encoder can leave its open MP4 unusable, and starting a fresh worker takes a moment, so there can be a brief gap in the buffer. Flashback marks that gap rather than hiding it; see Replay buffer and segment rotation.

Salvaging the last segment (0.8.0)

If the worker dies while finishing a segment, that file may in fact be complete. In 0.8.0 the host checks it before discarding it: the MP4's structure must be whole, its streams must match what the session recorded, its length must fit the time it was recording, and its final seconds must decode cleanly. A segment that passes those checks, plus the same monitor-identity check as a normal segment, joins your replay history, and a save that was waiting for it completes. Separate-audio segments aren't salvaged this way, because their audio timing ended with the worker.

Stuck native code is quarantined

Sometimes a Media Foundation callback or shutdown simply never returns. Tearing down objects in that state can crash or hang the caller. When one of these crosses its hard deadline, the worker stops trying: it reports that it's in a terminal state, leaves those native objects alone inside the disposable process, and the host replaces the whole worker. Nothing uncertain is ever carried back into the app.

Restarting

• Native failures finalize whatever can be finalized safely, then restart the worker with bounded backoff.
• During startup, repeated failures stop after a few attempts rather than looping forever.
• After a successful start, interruptions keep recovering until you stop the buffer yourself.
• Slow growth isn't treated as a crash. A worker whose memory, handles or threads keep climbing is replaced gracefully at a clean boundary; see Resource guards and recovery.

When a worker ends without a clean stop, the log records its exit code (a native crash shows up as a Windows status code such as 0xC0000005) and its last health sample compared with the session's starting point. That's what support looks at in Diagnostics and logs.

Shutting down and updating

Closing Flashback or applying an update stops the worker with an explicit deadline. If a driver or encoder doesn't return in time, the host ends the worker process rather than hanging or restarting the interface.

The cost

Running capture in a second process means a second process image in memory. Nothing per frame crosses the pipe: the worker writes segments straight to disk and only sends small status messages. The 0.6.71 release that introduced the worker measured a peak worker working set of 168.1 to 170.9 MiB at 1080p60 HEVC on one PC.

---

Related pages: Resource guards and recovery · Architecture overview · Replay buffer and segment rotation