PCS 7 OS Client Hang: Resolving WinCC Event 257 Memory Leak

Problem Overview

On a Siemens PCS 7 v8.1 SP1 OS Client station running Windows 7, the operator interface intermittently freezes every 2-3 days. The recovery is limited to a full Windows restart, after which runtime resumes normally. The system is configured with redundant OS Servers, seven OS Clients, one Engineering Station (ES), and a Process Historian (PH) Redundancy server.

The Windows Application log on the affected client shows WinCC Event 257 being raised approximately every two seconds:

Event ID: 257
Source: RedundancyControl
Description: "No RedundancyControl started, but all other conditions are set."

Despite the constant event, the WinCC diagnostics and OS Client runtime diagnostics show no internal fault at the time of the hang, and the OS Server pair continues to operate without error. This pattern strongly suggests a client-side resource exhaustion problem interacting with the WinCC redundancy state machine.

Affected System Architecture

PCS 7 V8.1 ships with WinCC 7.3 as the runtime engine. OS Clients in V8.1 connect to the OS Server pair through the standard WinCC channel and participate in redundancy state evaluation so that an automatic failover can update the operator display. The state evaluation is performed locally on every client by the RedundancyControl.exe process.

Root Cause Analysis

Why Event 257 Fires Every Two Seconds

Event 257 originates from the RedundancyControl application on the OS Client. WinCC evaluates three preconditions on a client to determine if it should accept a redundant partner state:

1. The configured preferred server is reachable.
2. The WinCC Runtime on the client is started and licensed.
3. The RedundancyControl on the client is started and bound to the configured server pair.

When conditions 1 and 2 are true but condition 3 is not, the message "No RedundancyControl started, but all other conditions are set" is logged. In a normally running PCS 7 OS Client, condition 3 should always be satisfied; therefore, the event normally appears only at startup and is cleared within a few seconds once the redundancy handshake completes.

When the event recurs every two seconds, the OS Client's runtime is in a degraded state: the WinCC picture tree, alarm pipeline, or C/VBS script layer is consuming resources to a point where the RedundancyControl cannot complete its handshake, and the condition is re-evaluated on every watchdog tick. The most common resource stress documented on PCS 7 V8.1 clients is a managed memory leak in the WinCC Runtime process (CCExpMgr.exe or PDLrt.exe depending on the client configuration), which grows working set monotonically until the process can no longer service the redundancy heartbeat.

Contributing Factor 1: Windows Regional and Language Settings

PCS 7 V8.1 SP1 supports only a defined set of Windows system locales on runtime stations. Languages outside this set, or locales that are installed but not switched to active, can cause VBS and C scripts to instantiate culture-specific formatting objects (date, decimal separator, currency) on every script call. The cumulative effect is both a memory growth and CPU pressure that surfaces as an Event 257 storm before the process actually crashes.

Siemens releases the following languages for PCS 7 V8.1: English (United States), German (Germany), French (France), Italian, Spanish, Chinese (Simplified, PRC), Japanese, Korean, and a small set of additional European languages depending on the installed MUI package. Any other locale - even one that ships with Windows 7 - is not released for runtime use and can produce the symptoms described.

Contributing Factor 2: PC Station Equalization

PCS 7 requires the same language, same locale, same code page, and same regional options on every station that participates in the OS Server-Client relationship. The diagnostic step in this article includes a verification matrix of all PC stations to confirm they are equalized.

Contributing Factor 3: Script-Driven Memory Leaks

Common memory leaks in PCS 7 OS Client runtime include:

• Unreleased COM object references in C scripts that wrap WinCC OLE Automation calls (e.g. DM_VAR, DM_AC).
• MScript/VBS routines that allocate picture objects without destroying them when a picture is closed.
• Custom ActiveX controls embedded in process pictures that do not implement IDispatch reference counting.
• Frequent picture-tree navigation with deep sub-tree depth that is not unloaded on close.

Diagnostic Procedure

Step 1 - Capture the Windows Application Event Sequence

1. Open Event Viewer on the affected OS Client.
2. Expand Windows Logs → Application.
3. Filter the log for Event ID 257 from source RedundancyControl and Event ID 1xxx from source WinCC.
4. Export the events covering the last 7 days to an .evtx file.
5. Confirm that the Event 257 cadence is two seconds and starts well before the visible hang (often 12-24 hours before).

If the events are not present, the issue is not on this client; redirect the investigation to the OS Server pair or the network path.

Step 2 - Capture Working Set Trend with Performance Monitor

Use Windows Reliability and Performance Monitor (perfmon.msc) to record the memory consumption of the WinCC processes over time.

1. Start a new Data Collector Set with the counters below.
2. Run the trace for at least 5 days, or for the full interval between two known hangs.
3. Export the .blg to CSV for analysis.

Step 3 - Verify Windows Regional and Language Settings

1. Open Control Panel → Region and Language (Windows 7).
2. On the Formats tab, set Format to a PCS 7-released language, for example English (United States).
3. On the Location tab, set the current location to a matching country.
4. On the Keyboards and Languages tab:
   • Confirm Display language matches a PCS 7-released MUI.
   • Remove any secondary installed language packs not used by the project.
5. Click Administrative → Change system locale and confirm the same locale.
6. Reboot the client and re-verify that WinCC Event 257 no longer appears at boot.

Step 4 - Equalize All PC Stations

Use the following matrix to verify every OS Server, OS Client, and ES in the system carries the same Windows configuration:

Step 5 - Inspect the WinCC Project for Script Leaks

1. On the Engineering Station, open the WinCC Explorer of the OS Client project.
2. Open Computer → Properties → Graphics Runtime and confirm Runtime language matches the Windows display language.
3. Open the C and VBS editor for the OS Client and search for the leak-prone patterns below.
4. Open Options → Settings → Graphics Runtime and confirm the picture tree caching settings match the system design.

