aerender (After Effects 26.5, Windows 11, RTX 4090) returns one frame near the end of a render job with a black strip or stale picture content, exit code 0, no warning

Issue. On one of our three Windows PCs, aerender returns one frame of a render job with its lower part wrong: either a solid black strip across the full width (rows 650 to 1079 of 1080), or the same rows filled with picture content that belongs elsewhere (a sideways-shifted copy of nearby picture, or once the picture of frame 249 while rendering frame 296). The top of the frame is correct. aerender exits 0 and its log shows no error or warning, so nothing downstream knows the frame is bad. Our other two PCs and our Macs never do this.

Steps to reproduce.

1. Copy dfp-reference.aep (in the upload: one comp, 7680 by 1080, 29.97 fps, 300 frames, 16 bits per channel, generated content only, no footage; render-queue item 1 is QuickTime ProRes 4444, item 2 is a 16-bit TIFF sequence) to a local folder on the boot drive.
2. Run, from a command prompt:

   "C:\Program Files\Adobe\Adobe After Effects 2026\Support Files\aerender.exe" -project C:\Users\<user>\dfp-e1\dfp-reference.aep -rqindex 1 -s 200 -e 299 -output C:\Users\<user>\dfp-e1\out\chunk-200-299.mov -v ERRORS_AND_PROGRESS

