Resolving WinCC Runtime Crashes: Diagnostic Procedures and Fixes

WinCC Runtime (whether the classic WinCC 7.x SCADA runtime, WinCC Runtime Professional under TIA Portal, or WinCC Runtime Advanced) is a long-lived Win32 / .NET process that can fail for reasons that are not always obvious from the operator screen. Frequent, non-deterministic crashes typically fall into one of five categories: incompatible Windows builds, script/VBScript or C-script faults, graphics/PDL corruption, memory exhaustion, or redundant server failover glitches. This article consolidates the diagnostic workflow that Siemens support engineers apply when a customer reports a recurring runtime crash, with concrete paths, file names, registry keys, and parameter sets that you can verify on the affected machine.

1. Identify the WinCC Product Line and Exact Version

Every diagnostic branch depends on the product. The same word "WinCC" can mean four different executables, and each has its own crash signature, log path, and support matrix.

To read the installed version directly from a CMD prompt, run:

reg query "HKLM\SOFTWARE\Siemens\Automation\WinCC" /v Version
reg query "HKLM\SOFTWARE\Siemens\Automation\WinCC_RT_Adv" /v Version
reg query "HKLM\SOFTWARE\Siemens\Automation\WinCCUnified" /v Version

For TIA Portal-based projects, the runtime build is reported under the project's "Device > Runtime settings > General > Version of the Runtime". Cross-check this against the Siemens WinCC Compatibility Tool (entry ID 109762833) to verify that your project version is officially released for the installed Windows build.

2. Verify the Windows OS Build Against the WinCC Compatibility Matrix

Siemens publishes a per-version matrix that lists which Windows 10 / 11 / Server builds are approved for each WinCC version. A runtime that crashes immediately after a Windows cumulative update almost always traces back to a build that is not in the matrix.

Capture the exact Windows build from an elevated command prompt:

winver
systeminfo | findstr /B /C:"OS Name" /C:"OS Version" /C:"System Type"

Compare against the relevant matrix:

• WinCC 7.5 SP2 / 7.5 SP2 Update 1 — Windows 10 IoT Enterprise LTSC 2019 (1809), Windows Server 2016, 2019, 2022.
• WinCC 8.0 (planned/released 2024) — Windows Server 2019 / 2022 with .NET 4.8.
• WinCC Professional V18 / V19 — Windows 10 LTSC 2021 (21H2), Windows 11 22H2, Windows Server 2019/2022.
• WinCC Unified V18 / V19 — Windows 10 LTSC 2021, Windows 11 22H2, Windows Server 2019/2022, with the Edge WebView2 runtime (≥ 110.x) installed.

Confirm the matrix against the official SIMATIC WinCC / WinCC Professional / Runtime – System Software documentation (entry 64847781). If the Windows build is not on the matrix, the immediate remediation is to roll back the latest quality update using wusa /uninstall /kb:<number> and pause updates via gpedit.msc → Computer Configuration → Administrative Templates → Windows Components → Windows Update.

3. Open the WinCC Diagnose Folder First

The diagnose folder is the single richest source of pre-crash state. Siemens writes log files, alarm snapshots, and redundant-server health entries here in real time, so even after a hard crash the most recent entries are still on disk.

Default locations:

Inspect the following files in chronological order, with most recent at the bottom of each file:

• WinCC_Sys_<date>.log – System-level start/stop, tag licensing, server redundancy events.
• WinCC_Service_<date>.log – Background services (alarm logging, tag logging, redundancy).
• APLog_<date>.txt – The trace written by the Automation License Manager and project-loading steps.
• *.apdiagnose – APDIAG console output (covered in Section 5).
• *PDLRT_*.log – Process/graphics runtime errors per picture.
• *.dmp – Native Windows user-mode mini-dumps created by the Windows Error Reporting service when the runtime crashes.

Filter for the time window surrounding the crash. Common high-value signatures to grep for:

