Fix a signage player out of memory exception after hours

What the exception signature means

Windows Presentation Foundation (WPF) draws through a separate render thread. The render thread ships drawing instructions to the composition engine over an internal channel, and System.Windows.Media.Composition.DUCE.Channel.SyncFlush() is the call that waits for a batch to be accepted. Microsoft's troubleshooting note for WPF render-thread failures states the fact that matters here: when a render-thread failure surfaces as System.OutOfMemoryException, it typically means the process exhausted some resource. That resource can sit closer to the graphics path than the RAM count in Task Manager, so a machine with plenty of free memory can still fail the flush.

The rest of the stack tells you when it failed. In this signature the flush is reached through HwndTarget.UpdateWindowPos and HwndTarget.UpdateWindowSettings. Those are the window-size and window-settings calls, which run when the window's rendering settings are refreshed. That is why display resolution and scaling are the first lever worth testing. Confirm you are on this path by matching the top of your own log against this signature:

System.OutOfMemoryException: Insufficient memory to continue the execution of the program.
   at System.Windows.Media.Composition.DUCE.Channel.SyncFlush()
   at System.Windows.Interop.HwndTarget.UpdateWindowSettings(Boolean enableRenderTarget, Nullable`1 channelSet)

A publicly reported WPF case produced this same exception at the moment an on-screen tooltip popped up, so a freeze that lands when an overlay or notification appears is a strong clue.

Symptoms and what each points to

• Freeze after several hours, OutOfMemoryException with DUCE.Channel.SyncFlush() top frame. The WPF composition channel exhausted a resource; a leak in the player's rendering path is the usual cause.
• The player is designed to restart under a watchdog, and after that it runs clean for hours again. The restart resets process memory to zero while the limit it climbs toward is unchanged. That pattern matches a leak, and it is why 'restart it nightly' is a delay, not a fix.
• The freeze lands when a tooltip, notification or overlay pops up. This matches the publicly reported WPF trigger, where the exception arrived as the tooltip appeared.
• Commit size of the player process climbs hour by hour in Task Manager. That is the leak measured directly, and the readings give you the growth rate in MB per hour.
• Changing resolution or scaling changes the time-to-freeze, or stops it. You have found a working lever; prove it over a full test window before you trust it.
• Hard crash at startup, before the first frame renders. Different path; the same Microsoft note ties this shape to image loading and graphics driver problems, so update the driver first.

Checks to run before you change settings

1. Confirm the signature. Filter the player's own log for OutOfMemoryException and read the top frame. If it is not DUCE.Channel.SyncFlush(), this article is not your case.
2. Write down the current display settings. Resolution and scaling percentage both, plus what the OS reports as the framebuffer resolution, which can sit below the panel's native resolution; the portrait player 720p framebuffer article shows one case.
3. Take hourly commit readings. In Task Manager's Details view, add the Commit size column and read the player process at startup, then once an hour for 4 hours. Two readings give a growth rate in MB per hour; four confirm whether it is steady.
4. Read the commit limit. Task Manager's Memory page shows committed memory against a limit of installed RAM plus pagefile. Write the limit down; that is the headroom the leak drains.
5. Note the player version and the graphics driver version. You need both to check for updates in the fix below.

The fix, in order

1. Stopgap today: virtual memory. Windows keeps the virtual memory (pagefile) setting with the advanced system performance options; set the size to system managed so the commit limit can grow with demand. On the documented installation this delayed the freeze, and the freeze returned, so treat it as buying time for the checks and tests below.
2. Test resolution and scaling combinations. The combination that stopped the freeze on the documented installation was 3840 x 2160 with 300% scaling. Run each candidate for 48 hours before you call it fixed; the freeze window is several hours, so 48 hours spans multiple windows. Before you commit a 4K desktop resolution, check the quirk where a portrait signage player shows a quarter of the layout; a resolution that renders the layout wrong is no fix.
3. Update the graphics driver. Microsoft's note lists graphics problems among the causes of render-thread failures, and one reported case of this exact exception was cleared by installing a newer driver.
4. Check for a newer player build. In the documented case the player's maintainers confirmed a memory leak and had no long-term fix at the time, so the real fix is a build newer than the version you recorded in the checks. No setting beats a leak fix in the player itself.
5. Cut the composition load. Fewer full-screen layers and overlays in the layout lower the pressure on the channel, and lean video keeps decode load down; the documented installation ran video re-encoded to 1080p30. If you re-encode playlist video, follow the bitrate testing before you deploy guidance rather than guessing at a number.

Example: 16 GB mini PC, 4K screen, freeze after several hours

Inputs, from the documented installation: a Windows 11 mini PC with 16 GB of RAM and a 512 GB SSD; a screen driven at 3840 x 2160; a playlist of JPG and PNG images plus MP4 video re-encoded to 1080p30; freezes after several hours with the DUCE.Channel.SyncFlush() exception; a pagefile raise that only delayed the crash.

Rule in words: a full-screen surface at 32-bit color stores 4 bytes per pixel, so its size is width x height x 4 bytes. A leak that keeps copies of such surfaces drains the commit headroom at a rate set by that size per surface.

Arithmetic:

• At 3840 x 2160: 3840 x 2160 = 8,294,400 pixels; 8,294,400 x 4 bytes = 33,177,600 bytes, about 33 MB per full-screen surface.
• At 1920 x 1080: 1920 x 1080 = 2,073,600 pixels; 2,073,600 x 4 bytes = 8,294,400 bytes, about 8 MB per surface.
• Difference per surface: 33 - 8 = 25 MB, so the same number of leaked surfaces takes about 4 times longer (33 / 8 ≈ 4) to consume the same headroom at 1080p.

Result: each full-screen 32-bit surface the leak captures takes up 33 MB at the 4K setting and 8 MB at 1080p.

Decision: test the documented combination first, 3840 x 2160 with 300% scaling, for 48 hours; if the freeze returns, the fallback that buys the most headroom is 1920 x 1080 at 25 MB less per surface, provided the layout tolerates the drop. Note what the arithmetic explains and what it does not: raising scaling to 300% makes rendered elements bigger, and that combination still held on the documented installation. The composition load depends on the whole combination, so the 48 hour test decides, and the arithmetic tells you what each fallback buys.

When a different player is the answer

This crash belongs to Windows and WPF. If the screen plays a fixed loop of images and video with no touch input, an Android all-in-one signage display plays those files locally from a microSD card or USB stick, brings its show up full screen at power-on, and carries no subscription and no PC. Windows and WPF never enter the picture, so this exception cannot appear there. Whether it fits depends on the files: PDF, PowerPoint and GIF do not play on it, so convert PDF slides to JPG before you migrate, or stay on the Windows player if the playlist leans on PDF. To see where such a player keeps its media before you move the content over, the Android signage player storage location article walks through it. For lobby and reception placements, see our lobby and reception displays.

One placement point outlives any player choice: a screen that freezes out of sight looks broken to everyone who walks past. Before you buy hardware for a spot nobody staffs, work through the questions in the elevator screens guide, because unattended placement changes what you buy and how it restarts.

Recommendation: confirm the DUCE.Channel.SyncFlush() signature in the log, set virtual memory to system managed the same day, then run 3840 x 2160 with 300% scaling through a 48 hour test. If the freeze returns, drop the desktop to 1920 x 1080, where a full-screen 32-bit surface uses 8 MB instead of 33 MB, update the graphics driver, and check the player version for a leak-fix build. Replace the PC-and-screen pair with an Android all-in-one only when the playlist is images and MP4, because PDF slides will not play on it.

Questions