Resolving WinCC Printit.exe Error When Printing Tag Archives

Overview

The Printit.exe module in SIMATIC WinCC is responsible for rendering and spooling tag logging archive reports to the configured Windows print device. Under specific load conditions—particularly large archive volumes or particular printer driver metadata—Printit.exe can fault with an Application Error dialog reporting an inability to read memory at a specified address. This is a Microsoft Windows structured exception (access violation, 0xC0000005) raised inside the Printit.exe address space and propagated to the Windows graphical shell as 0xC0000005 or, in older message formats, as 0xC0000094 (integer divide by zero) when record counts cross internal threshold checks.

This article documents the field-reported failure mode first observed on WinCC V6.0 SP4 running on SIMATIC PC577 industrial PCs with Windows XP SP2, then traces the downstream Siemens engineering fixes that landed in WinCC V7.4 SP1 Update 9 (K7.4.1.9) and WinCC V7.4 SP1 Update 18 (K7.4.1.18), which explicitly harden PrintIT.exe and PrtScr.exe against memory and string-length failures during print jobs.

Problem Symptoms

Field symptom set for the Printit.exe failure:

• WinCC Report Designer or runtime print job shows "Reading data" status, then hangs or terminates.
• A Windows Application Error dialog appears with the title Printit.exe and the body "The instruction at 0xNNNNNNNN referenced memory at 0xNNNNNNNN. The memory could not be read."
• The failure correlates strongly with the number of archive tags selected for one print job (typical threshold behavior: > ~120–200 tags per job, depending on row count and column count).
• Earlier Service Packs (V6.0 SP1, SP2, SP3) on the same project do not exhibit the fault.
• The fault reproduces with deterministic timing once the print-job payload crosses a memory-allocation boundary inside Printit.exe.

Affected Versions and Environment

The original report was filed against the following hardware/software combination:

The fault class was carried forward by Siemens engineering and is explicitly addressed in subsequent WinCC V7.x maintenance branches.

Root Cause Analysis

Printit.exe maintains an internal buffer for archive row data and for the page-layout structure that is passed to the underlying Windows print spooler. Three distinct triggers have been confirmed by Siemens readme entries and field reproductions:

1. Printer-name string length > 50 characters. When the Windows printer display name exceeds 50 characters (typical of clustered or copy-paste-renamed network printers), the buffer that Printit.exe allocates for the DEVNAMES structure is too small. Subsequent writes corrupt adjacent heap and produce an access violation during the read-back phase of the print job.
2. Large tag count per print job. Each tag contributes an array of VARIANT cells to the Printit render buffer. Above a runtime-determined threshold the buffer grows into unmapped pages or, on 32-bit hosts with limited contiguous free virtual address space, fails a contiguous allocation request and dereferences a NULL or stale pointer.
3. PrtScr.exe screen-capture race. The companion module PrtScr.exe shares the same printer-name parsing code path and can exhibit the same fault under identical printer-name conditions. Siemens explicitly references both modules in the same update notes.

Memory Limit Investigation

There is no published hard cap on the number of archive tags that WinCC will accept in a single print job; the practical limit is governed by the available contiguous virtual address space of the Printit.exe process and the per-row payload size. Use the following heuristic to size a print job before triggering it from runtime:

For a WinCC project that must print more than this working envelope, partition the report into multiple print jobs (e.g., by time slice or tag group) rather than forcing one oversized job.

Solution: Apply the WinCC V7.4 SP1 Maintenance Update

The Siemens engineering response to the Printit.exe / PrtScr.exe stability class is documented in the official update readmes. Two updates are directly relevant:

Both updates widen the buffer allocation for the printer display name and harden the PrintIT.exe memory path against the oversize job condition.

Prerequisite Check Before Update

1. Confirm installed WinCC version in the project: SIMATIC WinCC > About > Version.
2. Verify the target is V7.4 SP1 or later. V6.0 SP4 cannot be patched directly to V7.4 SP1; plan a controlled migration.
3. Capture a full project backup with WinCC Explorer > Project > Duplicate or with the SIMATIC WinCC Project Migrator.
4. Record all installed options (WinCC/Connectivity Pack, WinCC/IndustrialDataBridge, WebNavigator, DataMonitor) so they can be re-applied at the new build.
5. Document the license keys (CoL) for both the host and any client/sever stations.

Update Procedure

