Resolving WinCC ntdll.dll Unhandled Exception and PDLRTESH.log

Overview of the WinCC ntdll.dll Crash

Siemens WinCC V7.0 SP3 (and adjacent service packs) ship a graphics runtime named pdlrt.exe that hosts the picture tree, dynamic dialogs, C/VBS scripts, and OCX/.NET controls rendered inside WinCC Runtime. When the runtime terminates unexpectedly, Windows raises a structured exception that bubbles up through ntdll.dll and produces a dialog reading:

Unhandled exception was raised. See file "C:\Program Files\Siemens\WinCC\Diagnose\PDLRTESH.log" for details.

After the dialog is acknowledged, the runtime window closes and the Windows taskbar is hidden, leaving the engineering station in a half-orphaned state until a manual restart of the WinCC project is performed. The error is not a Windows fault in the classical sense; it is the result of an access violation (STATUS_ACCESS_VIOLATION, 0xC0000005) or, more commonly in WinCC, a heap corruption exception (STATUS_HEAP_CORRUPTION, 0xC0000374) raised inside the graphics runtime and re-thrown by ntdll.dll when the process attempts to clean up.

This article documents a field-proven triage procedure that combines local log analysis, dump collection, and the Siemens WinCC V7.0 SP3 Update 7 patch (Entry ID 109253830) with Windows-side validation steps. The methodology is deliberately ordered so that the most likely root causes are eliminated first and the dump evidence is captured correctly before any patch is uninstalled or project state is lost.

Affected Versions and Components

Symptoms and Observable Behavior

Engineers typically observe the following sequence on the runtime station:

1. WinCC Runtime window closes spontaneously without a user action.
2. A modal dialog appears with the title bar Unhandled exception referencing the path C:\Program Files\Siemens\WinCC\Diagonse\PDLRTESH.log.
3. The Windows taskbar is hidden; the desktop appears empty until a mouse click forces redraw.
4. On a multi-monitor engineering station, the runtime may re-spawn briefly on a different monitor, then exit again.
5. Windows Event Viewer logs an Application Error event (EID 1000) with faulting module ntdll.dll and an exception code of either 0xc0000005 (access violation) or 0xc0000374 (heap corruption).

If the runtime is hosted inside a WinCC station configured as a redundant pair, the standby takes over. On a single-station configuration, the process must be restarted manually and any unsaved tag logging is lost.

Root Cause Categories

Siemens support classifies the symptom into three primary families. Each family produces a different signature in PDLRTESH.log and a different faulting offset inside ntdll.dll.

1. Script-Induced Heap Corruption (0xC0000374)

The dominant cause in V7.0 SP3. A C script, VBScript, or .NET assembly referenced from a picture's On Open, On Click, or trigger event violates the WinCC memory contract. Typical offenders:

• Calling DMGetValue or GetTag on a tag that has been deleted or is in a non-running connection state, leaving an uninitialized handle.
• Releasing a COM object twice in VBScript (for example, both explicit Set obj = Nothing and an enclosing With-block that also nulls the reference).
• Writing past the bounds of a fixed-size char[] buffer in a C action triggered by a high-frequency tag.
• Hooking a .NET WinCC control that allocates GDI handles without disposing them, exhausting the heap during long uptime.

The exception is caught by the structured exception handler in ntdll.dll only when the corrupted heap block is next accessed — frequently seconds or minutes after the offending instruction. The fault therefore appears non-deterministic.

2. Graphics Object Defects

Picture window references to deleted pictures, broken custom OCX controls, or incompatible SmartTools can raise access violations on picture change. The log file PDLRTESH.log typically contains the line "PictureOpen failed for <PDL name>" immediately before the crash entry.

3. Operating System and DLL Side-Effects

If the faulting module is unambiguously C:\WINDOWS\SYSTEM32\ntdll.dll and the exception code is 0xC0000374, Windows memory management is the proximate cause but the trigger is still a user-mode component. Microsoft's documentation on the 0xC0000374 status code (My app is crashing due to ntdll.dll application error 0xC0000374) confirms heap corruption as the underlying mechanism. A corrupt or mismatched ntdll.dll itself, however, is rare and is only considered when reinstalling the OS does not help, as documented for the analogous Autodesk crash pattern in the Autodesk knowledge base article on ntdll.dll startup failures.

Diagnostic Procedure

Step 1: Confirm the Log Path and Spelling

1. Open File Explorer as Administrator and navigate to C:\Program Files\Siemens\WinCC\.
2. Locate the Diagonse folder (legacy spelling) or Diagnose folder (post-SP3 installations).
3. Sort by Date modified and open PDLRTESH.log.

Typical fault entries appear as:

2024-xx-xx 12:34:56.789  [EXCEPTION] pdlrt.exe (PID 4321): Unhandled exception 0xC0000374
  Module: ntdll.dll @ 0x00007FFA1234ABCD
  Fault offset: 0x00000000000A1234
  Last picture: MAIN_OVERVIEW.pdl

