Resolving WinCC V7.0 SP3 Server Hang on Binary Tag Updates

Symptom: In a migrated WinCC V7.0 SP3 redundant server pair, the Graphics Designer and the runtime's dynamic-dialog expressions for digital (binary) tags freeze on the server, while analog tags, trends, and all client pictures continue updating. The runtime is alive (process pdlrt.exe responds to navigation), but button events tied to binary tags stop firing. The same project on a standalone OS runs without fault. The defect returns several days after each server restart. This article documents the root-cause path, the recommended Siemens corrective actions, and the verification procedure.

1. Problem Environment and Project Topology

The reported environment has the following characteristics that constrain the diagnostic path:

The asymmetric behavior — server wrong, client right — is the most important diagnostic clue. It eliminates the PLC, the field wiring, and the tag database itself as primary suspects, and points instead at server-side picture evaluation or the redundancy/event channel between the two WinCC servers.

2. Symptom Matrix

The pattern — partial picture evaluation failure on the server only, with full recovery on restart — is a classic signature of a handle or memory leak in the picture runtime DLLs of WinCC V7.0 SP3 base, which Siemens addressed in Update 8 for WinCC V7.0 SP3.

3. Root-Cause Hypotheses

Three independent root causes can produce this exact symptom family. Each must be eliminated in turn before a fix is committed.

3.1 Defect in the WinCC V7.0 SP3 base picture runtime

WinCC V7.0 SP3 (released in 2011) shipped with several picture-evaluation defects that surface only in migrated projects that use dynamic-dialog expressions with binary tags. The most prominent cluster was corrected in Update 8, available from the Siemens Industry Online Support portal.

Reference: WinCC V7.0 SP3 Update 8 — Siemens Entry ID 109741127.

3.2 Incomplete project migration from WinCC V6.2 to V7.0 SP3

When projects are migrated from V6.2 to V7.x, the V6.2 picture structure and tag aliases are translated. If the migration is interrupted, the database is partially upgraded, or the original V6.2 CDB/MCP files are mixed with V7 files, the server can resolve analog tags through the new channel but fail to re-evaluate binary expressions because of stale pointers in the picture DLL. The Siemens migration manual mandates the post-migration verification steps in chapter 5.8.

Reference: WinCC Upgrade V4/V7 — Migration Manual (PDF).

3.3 Corrupt or inconsistent DCF (Data Cache File)

The *.DCF file caches runtime data and is the file the picture engine reads to evaluate expressions. A DCF generated under V6.2 and used under V7, or a DCF written by a partially-installed service pack, can cause exactly the asymmetric behavior described: the tag is in the database, the client reads it through the redundancy path, but the server's local picture evaluation uses a stale pointer. Regenerating the DCF resolves this in many cases.

Reference: How to create a new DCF file in WinCC V7 — Siemens Entry ID 16749678.

4. Pre-Fix Information Gathering

Before applying any corrective action, capture the following state from the affected server. The data is required both to confirm the diagnosis and to validate the fix.

4.1 Process and handle snapshot

1. Open Task Manager → Processes, add the columns Handles, User Objects, GDI Objects, Private Bytes, Virtual Size.
2. Sort by Image Name and locate pdlrt.exe, CCArchiveConn.exe, CCAlgRtServer.exe, CCEServer.exe.
3. Record the handle count and Private Bytes for pdlrt.exe immediately after a server restart.
4. Repeat the snapshot every 4 hours. If the handle count climbs monotonically and the binary-tag freeze appears when the count exceeds a threshold (commonly observed between 20,000 and 60,000 handles in legacy V7.0 SP3 builds), the runtime is leaking GDI/USER handles. This confirms a picture-runtime defect addressed by Update 8.

4.2 Service-pack and hotfix inventory

1. On the server, open Control Panel → Programs and Features and list the installed WinCC components with exact build numbers.
2. The exact installed V7.0 SP3 update level is recorded in C:\Program Files (x86)\Siemens\Automation\WinCC\bin\WinCCVersion.txt or by reading the registry value HKLM\SOFTWARE\Wow6432Node\Siemens\Automation\WinCC\Version\UpdateLevel.
3. Compare the recorded update level against the Update 8 (or later) reference build listed in the Siemens entry referenced in section 3.1. If the server is below Update 8, proceed directly to section 5.1.

4.3 Migration integrity check

1. Open WinCC Explorer on the server. From the menu, choose Help → About and note the database schema version.
2. From the project root, inspect <Project>\wincc.opn with a text editor and confirm the Database version field is consistent on both redundant servers.
3. Cross-check that no file with a V6.2 timestamp (pre-2009) remains in the project tree.

5. Corrective Action Path

Apply the fixes in the order below. Stop after each step and verify; do not stack fixes without a controlled restart between them.

5.1 Install WinCC V7.0 SP3 Update 8 (or the latest available update)

Update 8 is the single most impactful corrective action for the symptom family described. It contains cumulative hotfixes for the picture runtime, the redundancy synchronization engine, and the dynamic-dialog expression evaluator.

1. Stop the WinCC runtime on both redundant servers: Start → Programs → Siemens Automation → WinCC → Stop WinCC Runtime. Verify pdlrt.exe has exited via Task Manager.
2. Close the WinCC Explorer and the Graphics Designer on the server.
3. Run the Update 8 installer with administrative credentials. The installer is a self-extracting executable; allow it to back up the existing bin and library folders.
4. Reboot the server.
5. Repeat on the partner server. Do not bring both servers online simultaneously until both have been updated and rebooted.