1. Stop the WinCC Runtime and the CCAgent, SQLANYs_WinCC, and Printit.exe processes from Task Manager.
2. Insert the Siemens update medium or mount the downloaded ISO.
3. Run Setup.exe and select Update installation. The installer detects the existing V7.4 SP1 base and applies the new hotfix binaries only.
4. Restart the host. Confirm the new build with: HKLM\SOFTWARE\Siemens\Automation\WinCC\Versions\Current → value should read K7.4.1.9 or K7.4.1.18.
5. Reactivate the WinCC license (automatic via Automation License Manager if an unbonded license is present).
6. Reapply any custom action DLLs to bin\ and re-test.

Workarounds Without an Update

If a maintenance update cannot be applied immediately (production uptime, validated V6.0 SP4 baseline, regulated environment), the following operator and configuration changes reduce the probability of a Printit.exe fault:

Rename the Printer

Ensure the Windows display name of the target printer is 50 characters or fewer. This removes the buffer-overrun trigger entirely.

1. Open Devices and Printers on the WinCC station.
2. Right-click the printer → Printer properties → change the topmost Printer name field.
3. Avoid embedded UNC paths in the display name; use the share alias only.
4. Reboot the WinCC Runtime service so it picks up the new device enumeration.

Partition the Print Job

Split a large archive report into smaller jobs by time range or by tag group. In the WinCC Report Designer:

1. Open the affected layout under Report Designer > Layouts.
2. Replace a single Tag Table covering all tags with multiple tables, each limited to a tag group of 50–80 tags.
3. Use a VB or C script action triggered by a button to call each layout in sequence with separate print spool entries.

Add Physical Memory and Enable /3GB

On 32-bit hosts the addressable user space is the dominant limit. Two mitigations:

• Increase physical RAM from 1 GB to 2 GB or more so the working set fits in physical memory.
• Add the /3GB switch to boot.ini (Windows XP) or via bcdedit /set IncreaseUserVA 3072 (Windows 7/Server 2008 R2) to give user-mode processes a 3 GB virtual address space. WinCC is supported on the /3GB switch but you must also set /USERVA=3030 to reserve kernel pool.

Switch to a File-Based Report Export

For regulated archives where the on-paper copy is not strictly required, export the tag logging data via the CSV Provider or Connectivity Pack and print from Excel outside the WinCC runtime. This removes Printit.exe from the data path entirely.

Diagnostic Logging Procedure

Collect the Windows event log and WinCC diagnose folder before opening a support ticket. The field engineer in the original incident was specifically asked to attach all WinCC log files from ..\wincc\diagnose\.

1. Stop the WinCC Runtime.
2. Archive %ProgramFiles%\Siemens\Automation\WinCC\diagnose\ (or ..\wincc\diagnose\ on legacy paths).
3. Export eventvwr.msc → Windows Logs > Application as .evtx.
4. Capture msinfo32 /report %temp%\msinfo.txt for hardware and driver inventory.
5. For the printer subsystem, add PrintService operational log via wevtutil sl Microsoft-Windows-PrintService/Operational /e:true.
6. Trigger one reproducible Printit.exe fault and capture the resulting access-violation dialog text verbatim.
7. Zip and submit to Siemens Industry Online Support under the WinCC > Runtime > Tag Logging > Reporting queue.

Verification Steps

After applying the update or the workaround, verify the fix with a load-shaped print job:

1. Open WinCC Explorer and trigger the largest archive report configured in the project.
2. Confirm Printit.exe remains in memory, working-set > 0 MB, and CPU activity cycles between idle and burst during spooling.
3. Confirm the print job completes with Status: Printed in the Windows print queue.
4. Run the report three consecutive times in succession; intermittent faults indicate residual buffer issues and require escalation.
5. Inspect ..\wincc\diagnose\WinCC_SStart_<date>.log for any new error entries containing Printit or 0xC0000005.

Troubleshooting Matrix

Hardware Considerations for Print-Intensive Projects

Although the Printit.exe fault is software-triggered, the hardware envelope determines whether the fault manifests:

• RAM: WinCC V7.4 SP1 on Windows 7/10 64-bit should have at least 4 GB of physical RAM reserved for the WinCC station; 8 GB is preferred for print-intensive tag logging projects.
• Disk: Pagefile on a separate spindle (or separate SSD partition) reduces working-set churn during large spool jobs. Recommended initial size = 1.5 × physical RAM.
• CPU: Modern SIMATIC IPC227G, IPC277G or IPC547G provide the headroom for Printit.exe to spool without crossing the time slice of a single print job.
• Printer driver: Use the manufacturer's signed driver; generic Windows text-only drivers can avoid the access-violation path entirely for legacy tag logging projects.

FAQ