Adobe crashes rendering rotated raster images

Summary: Adobe Acrobat terminates without warning when opening any PDF page that requires a raster image to be rotated at draw time. A second, independent crash occurs on JPEG images encoded with 4:4:4 chroma. Both are reproducible on demand with the attached minimal test files.

Environment

• Adobe Acrobat DC, Windows 11
• NVIDIA GPU; ASUS Monitor Control running
• Preferences → Page Display → Rendering contains no "Use 2D graphics acceleration" option, i.e. Acrobat reports no supported acceleration hardware
• Already attempted with no change: Help → Repair Installation; clean NVIDIA driver reinstall

Symptom

Acrobat closes immediately, with no error dialog, when opening scanned PDFs. Vector and text PDFs open normally. The correlation with scanned documents is incidental — see below.

Root cause

The trigger is rotation of a raster image at draw time, regardless of how that rotation is expressed and regardless of the image codec.

The distinguishing test is a pair of files whose image streams are byte-identical (verified by SHA-256 of the raw stream). The only difference between them is whether the page carries /Rotate 270:

• REPRO-1_rotate270_CRASHES.pdf — crashes
• REPRO-2_no-rotate_OPENS.pdf — opens normally

Same image data. Same container. One variable.

Test matrix

Each row varies one property. All files render correctly in Microsoft Edge, Chrome, and poppler.

What this rules out

• Not the codec. Rows 1 and 2 crash with JPEG and Flate respectively. CCITT G4 behaves the same way.
• Not image size. Row 3 crashes at one quarter the pixel count of row 1.
• Not /Rotate specifically. Row 4 has no /Rotate entry at all; the rotation was moved into a cm matrix in the content stream. It still crashes. The renderer performs the same work either way.
• Not file corruption. All files pass qpdf --check with no errors and decode cleanly in third-party libraries.
• Not the source documents. The attached reproductions are synthetic, generated programmatically.

Conclusion: any code path that asks Acrobat to rotate a bitmap while drawing it will crash the application. This is why scanned documents appear to be the trigger in ordinary use: office copiers routinely emit pages tagged /Rotate 90 or /Rotate 270, whereas PDFs produced by Word, Excel or Acrobat itself generally do not.

Second, independent trigger: 4:4:4 chroma JPEG

REPRO-3_444-chroma_CRASHES.pdf contains no rotation of any kind. Its only distinguishing property is that the embedded JPEG uses 4:4:4 chroma subsampling instead of 4:2:0. It crashes. The same image encoded at 4:2:0 (REPRO-2) opens normally. This suggests the fault is not one narrow bug in rotation handling but something broader in the image rendering pipeline.

Steps to reproduce

• Open REPRO-2_no-rotate_OPENS.pdf — confirm it opens and displays a page of text, sideways.
• Open REPRO-1_rotate270_CRASHES.pdf — Acrobat terminates.
• Confirm the two files contain the identical image stream (SHA-256 of the raw /Im1 stream matches).
• Open REPRO-3_444-chroma_CRASHES.pdf — Acrobat terminates, with no rotation involved.

Expected: all three display normally, as they do in every other PDF renderer tested.

Impact and current workaround

This makes Acrobat unusable for scanned document archives. In the affected environment it blocks routine access to a library of roughly 730 scanned PDFs, since nearly all carry page rotation from the scanning device.

The workaround in use is to rewrite affected files so the pixels are physically rotated and the /Rotate entry removed, using jpegtran for lossless JPEG transposition. This is a rewrite of valid, standards-conformant PDFs to avoid a rendering defect, and it does not help with files received from third parties.