Troubleshooting WinCC V6.0 SP4 Server/Client Runtime Freezes

Random runtime freezes on a WinCC V6.0 SP4 Server/Client configuration typically present as a single client (or the server) stalling for tens of seconds while counters continue incrementing. Screens fail to load, the Graphics Runtime stops repainting, and the operator must exit Runtime and close WinCC Explorer to recover. The companion server (or the other clients) may continue serving requests, or may itself appear to "freeze" for roughly 60 seconds before returning to normal. The most common root causes documented in V6.0 SP4 deployments are: (1) ActionOverflow on the script engine when a C/B- or VBS-action enters a tight loop, (2) illegal tag addresses being polled continuously by an action, (3) Ethernet physical-layer faults (intermittent cable breaks, marginal RJ-45 crimps, USB-hub keyboard/mouse chatter on a client), and (4) a known runtime behavior internally referred to as slinkysearch that affects picture-cache lookup. This article consolidates the diagnostic workflow, the exact log signatures, and the verified remediation steps.

1. Symptom Matrix: Server vs. Client Behavior

Before chasing the cause, classify the freeze. WinCC V6.0 SP4 freeze behavior is not symmetric between server and client roles because the picture cache, tag subscription, and script execution models differ.

2. Required Diagnostic Artifacts

Collect the following from every affected machine before restarting Runtime. They form the evidence trail for a single-ticket resolution.

1. WinCC Diagnostics folder — <ProjectPath>\Diagnostics\*.log from the affected server and client. Includes WinCC_Sys_<date>.log, WinCC_Script_<date>.log, and connection logs.
2. APDiag / ODBC trace — tag polling history for the suspected illegal address (e.g., C-210_YA_1200A.Value).
3. Windows Event Viewer — System and Application logs filtered for the freeze timestamp; look for source WinCC, S7DOS, CCAgent, and NDIS / TCPIP warnings.
4. Network capture — short Wireshark or netsh trace capture on the server NIC during the next freeze (mirror the port or use a hub).
5. Process dump — procdump -ma CCExplorer.exe or Task Manager → Create Dump File when Runtime hangs.
6. Ping and tracert results from the affected client to the server, to each PLC (S7-300/400/1200/1500), and to the switch management IP.

3. Reading the WinCC Diagnostics Log

WinCC V6.0 SP4 writes messages with a fixed numeric prefix. The four signatures below account for the majority of random-freeze tickets.

4. ActionOverflow — Root Cause and Resolution

4.1 Why 5000 actions matter

Each WinCC action (C script, VBS, or global action) is dispatched onto a Windows thread pool. WinCC maintains a FIFO queue with a hard cap of 5000 pending actions. When an action is triggered but blocks — for example, by a synchronous MS_HMIRuntime.Tags read on a dead connection, a Wait on a synchronizing object, an external COM call, or a tight For loop with no DoEvents — every subsequent trigger piles up. Once the cap is reached, 1007000 ActionOverflow is logged and UnLoadFctAll tears the whole script set down. The Graphics Runtime then has to reload the picture and reinitialize the script engine, producing a visible 30–90 s "freeze."

4.2 Verifying the queue depth in real time

On the affected server or client, open WinCC Explorer → Tools → Status of Actions (or call the internal API PDLRTGetActionsStatus). The current queue length and longest-waiting action are displayed. Values approaching 1000 sustained, or any single action with > 5 s wait, are a leading indicator of an imminent ActionOverflow.

4.3 Common coding patterns that cause ActionOverflow

4.4 The "nCount 359" interpretation