For Unified RT, the equivalent filter in PowerShell on the *.json log files:

Get-ChildItem "$env:ProgramData\Siemens\Automation\Logfiles\RTUnified" -Recurse -Filter *.json |
  Select-String -Pattern '"Level":"(Error|Fatal)"' | Select-Object -Last 200

4. Confirm Screen-Specific vs. Global Crash Pattern

Before going further, classify the crash. The next steps differ by 180° depending on whether the runtime is killed by one specific picture, one tag update, or by idle background activity.

To prove the screen-specific hypothesis, open the runtime in startup picture selection mode by setting the startup picture to a known-good picture (the default Start.pdl in WinCC 7.x) and let the runtime idle for several hours. If it does not crash, you have isolated the fault to the original startup picture or to one of the actions scheduled at startup.

5. Run the APDIAG Console for Live Script Diagnostics

The APDIAG (Application Diagnostic) console is a Siemens-shipped tool that intercepts VBScript, C-script, and the global action interpreter inside the runtime. It can attach to an already-running runtime process, set breakpoints, and write a structured log of every error, exception, and unhandled reference.

For WinCC 7.x the executable is:

"C:\Program Files (x86)\Siemens\Automation\WinCC\bin\WCCILdapA.exe" -apdiag
# or interactively
"C:\Program Files (x86)\Siemens\Automation\WinCC\bin\apdiag.exe"

For TIA Portal WinCC Runtime Professional, APDIAG is invoked by launching the runtime from the TIA Portal with the option "Start with diagnostic settings" (menu Online → "Extended download to device" → tick "Activate AP Diagnostics"). For the RT PC variant you can also use the Windows start menu entry "Siemens Automation → WinCC Runtime Professional → AP Diagnostics".

Inside APDIAG, enable at minimum:

1. Trace → set to "All".
2. Watch → add the suspect tag(s), the global modules you suspect, and any custom DLL calls.
3. Log to file → point to D:\WinCCDiag\apdiag_<date>.txt. Do not log to the system drive if it is small; APDIAG traces can reach hundreds of MB per hour under heavy scripts.
4. Options → OnErrorResumeNext → UNCHECK this. With the option enabled, VBScript errors are silently swallowed and the runtime can still fall over later in a less obvious place.

Common findings from APDIAG traces that lead to runtime crashes:

• HMIRuntime.ActiveScreen.ScreenItems("myIO").OutputValue = ... when myIO does not exist on the active screen → triggers an unhandled COM exception in CCExp7.exe.
• HMIRuntime.Tags("Struct_Tag") written without first calling .Read → returns a stale or null variant.
• Recursion in a C script triggered by tag change → stack overflow after 60–90 s.
• OPC UA subscription storm (more than 5,000 monitored items on one channel) → WinCC tag manager thread pool exhaustion.

6. Capture the Crash Dump and Symbol Stack

When a runtime process is killed by an access violation, unhandled exception, or stack overflow, the Windows Error Reporting service (WER) writes a user-mode mini-dump to:

%LOCALAPPDATA%\CrashDumps\CCExp7.exe.<hash>.dmp
%LOCALAPPDATA%\CrashDumps\RT_Pro.exe.<hash>.dmp
%LOCALAPPDATA%\CrashDumps\HmiRtm.exe.<hash>.dmp

For a complete memory dump (≈ process working set), you must pre-configure WER before the crash:

1. Open sysdm.cpl → Advanced → Startup and Recovery → Settings → "Write debugging information" → "Complete memory dump" — note that this only applies to a system crash, not to a single process.
2. For per-process dumps, use the LocalDumps registry key:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\CCExp7.exe]
"DumpType"=dword:00000002
"DumpFolder"=hex(2):44,00,3a,00,5c,00,57,00,69,00,6e,00,43,00,43,00,44,00,69,00,61,00,67,00,00,00
"DumpCount"=dword:00000014

