Crash (access violation 0xc0000005) in PXCEditorCore.x64.dll when creating PDF from MPO/multi-picture JPEG (iPhone)

[ThePeml]

Product / Build: PDF-XChange Editor, version 11.0.1.0

Summary:
The application reliably crashes with an access violation in PXCEditorCore.x64.dll when creating a new PDF from an image (Document → Create → From Image(s), or equivalent) if the source JPEG is an MPO (Multi Picture Object) container rather than a plain single-frame JPEG. This affects photos taken on an iPhone 16 Pro (portrait/depth capture mode).

Steps to reproduce:

1. Take a photo with an iPhone 16 Pro in a mode that produces an MPO-format JPEG (confirmed via file inspection — see details below).
2. In PDF-XChange Editor, create a new PDF from that image file.
3. Application crashes immediately.

Crash details (from Windows Event Viewer, identical on repeated attempts — same faulting offset both times):

Code: Select all

Faulting application name: PXCEditor.exe, version: 11.0.1.0
Faulting module name: PXCEditorCore.x64.dll, version: 11.0.1.0
Exception code: 0xc0000005
Fault offset: 0x0000000001ebe4ca
Faulting application path: C:\Program Files\PDF-XChange\PDF Editor\PXCEditor.exe
Faulting module path: C:\Program Files\PDF-XChange\PDF Editor\PXCEditorCore.x64.dll

Root cause analysis (confirmed by binary inspection of the file):
The crashing file is structurally an MPO container, not a plain JPEG — Pillow identifies its format as MPO. The file contains 3 SOI (Start of Image, 0xFFD8) markers: one for the main image at offset 0, one for the small EXIF thumbnail (normal), and a third one at byte offset ~3,351,556 marking a second, full-size embedded JPEG frame (total file size ~3.97 MB). This second frame is the typical depth/secondary image Apple stores in MPO containers for certain capture modes.

Re-saving the same photo as a plain single-frame JPEG (tested using FastStone Image Viewer, which flattens the MPO container down to one image) resolves the crash completely — the resulting file has only 2 SOI markers (main image + EXIF thumbnail) and imports without issue.

This strongly suggests the JPEG decoder in PXCEditorCore.x64.dll does not correctly handle the MPO container structure and reads past the end of the first frame into the second embedded image, causing an out-of-bounds memory access.

Repair attempted: Ran "Repair" on the installation via Windows Settings — did not resolve the issue, confirming this is not an installation corruption problem but a reproducible parsing bug.

Workaround: Re-save/re-encode the source JPEG (e.g. via Windows Paint or FastStone Image Viewer) before importing, which strips the MPO container down to a single frame.

Request: Please could the JPEG import path in PXCEditorCore.x64.dll be made to either ignore any trailing embedded frames in an MPO/multi-picture JPEG, or handle them gracefully instead of causing an access violation?

Attached: a sample photo (same iPhone 16 Pro, same MPO structure) that reliably reproduces the crash — see attachment below.

IMG_2352.jpeg

[Stefan - PDF-XChange]

Hello ThePeml,

Welcome to our forums and thanks for the report!
File -> New Document -> From Images... did indeed cause my officialy available build of the Editor to restart, however I then also tested with the release candidate of V11.1 (which is in the final stages of internal testing), and with it the file was created correctly without any slowdowns or crashes. Both File -> New Document -> From Images... and dragging and dropping the image over the Editor window worked with the RC build. With the live one, as a workaround for now you can drag and drop files, and those will be converted without a crash.

Kind regards,
Stefan

[ThePeml]

Hi Stefan,

Thanks for the update — great news that it's already fixed in the 11.1 RC!

Can confirm the drag & drop workaround works reliably on my end for the current release, so I'll use that until 11.1 is officially out. Appreciate the fast turnaround and looking forward to the new build.

Kind regards,
Petr

[Stefan - PDF-XChange]