Crash-Isolated Codec Workers

HotPDF can move high-risk DCTDecode, JPXDecode, and JBIG2Decode image decoding out of the host process

Isolation modes

Once an available worker accepts a request, cimAutomatic does not retry failed or malicious input in the host process

Process boundary

Each decode request runs in a fresh hidden process assigned to a single-process Windows Job Object

Configuration

PDF.CodecIsolationMode := cimRequired;
PDF.CodecWorkerExecutable :=
  'C:\Program Files\MyApp\HotPDFCodecWorker.exe';
PDF.CodecWorkerTimeoutMilliseconds := 5000;
PDF.CodecWorkerMemoryLimitBytes := 256 * 1024 * 1024;

Bitmap := PDF.ExtractLoadedImage(0);
if Bitmap = nil then
begin
  PDF.GetLastCodecWorkerInfo(Info);
  Writeln(Ord(Info.Status), ': ', Info.ErrorMessage);
end;

An empty CodecWorkerExecutable resolves to HotPDFCodecWorker.exe beside the current application

Telemetry

GetLastCodecWorkerInfo reports the status, process identifier, exit code, elapsed milliseconds, and a bounded host-side diagnostic

GetLastJPEGReducedDecodeInfo reports source, scaled, output, and scanline geometry after an isolated reduced JPEG request

Distinct statuses cover unavailable or unlaunchable workers, timeout, crash, decode rejection, protocol mismatch, and decoded-output limits

Build and deployment

build-HotPDF-Codec-Worker.cmd

The build command emits separate Win32 and Win64 workers under tools\CodecWorker\<platform>\Release; deploy the worker matching the host process architecture

Related APIs