Resolving WinCC 7.0 SP1 PDLRTSEH Unhandled Exception During Alarm Acknowledgment

Engineers running Siemens WinCC V7.0 SP1 in a redundant server configuration sometimes encounter an Unhandled exception error after pressing the Acknowledge all (or single-step acknowledge) function on an Alarm Table Control during runtime. The exception is written to C:\Program Files\Siemens\WinCC\Diagnose\PDLRTSEH.LOG, the WinCC Runtime terminates, and the alarm subsystem no longer loads correctly until the entire operator station is rebooted. The fault is intermittent, which makes it one of the more frustrating defects in long-running WinCC plants.

This reference consolidates the diagnostic workflow, the four most common root causes, and the field-proven remediation steps. It is written for commissioning engineers, HMI administrators, and plant-floor support staff who need to repair the runtime without re-imaging the server.

1. Problem Definition

1.1 Symptoms

• Runtime message: "Unhandled exception was raised. Look at file C:\Program Files\Siemens\Siemens\WinCC\Diagnose\PDLRTSEH.LOG for details."
• WinCC Explorer exits without user prompt immediately after the alarm acknowledgment action.
• After a warm restart of WinCCExplorer.exe, the alarm views return empty or fail to subscribe; the CCAlarm service reports no connection.
• A full PC restart restores normal operation, but the defect re-occurs at random intervals (sometimes daily, sometimes weekly).
• The fault is most reproducible when three or more Alarm Table Controls are embedded in the same picture and a global acknowledge event triggers all three simultaneously.

1.2 Affected Configurations

1.3 Reading the PDLRTSEH.LOG

The PDLRTSEH.LOG file is appended each time the Structured Exception Handler (SEH) in the WinCC Graphics Runtime (PDLRT) catches a fatal fault. A typical excerpt:

==================================================
Date         : 11.03.2014
Time         : 14:22:07
ComputerName : HMI-SRV01
UserName     : Operator
ProcessId    : 0x0A14
ThreadId     : 0x1F2C
ExceptionCode: 0xC0000005 (ACCESS_VIOLATION)
FaultingAddress: 0x00000000
Module       : PDLRT.dll
Function     : PDLRT_AlarmAcknowledge
Offset       : 0x0001B7A2
--------------------------------------------------

Key fields to capture before opening a Siemens support request:

2. Root Cause Analysis

Siemens' diagnostics, published in support entry 22892165, classify the PDLRTSEH family of exceptions as non-fatal runtime errors raised by the Graphics Runtime's Structured Exception Handler. The four most common underlying causes, ordered by frequency observed in the field, are:

2.1 Uncompiled or Stale C Functions (Primary Cause)

WinCC stores C actions in two locations: the source (editable .pas/.c file) and the compiled header (@...@*.bck). If a project is copied, restored from backup, or migrated from V6.x, the compiled header may be out of date. Calling a stale C function from an alarm event triggers a NULL dereference inside PDLRT.dll.

2.2 External ActiveX Controls with Lifecycle Mismatches

Each Alarm Table Control hosts an OLE/ActiveX container. When a custom OCX (e.g. third-party trend, video, or barcode control) is embedded into the same picture and the picture is unloaded while a global acknowledge is in progress, the ActiveX container releases its interface while PDLRT is still walking the alarm object tree. The resulting IUnknown::Release on a freed pointer raises 0xC0000005.

2.3 Multiple Alarm Table Controls in One Picture

Embedding three or more Alarm Table Controls in a single base picture doubles the trigger rate. Each control subscribes to the same CCAlarm channel and processes the acknowledge asynchronously. When the user clicks Acknowledge all, the runtime fires the acknowledge into all three controls in the same dispatcher tick, and a known race condition in CCAlgdsp.dll pre-V7.0-SP3-HF3 corrupts the alarm list.

2.4 Redundancy Synchronization Race

On a WinCC redundant pair, the standby server mirrors the message frame of the master. If an alarm is acknowledged on the master and the standby is mid-synchronization, the message-frame callback may try to clear the same alarm on the standby, producing a double-free in the message-archive memory pool.

3. Pre-Diagnosis Checklist

Before applying any of the corrective actions below, gather the following information. This avoids repeated PC reboots and is the data Siemens support requires if a hotfix request is opened.

1. Copy C:\Program Files\Siemens\WinCC\Diagnose\PDLRTSEH.LOG to a dated backup folder.
2. Copy C:\Program Files\Siemens\WinCC\Diagnose\WinCC_Sys_*.log and the most recent WinCC_Service_*.log.
3. Open WinCC Explorer > Tools > Status of Server Connections and screenshot the CCAlarm row.
4. Run reg query "HKLM\SOFTWARE\Siemens\WinCC\RT" /v Version and record the full version string (e.g. 7.0.1.0).
5. Open the WinCC Information System (start menu) and navigate to Options > Redundancy > Diagnostic Files to confirm redundancy state.
6. List the C functions present in Global Script > C-Editor and confirm whether Compile All Functions has been executed since the last project edit.
7. List every ActiveX control registered on the picture that hosts the Alarm Table Control (right-click picture > Properties > Controls tab).

4. Solution 1 - Recompile All C Functions

Recompilation is the single highest-yield fix. It addresses both the uncompiled-source issue and most ActiveX-lifetime crashes by re-binding the function pointers to the current library version.

4.1 Procedure

1. Close every WinCC Runtime instance on the affected server.
2. Open WinCC Explorer > Global Script > C-Editor.
3. Select Tools > Compile All Functions. The output window must show 0 errors, 0 warnings for every *.c and *.pas.
4. Select Tools > Generate Header to refresh the @...@*.bck shadow files.
5. Save the project (File > Save As with a new revision suffix such as _fixed_compile.pcz).
6. Restart the WinCC Runtime in the configuration runtime first (File > Activate Runtime in the Graphics Designer) and confirm the alarm acknowledgment works for 10 minutes before deploying to operators.

