CriticalPDF

Introduction

What CriticalPDF is, how the pieces fit together, and where to go next.

CriticalPDF is a Windows suite for capturing PDFs from any application and routing them through templates to a destination — save, email, print, or any combination.

Installing the MSI puts three components on the machine:

  1. The virtual printer driver — appears in every Windows print dialog as CriticalPDF.
  2. The CriticalPDF Service — a Windows service that captures each print job and hands it off to the desktop app.
  3. The CriticalPDF desktop app — where you define templates, configure email providers, watch live stats, and review captures.

All required runtimes are bundled inside the MSI. You don’t install anything alongside it and there’s nothing else to keep patched.

How a capture flows

  1. The user picks CriticalPDF in any application’s print dialog and clicks Print.
  2. The driver renders the document to PDF and queues it in the Windows print spooler.
  3. The CriticalPDF Service notices the job (sub-second via Win32 notifications, with a 1-second EnumJobs poll as backup) and pipes the PDF to the desktop app — running as the user who printed it via CreateProcessAsUser, so file permissions and audit trails are accurate.
  4. The desktop app reads the captured text, looks for the <0>identifier</0> marker tag embedded in the source content, and picks the matching template.
  5. The template’s action fires — save to a folder, send through Gmail / Microsoft 365 / SMTP / Computer Team, print to a real printer, or any combination. If the action is Ask each time, a review window opens for the user to pick.
  6. If a delivery fails, the service seals the capture into an encrypted dead-letter envelope on disk and replays it automatically when the destination becomes available again.

Why a service AND a desktop app?

Because they have different jobs.

  • The service runs as LocalSystem and never sleeps. It survives logoff, user-switching, lock-screens, and reboots. It captures every print, no matter who is signed in.
  • The desktop app runs per-user and is where the human actually works — defining templates, viewing the savings calculator, editing settings, signing into mail providers.

They communicate via a loopback-only TCP endpoint bound to 127.0.0.1:9100 (never the network) and an encrypted handoff over an anonymous stdin pipe.

Where everything lives

Everything CriticalPDF writes lives under one base folder:

C:\ProgramData\CriticalPDF\
├─ users\<username>\config.json   per-user GUI config
├─ serviceconfig.json             machine-wide service config
├─ stats.json                     shared
├─ logs\                          shared
├─ error-reports\                 shared
└─ diagnostics\                   shared

There are two distinct configs, and people often conflate them:

  • GUI config (config.json) — owned by the desktop app. Holds your templates, email / SMTP settings, licence, savings-calculator costs, and UI preferences. It is per-user: each Windows account gets its own config.json under users\<username>\, so on an RDP host one person’s templates and email settings don’t disturb anyone else’s.
  • Service config (serviceconfig.json) — owned by the background service. Holds the TCP port, printer name, capture folders, and retry policy. One per machine.

Stats, logs, error reports, and diagnostics are shared machine-wide. Secrets — the SMTP password and OAuth tokens — are never written to config.json; they go into the Windows Credential Manager instead. See Credentials & secrets.

You normally don’t edit anything here by hand — everything is reachable from the desktop app’s Settings pages. See Service operations for the cases where you do.

Where to next

Was this page helpful? Let us know.