When using DocumentRenderer.Render() to rasterize PDF pages in a batch process,
a System.AccessViolationException occurs very rarely in the native PDFium function
FPDFDOC_ExitFormFillEnvironment, which is called during the internal cleanup phase of the
Render method (via PdfiumRenderer.Load → Dispose → FPDFDOC_ExitFormFillEnvironment).
The crash is non-deterministic and not data-dependent — the same PDF file can be rendered
successfully on retry. Each batch process handles approximately 7,000 PDF files (each 1–2
pages) in a single run, and the crash occurs roughly once in every 50 batch executions
(i.e., approximately once per 350,000 files processed across separate process invocations).
Processing is strictly sequential (single-threaded, no parallel or concurrent access to
PDFium). A new DocumentRenderer instance is created for each PDF file. The process starts
and terminates for each batch, so there is no long-lived process accumulating state across
runs.
What steps will reproduce the problem?
- Create a console application that uses DocumentRenderer to render PDF pages to Bitmap
in a loop, processing approximately 7,000 PDF files per batch run sequentially.
- For each PDF file:
- Instantiate DocumentRenderer with RenderOption { Print = true, Background = Color.White }
- Call renderer.Render(renderer.GetPage(pageIndex + 1), scale) for each page
- Dispose the renderer after processing all pages
- Repeat the batch execution approximately 50 times. The crash occurs roughly once in
every 50 runs — within a single batch of ~7,000 files, not after long-term accumulation.
What is the expected output? What do you see instead?
Expected: All PDF pages are rendered to Bitmap successfully without exceptions.
Instead: The process terminates with an unhandled System.AccessViolationException.
The stack trace shows the crash occurs in the native PDFium call
FPDFDOC_ExitFormFillEnvironment(IntPtr), invoked from Cube.Once.Invoke →
DisposableBase.Dispose → PdfiumRenderer.b__0 → PdfiumRenderer.Load.
Full stack trace:
at Cube.Pdf.Pdfium.NativeMethods.FPDFDOC_ExitFormFillEnvironment(IntPtr)
at Cube.Once1.Invoke(Action1)
at Cube.DisposableBase.Dispose()
at Cube.Pdf.Pdfium.PdfiumRenderer+<>c__DisplayClass0_0.b__0(IntPtr)
at Cube.Pdf.Pdfium.PdfiumRenderer.Load(IntPtr, Int32, Func`2)
at Cube.Pdf.Pdfium.PdfiumRenderer.Render(IntPtr, Int32, SizeF, Angle, RenderOption)
at Cube.Pdf.Pdfium.DocumentRenderer.Render(Page, SizeF)
What version of the product are you using? On what operating system?
- Cube.Pdf.Pdfium: 9.5.0
- Cube.Native.Pdfium.Lite: 142.0.7444
- Runtime: .NET Framework 4.8.1 (x64)
- OS: Windows Server 2022
Please provide any additional information below.
- The PDFs are programmatically generated by GrapeCity ActiveReports (simple report layouts,
1-2 pages, no form fields or JavaScript).
- A sample PDF that has triggered the crash is attached. Note that this PDF can also be
rendered successfully — the crash is not reproducible with a specific file.
tmpC567.pdf
- Processing is single-threaded: one DocumentRenderer is created per file, used, and
disposed before the next file is processed.
- The application runs as a console application invoked manually or via Windows Task
Scheduler.
- The process is short-lived: each invocation processes ~7,000 files and then terminates.
The crash is not caused by long-running process state accumulation. FPDF_InitLibrary
and all PDFium state are freshly initialized on each run.
- We suspect this may be a memory corruption or use-after-free issue in the native PDFium
library triggered under specific memory/timing conditions, unrelated to cumulative
processing volume within a single process.
- We would appreciate any guidance on:
(a) whether this is a known issue in PDFium or the Cube.Pdf wrapper,
(b) any recommended workaround (e.g., process isolation, periodic restart), or
(c) whether upgrading to a newer PDFium version may resolve this.
When using DocumentRenderer.Render() to rasterize PDF pages in a batch process,
a System.AccessViolationException occurs very rarely in the native PDFium function
FPDFDOC_ExitFormFillEnvironment, which is called during the internal cleanup phase of the
Render method (via PdfiumRenderer.Load → Dispose → FPDFDOC_ExitFormFillEnvironment).
The crash is non-deterministic and not data-dependent — the same PDF file can be rendered
successfully on retry. Each batch process handles approximately 7,000 PDF files (each 1–2
pages) in a single run, and the crash occurs roughly once in every 50 batch executions
(i.e., approximately once per 350,000 files processed across separate process invocations).
Processing is strictly sequential (single-threaded, no parallel or concurrent access to
PDFium). A new DocumentRenderer instance is created for each PDF file. The process starts
and terminates for each batch, so there is no long-lived process accumulating state across
runs.
What steps will reproduce the problem?
in a loop, processing approximately 7,000 PDF files per batch run sequentially.
every 50 runs — within a single batch of ~7,000 files, not after long-term accumulation.
What is the expected output? What do you see instead?
Expected: All PDF pages are rendered to Bitmap successfully without exceptions.
Instead: The process terminates with an unhandled System.AccessViolationException.
The stack trace shows the crash occurs in the native PDFium call
FPDFDOC_ExitFormFillEnvironment(IntPtr), invoked from Cube.Once.Invoke →
DisposableBase.Dispose → PdfiumRenderer.b__0 → PdfiumRenderer.Load.
Full stack trace:
at Cube.Pdf.Pdfium.NativeMethods.FPDFDOC_ExitFormFillEnvironment(IntPtr)
at Cube.Once
1.Invoke(Action1)at Cube.DisposableBase.Dispose()
at Cube.Pdf.Pdfium.PdfiumRenderer+<>c__DisplayClass0_0.b__0(IntPtr)
at Cube.Pdf.Pdfium.PdfiumRenderer.Load(IntPtr, Int32, Func`2)
at Cube.Pdf.Pdfium.PdfiumRenderer.Render(IntPtr, Int32, SizeF, Angle, RenderOption)
at Cube.Pdf.Pdfium.DocumentRenderer.Render(Page, SizeF)
What version of the product are you using? On what operating system?
Please provide any additional information below.
1-2 pages, no form fields or JavaScript).
rendered successfully — the crash is not reproducible with a specific file.
tmpC567.pdf
disposed before the next file is processed.
Scheduler.
The crash is not caused by long-running process state accumulation. FPDF_InitLibrary
and all PDFium state are freshly initialized on each run.
library triggered under specific memory/timing conditions, unrelated to cumulative
processing volume within a single process.
(a) whether this is a known issue in PDFium or the Cube.Pdf wrapper,
(b) any recommended workaround (e.g., process isolation, periodic restart), or
(c) whether upgrading to a newer PDFium version may resolve this.