DumpType = 2 requests a full heap dump; DumpCount = 0x14 (20) keeps the last 20 dumps so they are not overwritten. Repeat the key for RT_Pro.exe, HmiRtm.exe, and Siemens.Simatic.HmiStudio.Rt.exe as appropriate.

To extract a usable stack trace, install the Windows SDK and run:

setsym.exe -pids <PID_of_RT> -y "C:\Symbols;srv*C:\Symbols*https://mssymbols.blob.core.windows.net/symbols"
!analyze -v

Match the resulting top frames against the Siemens.Automation.Hmi.*.pdb and CCExp*.pdb public symbol store. Submit the .dmp to Siemens support (see Section 11) so that their engineers can load it against the internal private symbols that are not publicly distributed.

7. Common Root Causes and Field-Proven Remediations

7.1 GDI / User Object Exhaustion

WinCC graphics use GDI handles; on long-running projects, picture windows opened and not freed (forgotten ClosePicture in C scripts, dynamic PictureWindow controls without limit) exhaust the per-process GDI handle quota (10,000 by default in Windows). The runtime may then crash with no error dialog — only an event-log entry "GDI objects at limit".

Remediation: instrument GetGuiResources(hProcess, GR_GDIOBJECTS) in a periodic background VB script; warn the operator at 7,500 and force a controlled runtime restart at 9,500.

7.2 Tag Memory Leak (WinCC 7.x with large project)

Each tag uses ≈ 80–120 bytes of resident memory. A 200,000-tag project consumes 20–24 MB just for tag administration. If the runtime is a 32-bit process (WinCC 7.x is 32-bit), the 2 GB user-mode limit is approached around 1.6 M tags or when archive segments are kept in memory.

Remediation: split the project across multiple servers, use tag multiplexing, and switch archive storage from in-memory ring buffer to disk-backed segments.

7.3 Corrupted PDL / Faceplate

Symptoms: crash only when opening one screen, or crash on the first faceplate instantiation. Use the WinCC Picture Compiler: CCPictureCompile.exe /p <project> /c — re-saves every PDL in a normalised form and reports any with structural errors.

7.4 Third-Party Driver or OPC UA Server Instability

Check the OPC_<date>.log in the diagnose folder. If the OPC UA server (e.g., SIMATIC S7-1500, third-party Kepware) disconnects and re-establishes connections more than once per minute, the WinCC tag manager can deadlock.

Remediation: in the WinCC channel configuration, set "Reconnection time" to ≥ 30 s and enable the "Deactivate on connection error" flag with a 60 s cool-down.

7.5 Windows Update / .NET Patch Side Effects

Microsoft .NET patches released on "Patch Tuesday" (especially KB5xxxxxx for .NET 4.8) have historically caused script execution failures in WinCC 7.x. The official Siemens recommendation is to enable only the security-updates channel and to test .NET patches on a non-production twin station first.

7.6 Redundancy Failover Loop

If the runtime crashes on a redundant partner and is auto-restarted, then a fast failback loop can occur if the partner's state is still "STANDBY → becoming MASTER". Increase the redundancy failback delay (Redundancy\FailBackDelay) to ≥ 60 s and verify that the redundant service has time to close its file handles.

8. Memory, Process and Service Tuning for Stability

Apply the following Windows-level hardening on every WinCC server, regardless of crash history, because the same parameters prevent the most common classes of crash:

1. Disable the Windows Error Reporting UI. In HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting set DontShowUI=1 to stop the "WinCC has stopped working" dialog from holding the process open.
2. Set the runtime process to High priority class. In Task Manager → Details → right-click CCExp7.exe / RT_Pro.exe → Set priority → High. (Permanent: create a scheduled task with /priority high.)
3. Avoid screen savers and power-management sleep. powercfg -change -standby-timeout-ac 0 and disable the lock screen via Group Policy.
4. Set the paging file to a fixed 16–32 GB on a dedicated drive, not the system drive. A dynamic paging file on the system drive is the most common cause of "random" GDI crashes under memory pressure.
5. Verify DEP is enabled for the runtime (boot.ini /noexecute=optin or default in UEFI), and add CCExp7.exe, RT_Pro.exe, HmiRtm.exe to the DEP exception list only if Siemens support has explicitly requested it.