4.2 Verification

Trigger a single alarm from the simulated alarm source (Internal > Tag > Simulation), acknowledge it, and observe PDLRTSEH.LOG. The file should not be appended. Repeat 50 cycles to confirm stability.

5. Solution 2 - Audit and Remove External ActiveX Controls

If recompilation does not eliminate the exception, or if the log shows Module: <3rd-party>.ocx, the embedded ActiveX is the trigger. The fix is to remove the OCX from the alarm picture and to relocate the functionality to a separate pop-up picture that is opened on demand.

5.1 Procedure

1. In the Graphics Designer, open the picture that contains the Alarm Table Control.
2. Open the Object Palette > Controls tab and identify every non-Siemens control (OCX with a CLSID that is not {3D....WinCC...}).
3. Cut the controls and paste them into a new picture (Pictures\Popups\Alarm_Extras.pdl).
4. Replace the embedded control in the alarm picture with a button that opens the popup via OpenPicture("Alarm_Extras.pdl") in a C action triggered on click.
5. Recompile all C functions as in Section 4.
6. Deploy and test.

5.2 Approved OCX Inventory

The following Siemens-shipped OCX classes are verified to coexist with multiple Alarm Table Controls and do not require relocation:

6. Solution 3 - Reduce Concurrent Alarm Table Controls

If the project architecture cannot be changed to use a single Alarm Table Control, the runtime impact can be reduced by separating the controls into layered base pictures that are loaded on demand rather than all present at startup.

6.1 Pattern A - Direct Picture Change

Use three separate pictures, each containing one Alarm Table Control filtered by a different message class. Navigate between them with a header button. This eliminates the dispatcher collision entirely.

6.2 Pattern B - Picture Window with Conditional Loading

Place a Picture Window on the overview page. Set the Picture Name tag to the desired alarm picture via a C action. Only the currently selected alarm control is instantiated, so the multi-instance race cannot occur.

6.3 Pattern C - WinCC V7.2+ Migration

If the project can be migrated to WinCC V7.2 or later, the alarm display is reimplemented on the WinCC Unified graphics engine, which no longer uses the PDLRT runtime and removes the PDLRTSEH exception family. Migration is non-trivial for large projects and is recommended only when the hardware refresh is already scheduled.

7. Solution 4 - Apply WinCC Hotfixes

Siemens released a sequence of hotfixes for the PDLRTSEH exception family. The applicable hotfix depends on the installed service pack.

7.1 Hotfix Application Procedure

1. Stop the WinCC Runtime and the CCAlarm, CCMsgArch, and CCAlgDisp services.
2. Back up the project file (<ProjectName>.MCP) and the GraCS, Library, and PAS folders.
3. Run the Siemens Setup Hotfix executable with administrative credentials.
4. Reboot the server.
5. Open the project, recompile all C functions (Section 4), redeploy.

8. Redundant Pair Specific Steps

When the issue occurs on a redundant pair, additional steps are required to verify that both servers are at the same WinCC version and the same hotfix level.

1. Open Redundancy > Server Data on both servers. Confirm the partner server's Computer Name and Status are Standby (synchronized).
2. Compare the registry key HKLM\SOFTWARE\Siemens\WinCC\RT\Version on both servers. Mismatches cause the message frame to fall out of sync and produce intermittent PDLRTSEH exceptions on the standby.
3. Open the Redundancy Control diagnostic window (Start > Programs > Siemens Automation > SIMATIC > WinCC > Redundancy Control). The Last message frame timestamp must be within 2 seconds of Current time on both servers.
4. Disable automatic failover for the maintenance window and test acknowledge on the master, then on the standby, then trigger a forced failover and re-test.

9. WinCC Built-in Diagnostic Tools

Siemens ships several diagnostic tools that complement the PDLRTSEH.LOG. The most useful for this fault are:

9.1 APDiag Trace Procedure

1. Start APDiag.exe with administrative credentials.
2. Click Trace > Start and select the Alarm and Tag categories.
3. Reproduce the acknowledge event.
4. Stop the trace and export to *.csv for analysis.
5. Look for an alarm that changes state from came in to went out without the intervening acknowledged state - this indicates the message-frame dropped the acknowledgment.

10. Verification Procedure

After every fix, run the following verification sequence on each affected server before returning it to production.

1. Activate the runtime in configuration mode.
2. Inject 100 simulated alarms of varying priority and class over 10 minutes.
3. Perform Acknowledge all on each alarm table 10 times.
4. Confirm PDLRTSEH.LOG timestamp is unchanged.
5. Confirm the runtime has not exited (Task Manager > WinCC Explorer Process stable).
6. Deactivate the runtime, reactivate, and confirm the alarm tables load data within 5 seconds.
7. Repeat the sequence on the redundant partner and trigger one forced failover.

11. Preventive Maintenance Schedule

To prevent recurrence in long-running plants, integrate the following items into the regular maintenance plan.

12. Escalation Path

If all four solutions above fail to eliminate the exception, escalate to Siemens Industry Online Support with the following package:

1. Full WinCC version string (registry key above).
2. The complete PDLRTSEH.LOG file.
3. Last 24 hours of WinCC_Sys_*.log.
4. APDiag trace from the failure event.
5. The compressed project file (*.zip with the .MCP and the GraCS, Library, PAS folders).
6. Screenshot of the Status of Server Connections dialog at the time of the failure.

Reference the original Siemens support entry 22892165 - How to use WinCC diagnostic tools when opening the request, and quote the ExceptionCode and FaultingAddress from the PDLRTSEH.LOG in the subject line to route the case to the runtime team.

13. Frequently Asked Questions