Memory Leak Hunt: Common Code Patterns

The following patterns are known to leak memory in PCS 7 V8.1 SP1 OS Client runtime. Each should be reviewed and corrected in the C and VBS project on the ES.

Pattern 1 - Unreleased DM Object References (C)

// LEAK: DM object assigned, never released
DM_VAR_VARIANT dm;
dm.lpcszName = "Tag1";
DM_VAR_GET(&dm); // returns handle, never released

Corrected form:

DM_VAR_VARIANT dm;
memset(&dm, 0, sizeof(dm));
dm.lpcszName = "Tag1";
DM_VAR_GET(&dm);
// ... use dm ...
DM_VAR_RELEASE(&dm); // explicit release

Pattern 2 - Picture Object Created in Hot-Key Handler (VBS)

' LEAK: object is created, used, and dropped without Disconnect
Sub OnBtnOpenTrend(szPictureName, szObjectName)
    Dim obj
    Set obj = ScreenItems("WinCC Online Trend Control")
    obj.Online = True
    ' no Disconnect / no Set obj = Nothing
End Sub

Corrected form:

Sub OnBtnOpenTrend(szPictureName, szObjectName)
    Dim obj
    Set obj = ScreenItems("WinCC Online Trend Control")
    obj.Online = True
    obj.Connect()
    ' ... work ...
    obj.Disconnect()
    Set obj = Nothing
End Sub

Pattern 3 - Picture Tree Without Unload on Close

If the OS Client uses a picture tree that is built dynamically (typical when adding new areas), each navigation must explicitly call UnloadPicture on the previous level. Failure to unload will hold the old picture's WinCC object space in memory for the life of the runtime session, producing a slow growth that takes 2-3 days to crash the process.

Solution

Fix 1 - Restore Released Locale

1. Set the system locale to a PCS 7-released language (English-US, German, French, Italian, Spanish, Chinese, Japanese, or Korean).
2. Set the user locale and the input language to the same value.
3. Reboot the client.
4. Confirm that WinCC Event 257 no longer fires at boot.

Fix 2 - Remove the Memory Leak Source

1. On the ES, open the OS Client project and apply the corrected patterns above for every C and VBS routine that wraps a WinCC object.
2. Add a project-level discipline: every GetObject in VBS has a matching Set obj = Nothing in the same scope; every DM_VAR_GET in C has a matching DM_VAR_RELEASE.
3. Recompile the OS Client and download to the runtime client.
4. Restart WinCC Runtime on the client only (no full Windows reboot required for the test).

Fix 3 - Patch PCS 7 V8.1 SP1 to Current Hotfix Level

Several memory-related fixes for WinCC 7.3 / PCS 7 V8.1 were delivered as hotfixes beyond SP1. Apply the cumulative WinCC/PCS 7 V8.1 hotfix package on the ES, then download to all OS Servers and OS Clients during the next planned outage.

Fix 4 - Add Memory Watchdog

Until the leak source is removed, deploy a watchdog script on the OS Client to log the working set of CCExpMgr.exe every 30 minutes to a CSV file on a network share. If the working set crosses 1.5 GB on a 4 GB client, the watchdog writes a Windows Task Scheduler trigger that restarts the WinCC Runtime service. This converts a hard hang into a controlled runtime restart and protects the plant from operator-screen unavailability windows of more than 90 seconds.

Verification

1. Event Viewer: After applying the locale fix and patch, confirm that Event 257 from RedundancyControl does not appear at boot or during a 7-day observation window.
2. Performance Monitor: Working set of CCExpMgr and PDLrt should remain within ±10% of the value at runtime start. Confirm via a 7-day data collector set.
3. Operator confirmation: No spontaneous OS Client hang over a 14-day production period.
4. Redundancy test: Force-failover the primary OS Server to the standby; confirm that all seven OS Clients switch to the standby within the configured timeout (default 30 seconds in PCS 7 V8.1) and that no client hangs on the failover event.
5. Locale audit: Print the Regional Options screen from every PC station and store in the plant documentation; this satisfies quality audits and proves equalization.

Troubleshooting Matrix

Preventive Maintenance

• Standardize the OS Client image. Use a single Windows 7 SP1 image with the released locale locked, a single admin user name, and the same hotfix level. Image the client to a recovery partition for fast swap-in.
• Exclude C:\Program Files (x86)\Siemens\Automation\WinCC\ and C:\ProgramData\Siemens\Automation\ from antivirus real-time scanning.
• Set the Windows pagefile to 8 GB minimum on every client, system-managed size. WinCC uses the pagefile aggressively for tag logging; restricting it can cause Event 257 storms on clients with limited RAM.
• Run a quarterly Performance Monitor trace and review the working set trend for every OS Client. Investigate any client whose working set grows more than 2 MB/hour on average.
• Maintain a project-level coding standard for VBS and C that mandates explicit object release, and run a code review on every change to the OS Client dataset before download.

Related Siemens Manuals and References

For deeper background and official configuration, consult the PCS 7 V8.1 documentation set available on the Siemens Industry Online Support portal:

• PCS 7 V8.1 Operating Instructions - WinCC V7.3: Configuration of OS Clients and Redundancy
• PCS 7 V8.1 PC Configuration Manual - Released Languages and PC Station Equalization
• WinCC V7.3 Information System - Redundancy Diagnostics and Event 257
• SIMATIC PCS 7 V8.1 SP1 Readme - Released Windows 7 / Server 2008 R2 locales and service packs
• Siemens KB entry 109751005 - "OS Client shows Event 257 and stops responding"