3. Look at frame 296 of the output (index 96 of the 100-frame file), or compare the file frame by frame against the same job rendered on another machine.
4. For the TIFF form of the same fault, render item 2 for the last frame alone:

   "C:\Program Files\Adobe\Adobe After Effects 2026\Support Files\aerender.exe" -project C:\Users\<user>\dfp-e1\dfp-reference.aep -rqindex 2 -s 299 -e 299 -output C:\Users\<user>\dfp-e1\out\f_[#####].tif -v ERRORS_AND_PROGRESS

   and open f_00299.tif.

Expected result. Every frame of the output matches the comp; aerender exits 0.

Actual result. On the AMD PC, frame 296 of the 200 to 299 job (and frame 299 of a 299-only or 298 to 299 job) comes back with rows 650 to 1079 solid black, or with wrong content in those rows. The other 99 frames are byte-identical to a good render of the same job from another PC. aerender exits 0 with no warning in its log.

• Ten renders of the 200 to 299 job, one after another, on 4 Nov: frame 296 wrong in all ten (black in seven, wrong content in three: twice a sideways-shifted copy of nearby picture, once the label “frame 249 00;00;08;09” and that frame’s picture, upside down and recoloured, inside frame 296). black-frame-rate-2026-11-04.txt lists every run.
• The same ten renders on our Intel PC: 0 wrong frames in 1000, all ten files identical.
• A 16-bit TIFF of the black-strip frame is byte-identical to a good TIFF of frame 296 from row 0 to row 648; row 649 is mixed; rows 650 to 1079 are black. So the frame is rendered correctly and its bottom replaced. (The ProRes versions also differ slightly across the whole frame, which is the encoder spending the bits the black strip frees.)
• The fault comes and goes over hours: the AMD PC rendered the job correctly on the morning of 4 Nov and wrongly every time since. After a restart on 5 Nov it was wrong from the first render, two minutes after boot, and at every render up to 90 minutes later (amd-after-restart-2026-11-05.txt).
• With -mfr OFF 100 the frame is wrong in the same way (20 Oct).
• The TIFF output shows it too (18 and 20 Oct: frame 299 with its bottom third black, in six renders).

Screen recording. None; aerender is run from a command prompt with no window to show. The batch files and the full aerender logs for every run are in the upload. We can record a run if that helps.

Adobe After Effects version. 26.5 (After Effects 2026), aerender from the same install.

Operating system. Windows 11 Pro, build 10.0.26300 on the affected PC (builds 10.0.26200 and 10.0.26100 on the two that are fine).

GPU driver version. NVIDIA Studio driver 617.42 on all three PCs (the fault was also present on 610.88). The affected PC’s CPU has integrated AMD Radeon graphics; it is disabled in Device Manager and the fault is unchanged. Project video rendering: Mercury GPU acceleration (CUDA).

Video format. No footage in the project. Output: QuickTime ProRes 4444 (render-queue item 1) and a 16-bit TIFF sequence (item 2); the fault appears in both. Sample files are in the upload.

Comparative information.

• Machines: it happens on one PC (AMD Ryzen 9 7950X, 16 cores, RTX 4090). It happened once on the Intel PC (i9-9980XE, RTX 4090) on 18 Oct and never since in over a thousand frames. It has never happened on the Xeon PC (a 2019 Mac Pro under Windows 11, Xeon W-3265M, RTX 4090 plus a Radeon Pro Vega II) or on any Mac (M4 Max, M2 Ultra, M1 Ultra).
• Projects: seen with this project and with a brand-new project made for a separate test; we have not tried others on that PC.
• Which frame: always one frame near the end of the job, whatever the job is (296 of 200 to 299; 299 of 299 alone or 298 to 299), with content that varies between runs.
• When it began: first seen 18 Oct 2026, the first day we rendered on that PC.
• Checked and ruled out: third-party plugin licences (all in order; the fault returned after they were corrected), the NVIDIA driver (610.88 and 617.42), Windows’ per-app GPU preference forced to the RTX 4090, opening and closing the After Effects application, the integrated Radeon GPU (disabled), the display being off (the fault is present with a user logged in at the desktop and the monitor on), and time since boot (wrong at 2, 4, 30, 60 and 90 minutes after a restart).
• Plugins in the comp, each in its own vertical band: Neat Video, Video Copilot Saber, Vibrance, Shadow Studio 3, Sapphire S_Rays, Deep Glow 2, Magic Bullet Looks, Continuum Film Grunge. Every plugin on each PC, with its version, is listed in the three plugins-pc-*.txt files in the upload.

Questions. Is this a known issue in aerender’s handling of the last frames of a render job, or of GPU frame buffers under Mercury GPU acceleration? Which logs or settings would help: the aerender log level, a Mercury diagnostic? We can run any test you need on the machine.

Uploads (https://www.dropbox.com/scl/fo/lk1lb5d0vlto8ngqwveh8/AJ1A_l9mGyM3WQv9ue4E3L4?rlkey=regewl6m3w4thmr1j4o2rg3rc&dl=0 ,  evidence/adobe/, 2026-11-04/ and 2026-11-05/):

• dfp-reference.aep: the project (AE 2026, no footage).
• frame-296-four-versions-good-black-shifted-shifted.jpg: frame 296, top to bottom: good (Intel PC), black strip, shifted content (run 4), shifted content (run 10). Attached to the post as well.
• intel-good-chunk-200-299.mov, amd-black-strip-chunk-200-299.mov, amd-run4-chunk-200-299.mov, amd-run7-chunk-200-299.mov, amd-run10-chunk-200-299.mov: the renders themselves (ProRes 4444, 100 frames each).
• black-frame-rate-2026-11-04.txt: the ten-run test, every run and frame.
• amd-after-restart-2026-11-05.txt and amd-after-restart-boot+2min-chunk-200-299.mov: the renders after a restart, and the one made two minutes after the boot.
• frame-296-black-strip-tiff-job-290-299.tif and frame-299-complete-same-job.tif: the black-strip frame as lossless 16-bit TIFF, from a ten-frame job (290 to 299), with the complete last frame of the same job; frames-296-and-299-same-job.pngshows both.
• From 18 and 20 Oct: the incomplete TIFF frames 299 from the AMD and Intel PCs, the complete ones from the Xeon PC and a Mac, their aerender logs, and the batch files used.
• plugins-pc-amd.txt, plugins-pc-intel.txt, plugins-pc-xeon.txt: every plugin on each PC with its version and the system facts.