When you see UnLoadFctAll nCount 359 in the log, the nCount value is the number of action objects forcibly unloaded. A non-trivial nCount immediately preceding a 1007000 confirms the unload was triggered by the overflow, not by a clean project stop. The exact number can also be cross-referenced to the number of configured actions in the picture to find the one that was missing from the unload set (i.e., the one that didn't return from its last call).

5. Illegal Tag Address Errors

The log line ERROR Illegal tag address "C-210_YA_1200A.Value"! indicates the action framework evaluated a tag reference for which WinCC cannot find a matching internal tag definition. The reference is to a tag in a user-defined structure (UDS) or a connection-prefixed address. The three things to verify:

1. Structure element exists: Open the tag in WinCC Tag Management and confirm that C-210_YA_1200A is the full tag name and that the structure element is a member, not a sub-structure. The .Value suffix is added by the runtime; you do not type it in the script.
2. Connection is online: The PLC may be online, but the S7 connection used to read this tag may be a different one. Cross-check Tag Management → [Connection] → Properties → Connection Name against the project's connection list.
3. Type compatibility: An action trying to assign a string to a numeric tag, or to call .Value on a raw bit, will throw this. Use .Read with type checking, or address the tag directly as a SmartTag.

6. Network Integrity Verification

6.1 Ping baseline

Run the following from each WinCC machine:

ping -n 100 -l 1024 <ServerIP>
ping -n 100 -l 1024 <PLC1IP>
ping -n 100 -l 1024 <PLC2IP>
ping -n 100 -l 1024 <SwitchMgmtIP>

Acceptable values for V6.0 SP4 are:

Anything above this, or any non-zero loss, indicates a Layer-1 or Layer-2 issue that masquerades as a WinCC freeze because the Graphics Runtime's tag subscription times out and the picture cannot be repainted.

6.2 tracert usage in a flat plant LAN

If the affected machine is in the same subnet as the destination, tracert will normally return only a single hop (the destination itself), because Windows routers do not decrement TTL on a same-subnet delivery. The diagnostic value of tracert on a WinCC client is therefore limited to confirming routing topology, not detecting cable faults. Use it to verify the path traverses no more than two routers:

More than two hops in a plant LAN usually means a misconfigured gateway or a rogue device acting as a router.

6.3 Physical-layer checks

A broken or marginal Ethernet cable between the WinCC server and the core switch will produce a freeze on all clients simultaneously while the server's local graphics continue to update. This is the most commonly reported cause of "all clients freeze" tickets. The two practical checks are:

1. Swap the suspected patch cable for a known-good CAT5e or CAT6 cable, observing 100 Mbit/s or 1 Gbit/s link LED on both ends.
2. Use a cable tester (Fluke MicroScanner or equivalent) to verify all eight conductors pass continuity and the pair-to-pair resistance is < 0.5 Ω on each pair.

USB-hub-attached peripherals on a WinCC client have also been reported to cause local freezes. Eliminate the hub as a variable by moving the keyboard and mouse to direct PS/2 (via an active PS/2-to-USB adapter only if the motherboard has PS/2 ports) or to direct USB ports on the client. The original ticket that prompted this article was resolved by replacing the USB hub with PS/2 extensions.

7. The "SlinkySearch" Behavior

Slinkysearch is the colloquial name used by Siemens development for the picture-cache lookup algorithm in the V6.0 SP4 picture window subsystem. Under specific conditions — typically when a base picture contains hundreds of faceplates or dynamic dialogs and a hot-key navigates through several picture windows in rapid succession — the cache traversal exceeds the watchdog budget and the runtime pauses for several seconds. A pre-SP4 hotfix was eventually distributed to address this; on SP4 deployments, the workaround is to reduce the number of nested picture windows per base picture, to keep faceplate instances < 200 per picture, and to disable the picture cache for navigation-heavy screens.

7.1 Disabling the picture cache per picture

1. Open the affected picture in Graphics Designer.
2. Right-click the picture window → Properties.
3. Clear Cache after leaving the picture.
4. Set Update to On change rather than On Show if the picture does not need to be repainted on every navigation.

Disabling the cache increases picture-open time but eliminates the slinkysearch pause, which is an acceptable trade-off in operator-HMI applications where correctness beats load time.

8. Step-by-Step Resolution Procedure

Follow this sequence in order. Do not skip steps; each gates the next.

1. Capture the freeze. When the next freeze occurs, immediately Task Manager → right-click CCExplorer.exe → Create Dump File. Also click Take Stack Trace if you have procdump installed.
2. Grep the diagnostics folder. findstr /S /I "1007000 Illegal ActionOverflow Deactivation" "C:\<Project>\Diagnostics\*.log"
3. If 1007000 is present: identify the looping action (Section 4.3) and fix per the table. Re-test.
4. If only "Illegal tag address" is present: fix the tag reference (Section 5) and re-test.
5. If neither is present: run the network integrity checks (Section 6). Replace the server-to-switch patch cable first; it is the cheapest fix and the most common cause of multi-client freezes.
6. If the problem is single-client only: check the local USB hub, replace the keyboard/mouse with PS/2 or direct USB, update the video driver, and disable the picture cache on heavily nested picture windows (Section 7).
7. Re-test with logging enabled: WinCC Explorer → Computer → Properties → Graphics Runtime → Activate Diagnostics. Reproduce the scenario three times.
8. If the freeze persists: open a Siemens support ticket referencing the dump, the log, the network capture, and the action names suspected.

9. Verification Checklist

Use this checklist to confirm a permanent fix. Every item must be green for 72 continuous hours of production operation.

10. Common Pitfalls

• Restarting the server is not a fix. The ActionOverflow will re-occur on the next triggering event. Always fix the action, not the symptom.
• Increasing the 5000-action cap is not supported. WinCC V6.0 SP4 has a fixed internal queue; the only knob is the action's own trigger frequency and execution time.
• Tracert is not a cable tester. A passing tracert proves only that routing is configured correctly; it does not detect a marginal pair or a broken shield.
• Ignoring "Deactivation : Action was stopped by script". This is a warning, not an error, but it indicates a script is killing peer actions, which is almost always the signature of a poorly written watchdog.
• Tuning tag logging/archiving times to a lower value is not a WinCC freeze remedy. It changes the archive load, not the script queue depth. It is useful only when the freeze is correlated with archive writer blocking the main thread.

11. When to Escalate

Escalate to Siemens Technical Support with the dump and logs when any of the following is true:

• No 1007000, no illegal tag address, network is clean, and the freeze still occurs.
• The freeze coincides with a specific picture change that includes a slinkysearch pattern.
• The dump shows the main thread blocked in WaitForSingleObject on a non-script handle (an S7DOS read against an offline CP).
• Multiple V6.0 SP4 sites report the identical pattern; this is a candidate for a Siemens Hotfix request.

For the authoritative reference, consult the Siemens Industry Online Support entry for WinCC V6.0 SP4 and the WinCC V6.0 SP4 Service Pack Release Notes. For S7 connection diagnostics, the S7DOS / S7 Communication Diagnostics Manual describes the trace log fields that appear in the same diagnostics folder. Tag configuration details for V6.x are in the WinCC Information System under Tag Management → Internal Tags / External Tags.

FAQ