9. Clean Up, Recompile, and Re-Deploy the Project

Once diagnostics are in place, the project itself should be cleaned before the next runtime start. A full clean re-compile eliminates the corrupted-PDL class of crash:

1. In the WinCC Explorer, run "Tools → Project Duplicator" to copy the running project to a working folder, then close the original project.
2. Run the CCCleaner tool from ...\WinCC\Tools\CCCleaner.exe to drop all compiled .pdl cache files, language DLLs, and @*.tmp files.
3. Open the project in the WinCC Explorer and trigger Tools → Compile OS → All. This regenerates the runtime DB and the picture cache.
4. For TIA Portal, perform "Project → Compile → Software (rebuild all)" and then "Online → Extended download to device → Stop runtime → Download → Start runtime".

10. Reproduce the Crash Under a Watched Test Runtime

Before contacting Siemens, reproduce the crash on a second, non-production machine with the same Windows build, same WinCC version, and the same project. This step alone cuts Siemens support response time roughly in half because it converts a "sometimes crashes" ticket into "crashes at 14:23 when this script runs".

The minimal reproduction recipe should be scripted in a one-page runbook:

1. Start runtime with APDIAG attached and WER LocalDumps enabled (Sections 5 and 6).
2. Reproduce the user sequence: open the suspect picture, press the suspect button, wait for the scheduled action, etc.
3. Wait 5 minutes after the crash for the dump and the diagnose logs to flush to disk.
4. Capture the CCExp7.exe.<hash>.dmp, the last 5,000 lines of the diagnose logs, and the apdiag_*.txt.

11. Open a Siemens Support Request (SR) with the Right Evidence

Siemens industrial support (the SR portal) requires a specific evidence bundle. Submitting the full bundle on the first reply avoids the back-and-forth that delays a fix.

Bundle to attach:

• The crash dump (.dmp) — do not zip the diagnose folder, attach each .dmp separately so Siemens can hash and match it to their internal build symbols.
• APLOG / WinCC_Sys_*.log / WinCC_Service_*.log for the day of the crash and the previous day.
• APDIAG trace file covering at least 30 minutes before the crash.
• The exported WinCC project (or at minimum the project .mcp / .apXX file, with the password).
• Output of msinfo32 /report and winver.
• Output of reg query "HKLM\SOFTWARE\Siemens\Automation\WinCC" /s — this is the canonical "what version, what channel, what options" snapshot Siemens reads first.

Open the ticket via the Siemens Industry Online Support portal (SOM); for hotline assistance under contract, dial the regional hotline published in your maintenance agreement. Reference the project ID (PID) from the WinCC Project Properties dialog; if it is empty, Siemens will ask for it before accepting the dump.

12. Preventive Maintenance Checklist

13. Verification Procedure After Applying a Fix

After any remediation, prove the fix by running the runtime under load for a minimum of 72 hours with the diagnostics enabled. The acceptance criteria are:

1. No CCExp7.exe / RT_Pro.exe / HmiRtm.exe crashes recorded by WER (check %LOCALAPPDATA%\CrashDumps).
2. No "Fatal" or "Error" entries with category "Exception", "Access violation", or "Stack overflow" in the diagnose logs.
3. GDI handle count remains < 5,000 under normal operator activity (verify via GetGuiResources or Process Explorer).
4. Process working set stable within ± 10 % over 24 h; if it grows monotonically, a memory leak is still present.
5. No silent VBScript exceptions reported by APDIAG (the OnErrorResumeNext flag must remain unchecked).

If any of these criteria fail, escalate to Siemens support with the freshly collected bundle — the crash will not fix itself and each occurrence erodes operator confidence in the system.