Troubleshooting WinCC Runtime Unhandled Exception PDLRTSEH.LOG

Troubleshooting WinCC Runtime Unhandled Exception PDLRTSEH.LOG Errors

WinCC V6.2 SP2 Runtime environments — particularly those deployed inside PCS 7 V7.0 SP1 plants — occasionally raise a generic but disruptive Unhandled exception was raised. Look file "C:\<projectpath>\PDLRTSEH.LOG" message. The Runtime usually freezes the moment the operator clicks the screen that triggers the fault, the alarm logging window appears blank or stuck, and online trend controls may stop updating. This reference walks through the root causes Siemens has documented, the diagnostic path that isolates them, and the field-proven workarounds for each failure mode.

1. Problem Description and Symptoms

Operators report one or more of the following during normal Runtime operation:

• An alert dialog reading "Unhandled exception was raised. Look file PDLRTSEH.LOG" appears, the process is suspended, and the WinCC Explorer / Runtime window becomes unresponsive.
• The fault is non-deterministic: it appears 1–3 times per week on a single client in a redundant server / multi-client topology, and may migrate between clients in subsequent occurrences.
• Triggered specifically when the user opens a particular picture, opens Historical data inside an OnlineTrendControl, or activates Alarm Logging / Tag Logging at project start.
• Identical project runs without fault on a reference machine with the same software installation.
• PDLRTSEH.LOG records an access violation (0xC0000005) reading or writing a WinCC subsystem DLL — most commonly PDLRT.dll, CCDBCLIENT.dll, WinCC_OLE.dll, or one of the C-/VBScript engine modules loaded by Graphics Runtime.

2. Environment and Affected Versions

The fault has also been confirmed on WinCC V6.2 SP3 and V7.0 SP1 / SP2 installations that inherited a V6.2 SP2-era project. The mechanism is the same: the WinCC Graphics Runtime exception handler is named PDLRTSEH (Picture Description Library Runtime Structured Exception Handler) and writes the dump file whenever the underlying C/C++ module trips a structured exception.

3. Root Cause Catalogue

Siemens' official support database and field engineering observations converge on the following ranked list of causes. The first three are documented in Siemens Support Entry 109766432 – "Activating WinCC Runtime freezes during Alarm/Tag Logging"; the remaining causes are derived from reproducible engineering cases.

3.1 Windows Service "Message Queuing" Not Started

WinCC V6.2 and V7.0 use MSMQ (Microsoft Message Queuing) for inter-process communication between Graphics Runtime, Alarm Logging Service, Tag Logging Service, and the redundant server partner. If the Message Queuing service is set to Manual or Disabled, the alarm and tag subsystems deadlock on first write, raising an exception inside CCDBCLIENT.dll that is caught and logged to PDLRTSEH.LOG.

3.2 Damaged WinCC Template Database

Every WinCC project contains a TemplateDB.mdf / TemplateDB_log.LDF pair that is copied on first Runtime activation to form the project-specific CC_<ProjectName>_<Timestamp>.mdf archive. Corruption in the template propagates to every project that activates on that host, but only intermittently — SQL Server's read-ahead cache may return valid pages for several days before hitting the damaged extent.

3.3 Corrupted Project Configuration File

The WinCC project registry hive (WinCC_<Project>.pnl, GraCS\*.pdl, and the central project.mcf) can become inconsistent after an aborted save, anti-virus file lock, or cluster failover. The structured exception is then raised on the first picture that requires the missing configuration entry.

3.4 Corrupted Graphic Object Inside a PDL Picture

Frequently reported in field service tickets: a single OCX, ActiveX, or OLE container inside a picture holds a stale pointer. The exception fires only when the operator navigates to that exact picture, matching the original symptom "when I click on the tab that contains a picture in particular".

3.5 DLL Version Mismatch Between Engineering and Runtime Station

Although both machines report the same SW versions, the local DLL cache (%WINDIR%\System32 and the WinCC installation folder) may diverge after Windows Update, manual DLL registration, or installation of a third-party OPC / Historian client. The Runtime can load a binary that exposes a different exported symbol set and crash inside the PDL script engine.

3.6 Network / SIMATIC Shell Instability on Terminal Bus