Note the Last picture line; it identifies the PDL active at the moment of fault and is the strongest local evidence to start a code review.

Step 2: Capture Crash Dumps

From WinCC V7.0 SP3, the Diagnose folder contains a dumps subfolder. The graphics runtime writes a *.dmp file on every unhandled exception. Verify file presence:

Each file is a mini-dump that can be opened with WinDbg, Visual Studio, or the !dump extension. A typical stack includes ntdll.dll!RtlUserThreadStart → pdlrt.exe!CPDLRuntime::PictureLoop → pdlrt.exe!CScriptEngine::Execute → mscorlib.ni.dll or vbscript.dll. The top three frames pinpoint whether the corruption is picture-driven or script-driven.

Step 3: Correlate with Windows Event Viewer

1. Open eventvwr.msc and navigate to Windows Logs → Application.
2. Filter for source Application Error, Event ID 1000, in the time window of the crash.
3. Record the Faulting module name, Exception code, and Fault offset.

Step 4: Apply the Correct Cumulative Update

For V7.0 SP3, install Update 7 (Entry ID 109253830) on top of the existing installation. The update is cumulative and supersedes earlier updates for SP3. The Siemens entry page documents prerequisites, the download link, and the post-install reboot requirement. Apply the update on the engineering station first, then on every runtime and server in the same project; mixing versions is unsupported.

Step 5: Validate the Project After Update

1. Start the WinCC project and observe runtime uptime for at least 48 hours.
2. Open PDLRTESH.log daily; no new [EXCEPTION] lines should be appended.
3. Open the Windows Application event log; no new Event ID 1000 entries for pdlrt.exe should appear.
4. Run the WinCC internal diagnostic CCDiagnostics.exe (Start → Programs → Siemens Automation → WinCC → Tools) to validate installation integrity.

Script and Picture Audit Procedure

If the update does not eliminate the crash, the cause is project-specific. Use the following sequence:

1. Open the picture listed in Last picture in Graphics Designer.
2. Disable every dynamic attribute, script trigger, and OCX on that picture and reopen runtime. If the crash disappears, re-enable attributes one at a time to isolate the offender.
3. For C actions, search the project for the pattern GetTagWord( with a NULL default and replace with an explicit initial value.
4. For VBScript, search for Set statements inside loops and verify that the referenced object is destroyed deterministically.
5. For .NET controls, verify that the registered assembly is built for the same target framework (x86 vs x64) as the WinCC installation. Mixed-bit assemblies are a known heap-corruption vector.

Escalation to Siemens Support

When local diagnostics are inconclusive, escalate by opening a Service Request via the Siemens Industry Online Support portal. The dump and log evidence required by support are:

• The complete folder C:\Program Files\Siemens\WinCC\Diagonse (including PDLRTESH.log, PDLRTdiag.log, and the dumps subfolder).
• The full WinCC project archive (Project → Archive in WinCC Explorer).
• The Windows event export (eventvwr.msc → Action → Save All Events As…).
• The installed version listing from Help → About WinCC Explorer on every affected station.
• Information on any third-party OCX, .NET assembly, or SmartTool installed under \Siemens\WinCC\bin\ or \Siemens\WinCC\opc\.

Support's reverse engineering of the dump resolves the call stack back to a specific C function in pdlrt.exe, which is the only reliable way to confirm a binary bug versus a project bug. Always collect the dumps before applying Update 7 if you intend to escalate, because the update overwrites the binary and the stack frames become impossible to map against the original faulting module version.

Preventive Maintenance Checklist

• Keep WinCC within one major version across the entire project. Mixing V7.0 SP3 with V7.2 on a server-client pair is unsupported and can reproduce the crash on the older node.
• Run a script lint pass (Start → Programs → Siemens Automation → WinCC → Tools → Script Diagnostics) before every project release.
• Restrict the Siemens\WinCC directory ACL to administrators; a non-admin user overwriting an OCX or a DLL can reproduce the ntdll.dll symptom even when the binary is technically valid.
• Schedule a weekly rotation of the Diagnose folder; a full disk on the diagnostics volume is a known way for the dump writer to silently fail and mask a real crash with a generic exit.
• Document the exact Update level of every installation in the project handover package. Field experience shows that 70 percent of repeat crashes are caused by stations that quietly fall behind on cumulative updates after a backup restore.

Troubleshooting Matrix

Verification Steps

1. After applying the update or project fix, run the WinCC project for 48 hours continuously with simulated operator activity (picture changes, alarm acknowledgements, recipe loads).
2. Confirm zero new lines in PDLRTESH.log containing the substring [EXCEPTION].
3. Confirm zero new Event ID 1000 entries for pdlrt.exe in the Windows Application log.
4. Run CCDiagnostics.exe and verify the report status is green for all categories: Communication, Tags, Scripts, and Pictures.
5. Perform a controlled power loss (UPS-triggered shutdown) and confirm that the runtime restarts cleanly without a new unhandled exception during initialization.

FAQ