5.2 Validate the V6.2 → V7.0 SP3 migration

If the Update 8 install does not resolve the binary-tag freeze, the next step is to confirm the migration. The Siemens upgrade manual, chapter 5.8, lists the post-migration checks.

1. On the server, open WinCC Explorer and verify that every picture in Graphics Designer compiles without warnings. Warnings about unknown tag or type mismatch on binary tag are a red flag for an incomplete migration.
2. From the menu Tools → Cross Reference, search for binary tags used in dynamic-dialog expressions. Open each occurrence and confirm the Trigger column is set to the correct tag and update cycle (typically 1 s or 2 s). A blank or default trigger is a symptom of a corrupted V6.2 → V7 migration entry.
3. Open the migration log file <Project>\MigrationLog.txt. Resolve every WARNING and ERROR entry before proceeding.
4. If the migration log shows structural errors, perform a clean re-migration on a test bench from the original V6.2 source project, not from the previously-migrated V7.0 project.

5.3 Regenerate the DCF file

A stale or partially-overwritten DCF causes the picture engine to read inconsistent tag values for binary expressions while the channel driver — which reads directly from the tag manager — still serves correct values to the clients via the redundant path.

1. Close the WinCC Runtime and WinCC Explorer on the server.
2. Open the Windows service manager and stop the WinCC Runtime service.
3. Navigate to the project runtime folder, typically <Project>\<ServerName>\. Locate the files *.DCF, *.RT, and the binary PDLRT cache files.
4. Move (do not delete) the existing DCF file to a backup folder with a timestamp suffix.
5. Reopen WinCC Explorer. The system will detect the missing DCF and create a new one automatically. If a manual rebuild is required, follow the procedure in the Siemens KB article: Siemens Entry ID 16749678.
6. Start the runtime and monitor pdlrt.exe handle counts (section 4.1) for 24 to 72 hours.

6. Memory-Leak Diagnostic Procedure

If the freeze returns after Update 8 + DCF regeneration, the next investigation layer is a full memory and handle audit. WinCC V7.0 SP3 picture evaluation is a 32-bit process; the 2 GB user-space address limit is reached faster in migrated projects with many dynamic-dialog expressions.

6.1 4 GB large-address-aware tuning (optional, 64-bit OS only)

Windows Server 2008 R2 supports 4 GB for 32-bit processes when the binary is marked large-address-aware. WinCC V7.0 SP3 ships with the flag set in the pdlrt.exe image, but a clean Update 8 install is required for the flag to remain intact after patching.

1. Open an elevated command prompt.
2. Run editbin /LARGEADDRESSAWARE "C:\Program Files (x86)\Siemens\Automation\WinCC\bin\pdlrt.exe" (requires Visual Studio tools) or use the free SetLAA utility.
3. Reboot and observe the peak Private Bytes of pdlrt.exe over a 7-day window.

7. Redundant-Server Specific Considerations

The fact that the symptom appears on both redundant servers but not on the standalone OS is itself diagnostic. It rules out hardware differences and points to project-level artifacts that are loaded by every server but not by a standalone:

• Redundancy DLLs (ccredundsrv.dll and partners) — initialize additional event channels that the standalone machine does not load.
• Server-only picture scripts — scripts gated by @SERVER or by the redundancy master state.
• User archive synchronization — opens additional connections to the partner that the standalone never sees.

If the freeze correlates with a redundancy partner switchover, capture the Redundancy log file <Project>\<Server>\Redundancy\Redundancy.LOG. A growing list of WARN: lost connection to partner entries followed by rapid reconnects is associated with event-channel thrashing, which in turn can starve the picture evaluator and freeze binary-tag updates.

8. Step-by-Step Resolution Procedure

1. Schedule a maintenance window for both redundant servers. Do not attempt a hot fix; the runtime must be stopped.
2. Capture the pre-fix baseline per section 4.
3. Install WinCC V7.0 SP3 Update 8 (or the latest available hotfix rollup) on server A. Reboot. Repeat on server B.
4. Verify the migration per section 5.2. Resolve every WARNING in MigrationLog.txt.
5. Regenerate the DCF per section 5.3.
6. Recompile the project: in WinCC Explorer, right-click the server and select Rebuild all. Confirm zero compile errors.
7. Start the runtime on the master server first; allow it to reach the redundant state, then start the standby.
8. Run for 7 days. Monitor pdlrt.exe handle counts twice per shift. Compare to the pre-fix baseline.
9. Validate the client by clicking every binary-tag-driven button and confirming the server reflects the new value within the configured update cycle (typically 1 s).

9. Verification Checklist

10. When the Fix Does Not Hold

If the binary-tag freeze returns after the full procedure, escalate through the official Siemens support channel with the following package:

• The pre-fix and post-fix handle/Private-Bytes logs from Process Explorer.
• The complete WinCC\Diagnostics folder (enable with Apdiag.exe).
• The MigrationLog.txt showing zero warnings.
• Two screenshots, one from the server and one from the client, capturing the same picture at the moment of the freeze, with the time stamps visible in the Windows taskbar.
• The Computer.properties file from the project root.

This evidence package is the standard deliverable expected by Siemens WinCC support and is required for a hotfix escalation beyond Update 8.