On redundant servers with teamed NICs, the WinCC client/server heartbeat traverses the SIMATIC Shell. A broken TCP keep-alive, an STP recalculation on the terminal bus, or a NIC failover that exceeds WinCC's reconnection timeout can cause the Graphics Runtime to throw inside the message dispatcher. The fault appears as if it is "in a random client at a random time" — a pattern reported by plant operators with 2 redundant servers and 6 clients.

4. Diagnostic Workflow

1. Capture the log path. The exact path is shown in the dialog: typically C:\<WinCCProject>\PDLRTSEH.LOG on the affected server or client. The file is regenerated on every fresh exception.
2. Open PDLRTSEH.LOG in Notepad. Each entry contains a timestamp, the faulting module, the exception code, and an offset. Common lines look like:

   // PDLRT Structured Exception Handler Log
   [12.03.2024 09:14:22] ExceptionCode = 0xC0000005 (ACCESS_VIOLATION)
   [12.03.2024 09:14:22] FaultingModule = C:\Program Files\Siemens\WinCC\bin\PDLRT.dll
   [12.03.2024 09:14:22] FaultingOffset = 0x00012A30
   [12.03.2024 09:14:22] Picture = Overview.pdl
   [12.03.2024 09:14:22] Object  = WinCC Online Trend Control

   The Picture and Object fields are the fastest way to localise the trigger (see §6.4).
3. Capture a WinCC APDIAG trace. APDIAG (WinCC Performance and Diagnostic Tool) is installed with the WinCC DVD under \Tools\APDIAG and provides an instrumented Runtime that records C / VBS errors, GAPI calls, and tag subscription events. Run APDIAG.exe /Project:<ProjectName> /Mode:Trace from the project path. APDIAG writes apdiag.log next to PDLRTSEH.LOG.
4. Verify Windows services. Open services.msc on the affected station and confirm Message Queuing, SQL Server (WINCC), SIMATIC WinCC ArchiveManager, SIMATIC WinCC AlarmManager, and SIMATIC WinCC TagManager are all Started and Automatic.
5. Diff binary versions between the working and the failing station using fc /b <ref>\PDLRT.dll <fail>\PDLRT.dll for every DLL mentioned in PDLRTSEH.LOG.
6. Reproduce the fault on the working machine by copying the project folder 1:1 and re-activating Runtime. If the working machine does not fail, the divergence is environmental (services, DLL, NIC teaming), not project-based.

5. Resolution by Root Cause

5.1 Fix the Message Queuing Service

1. Open Control Panel → Administrative Tools → Computer Management → Services and Applications → Message Queuing.
2. Right-click Message Queuing → Properties. Set Startup type to Automatic.
3. From an elevated command prompt run:

   sc config MSMQ start= auto
   net start MSMQ

4. Reboot the station and re-activate the WinCC Runtime.
5. Verify with sc query MSMQ that state reads RUNNING and that C:\Windows\System32\msmq\storage exists.

5.2 Repair the WinCC Template Database

1. Stop the WinCC Runtime on the affected station.
2. Locate the template at C:\Program Files\Siemens\WinCC\SQLTemplates\TemplateDB.mdf (WinCC V6.2) or C:\Program Files\Siemens\Automation\WinCC\SQLTemplates (V7.0+).
3. Open SQL Server Management Studio, attach TemplateDB.mdf, and execute:

   DBCC CHECKDB('TemplateDB') WITH NO_INFOMSGS, ALL_ERRORMSGS;
   ALTER DATABASE TemplateDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
   DBCC CHECKDB('TemplateDB', REPAIR_ALLOW_DATA_LOSS);
   ALTER DATABASE TemplateDB SET MULTI_USER;

4. If DBCC CHECKDB reports unrepairable corruption, replace the template from the original WinCC installation DVD or from a known-good backup.
5. Delete the corrupted project archive in C:\<Project>\ArchiveManager and re-activate Runtime to force a clean recreation from the repaired template.

5.3 Rebuild the Corrupted Configuration File

1. Close WinCC Explorer on all clients.
2. Back up the full project folder C:\<Project>.
3. Open the project on the engineering station, then Project → Save As → Compile OS to regenerate project.mcf and the PNL files.
4. If only one picture is suspected, copy the offending PDL out, then re-import a clean copy from the project backup or from the working station.
5. For an entire damaged project, run Project → Migrate / Reorganize from WinCC Explorer. The tool re-indexes the project files and repairs internal pointers in GraCS\.

5.4 Isolate a Corrupted Graphic Object (Bisection Method)

The bisection method has resolved the highest number of field tickets because it requires no DLL or service knowledge:

1. In WinCC Explorer, copy the failing PDL to FaultA.pdl and FaultB.pdl.
2. Open FaultA.pdl, delete the second half of the objects, save, and activate Runtime. Navigate to the picture.
3. If the fault reappears, the defect is in the first half. Delete objects from the second half of the first half, save, and re-test.
4. If the fault disappears, the defect is in the deleted second half. Restore FaultA.pdl and repeat against the other half.
5. Repeat until a single object (typically a WinCC Online Trend Control, WinCC Alarm Control, OCX, or scripted smart object) is identified. Replace the object with a freshly inserted instance of the same control.
6. Alternatively, rename the original PDL to Overview_old.pdl and create a new Overview.pdl from a known-clean template, re-inserting objects one by one until the exception returns.

5.5 Reconcile DLL Versions Between Stations

1. On the engineering station, run Start → SIMATIC → WinCC → Tools → WinCC Installation Check and export the report as installcheck_ref.txt.
2. On the affected station, run the same tool and export installcheck_fail.txt.
3. Diff the two reports with a text comparison tool. Replace any divergent DLL with the version from the reference station, taking the file from the original WinCC DVD to guarantee a clean build.
4. Re-register WinCC OCX files from the engineering station folder:

   for %f in ("C:\Program Files\Siemens\WinCC\bin\*.ocx") do regsvr32 /s "%f"

5. Reboot and re-test.

5.6 Stabilise the Terminal Bus and SIMATIC Shell

1. Disable energy-efficient Ethernet (EEE) and any green-IT power saving on every NIC participating in the team. EEE has been shown to interrupt the SIMATIC Shell keep-alive at unpredictable intervals.
2. On the teamed NICs, set Speed & Duplex to Auto / Full explicitly; do not leave it on default Auto Negotiation with managed switches running LACP.
3. Increase the CCFast and TagLogging timeout in WinCC Explorer → Computer → Properties → Startup to 30 s to ride out momentary failover events.
4. Update the SIMATIC Shell via the PCS 7 V7.0 SP1 hotfix package if the WinCC clients are still on the original 6.2.2.0 shell release.
5. Validate end-to-end with simatic_shell_diag.exe (bundled with PCS 7) and confirm 0 packet loss over 24 h.

6. Verification Procedure

After applying the corrective action, confirm the fix with the following checks:

1. Activate the WinCC Runtime and click the previously failing picture 20 times in succession. PDLRTSEH.LOG should not be regenerated.
2. Open the Online Trend Control that previously triggered the historical data access violation. Cycle through Online, Online historical, and Online buffered modes.
3. Force a redundant failover: stop the master server, verify the standby takes ownership, and exercise the same picture from each client.
4. Capture 72 hours of APDIAG trace; the count of STATUS_ACCESS_VIOLATION entries must be 0.
5. Run DBCC CHECKDB on every project database and on the template database. The result must read clean with no allocation or consistency errors.

7. Diagnostic Matrix

8. Preventive Maintenance

• Set Message Queuing, SQL Server (WINCC), and all SIMATIC WinCC *Manager services to Automatic (Delayed Start) via Group Policy.
• Schedule a monthly DBCC CHECKDB on every WinCC archive database, with a 5% sample of rows physically verified.
• Keep the WinCC Installation Check output for every station in \SERVER\WinCC\InstallChecks\<hostname>_<date>.txt; compare monthly to catch DLL drift introduced by Windows Update.
• Enable WinCC Change-Log on the engineering station to record every PDL modification; this accelerates the bisection method.
• Maintain terminal bus switches on a documented firmware; subscribe to vendor security advisories and re-validate SIMATIC Shell performance after each switch firmware upgrade.
• After any change to the project, perform an "all-clients" simulated click-walkthrough using the WinCC Runtime Simulator (RT_sim.exe /Project:<Project>) before the next production window.

9. Field-Proven Caveats

10. Frequently Asked Questions