Troubleshooting WinCC V7 Server-Client Communication

Problem Definition

WinCC V7.0 SP3 server-client architectures occasionally exhibit a class of fault where the WinCC Client loses its runtime connection to the WinCC Server, even though the physical LAN remains reachable. The classic symptom set is:

• Server-to-PLC connection (Ethernet, S7 protocol) remains Established; tag values continue to update on the server.
• Client shows Established connection to server in the Server Status dialog, but the runtime canvas reports Disconnected.
• No modal WinCC error popup appears on the client or server.
• ICMP ping (Ping) from client to server succeeds throughout the fault window.
• Disconnection appears random in time; no operator action correlates with the drop.
• Migrating the server project to a different PC eliminates the fault entirely.

The last bullet is the strongest diagnostic signal that the fault is localised to the original server hardware/software stack, not to the network or to the client image. This article documents the engineering workflow used to isolate that class of failure.

WinCC V7 Server-Client Communication Model

WinCC V7 uses a distributed architecture where the server holds the data manager, the archive database, the alarm logging, and the tag connection(s) to the PLC. Clients are pure HMI viewers; they do not own PLC connections of their own in a standard server-client configuration.

The client-server handshake uses a port negotiation that depends on the WinCC Server service and the DCom service control manager on the server host. If any of these underlying services restart, time out, or hit a per-process resource limit, the client runtime will display Disconnected without a visible fault popup.

Network Topology Under Test

The reported topology was:

• PLC (S7-300/400 or S7-1200/1500) on Industrial Ethernet.
• WinCC Server PC connected to the PLC via Ethernet.
• WinCC Client PC connected to the server via the same Ethernet segment, with a SCALANCE switch (e.g., SCALANCE X-200, XB-200, or XC-200) acting as the central node.
• All devices on a single /24 (or larger) subnet; no router in the path between server and client.

Because the ping succeeds during the fault, Layer 1 (cable, port LED, link speed) and Layer 2 (MAC learning, switch forwarding, VLAN) are operationally healthy at the moment of the fault. The fault therefore resides at:

1. Layer 3+ on the server host (TCP socket state, WinCC process state, service health).
2. The WinCC application-layer connection state above TCP.

Root Cause Categories

From the symptom pattern - random client disconnects, server-PLC stays up, no popup, resolved by changing server PC - the candidate root causes rank as follows:

The fact that moving the server project to a different PC resolved the issue is a strong indicator that the root cause is one of the first four (host-local). The PLC and the network are exonerated because they were not changed. The client was not changed. Only the server host changed. Therefore the server host's hardware/OS/WinCC service stack was the fault domain.

Diagnostic File Locations and Interpretation

WinCC V7 stores rich diagnostic data that survives the runtime. The primary locations are:

C:\Program Files\Siemens\Automation\WinCC\Diagnose\
C:\Program Files (x86)\Siemens\Automation\WinCC\Diagnose\   (32-bit WinCC on 64-bit OS)

Within the Diagnose directory, the following files are produced and rotated by WinCC:

Open the most recent file and search for the exact time the client reported Disconnected. Look for any of the following strings:

Connection interrupted
Lost connection to server
DataManager stopped
Archive write failed
Service not responding
COM call failed (0x800...) 

If the log shows a normal server lifecycle and the client was the only thing that lost view, the cause is in the WinCC client-server RPC plumbing. If the log shows server-side exceptions, the cause is the server process itself.

Step-by-Step Troubleshooting Procedure

Prerequisites

• Administrator access to the WinCC Server PC.
• Read access to the SCALANCE switch (Web Based Management or TIA Portal).
• Wireshark (or similar) installed on both server and client.
• Reference to the WinCC V7.0 SP3 release notes and Microsoft KB for the OS build in use.

Step 1 - Correlate the Disconnect Timestamp

1. On the client, note the exact time the runtime went to Disconnected (visible in the status bar or in the WinCC Diagnose client log).
2. Open WinCC_Server_*.log in the server's Diagnose folder and search for the same timestamp plus/minus 60 seconds.
3. If a server-side event correlates, go to Step 2A. If nothing correlates, go to Step 2B.

Step 2A - Server-Side Event Found

The disconnect is caused by a server process fault. Common sequences:

• Archive write stall → the WinCC archive database (Microsoft SQL Server or the in-process archive engine) stops accepting writes. The server service stalls while waiting for I/O. The client times out on subscription RPC. Resolution: move the archive database to a dedicated drive with NTFS write cache disabled, check disk health with wmic diskdrive get status and S.M.A.R.T. via smartctl -a /dev/sda (Linux) or vendor tools (Windows).
• Data Manager exception → a tag, alarm, or script triggers a fault in the data manager process. Resolution: enable extended diagnostics, reproduce the fault, and patch the offending tag configuration.
• License re-acquisition → V7.0 SP3 has known issues with License Server re-validation. The archive of RTLicLog.txt shows cyclical re-acquisitions. Resolution: pin the License Server service to manual start, or move to V7.0 SP3 Update 13 or later where this was corrected.

Step 2B - No Server-Side Event

The disconnect is in the network path or in the server's TCP stack. Continue with Step 3.

Step 3 - Check the SCALANCE Switch Port Statistics

1. Open SCALANCE Web Based Management at https://<switch-ip>.
2. Navigate to Information > Port Statistics for the port the server is connected to.
3. Inspect the following counters during the fault window:

Per the Siemens SCALANCE X-200/XB-200/XC-200 Operating Instructions, port counters are cumulative since the last counter reset. Record them before the fault and after the fault. Any non-zero error counter that grows during the fault window implicates the server NIC, the patch cable, or the switch port.

Step 4 - Capture WinCC Traffic With Wireshark

1. Start a capture on both server and client with the display filter: port 2308 or port 2309 or port 102.
2. Wait for the next disconnect.
3. Stop the capture. Filter for tcp.stream segments between the two PCs.
4. Inspect for:

• TCP retransmits on the server's client-server stream but not on the server-PLC stream → server's outbound path to the client is impaired while the PLC path is healthy. Classic NIC or switch port fault.
• RST or FIN sent by the server but not the client → the server's WinCC process is closing the socket. Application-level fault.
• Keepalive timeout - if tcp.analysis.keep_alive shows repeated keepalives not answered, the server's TCP subsystem is not responding to the client. OS or driver stall.

Step 5 - Inspect the Server's Network Adapter

1. Open Device Manager > Network Adapters > Properties > Advanced.
2. Confirm Speed & Duplex is set to a fixed value (1 Gbps Full Duplex or 100 Mbps Full Duplex) - not Auto Negotiation if the SCALANCE port is fixed. Mismatched auto/fixed settings cause intermittent drops. See the Siemens FAQ on Auto Negotiation with SCALANCE.
3. Disable energy-efficient Ethernet (Green IT) and any "Energy Efficient Ethernet" or "Power Saving Mode" option on the NIC. These features have been known to cause link flaps on industrial PCs.
4. Update the NIC driver to the latest vendor release certified for the Windows version in use. For Intel NICs, reference the Intel Wired Ethernet driver package. For Realtek, reference the vendor site for the specific OEM.

Step 6 - Inspect Server Hardware Health

1. Open Reliability Monitor on the server. Look for clusters of hardware failures (disk, NIC, memory) around the fault time.
2. Run wmic memphysical get memoryerrorcorrection,totalphysicalmemory and mdsched.exe to schedule a memory test.
3. Run the manufacturer's disk diagnostic (SeaTools, Data Lifeguard, vendor UEFI diagnostics).
4. Check Event Viewer > System for Event ID 51 (disk), Event ID 1014 (DNS), Event ID 4227 (TCP/IP), Event ID 1011 (DCom). Any cluster of these around the fault time is the smoking gun.

Step 7 - Confirm By Swapping

If Steps 1-6 have not localised the fault, perform a controlled swap test:

• Move only the WinCC server project to a known-good PC (same OS build, same WinCC version, same service pack).
• If the fault disappears, the original server host is the fault domain. Proceed to isolate which subsystem (NIC, disk, RAM, OS) by binary swap.
• If the fault persists, the project itself is the fault domain - proceed to Step 8.

Step 8 - Project-Level Fault Isolation

1. Open the WinCC project in the WinCC Explorer on the new server.
2. Disable non-essential scripts and check the runtime.
3. Re-enable in small groups until the fault returns.
4. Inspect the tag manager for tags with bad configuration (e.g., wrong S7 address, bad conversion).
5. Check the Alarm Logging configuration for routing rules that point to non-existent clients.
6. Cross-reference the symptom against the Siemens WinCC V7.0 SP3 Release Notes / Readme for known issues fixed in later updates.

SCALANCE Switch Considerations

SCALANCE X-series switches are industrial-managed switches with several features that, when misconfigured, can selectively break the client-server path while leaving the PLC path intact:

Reference the Siemens SCALANCE X Configuration Manual for the exact CLI and WBM navigation to adjust these features.

Server-Side WinCC Service Architecture

Understanding the Windows services on which WinCC V7.0 SP3 depends clarifies why a host-local fault can manifest as a client disconnect with no server-PLC impact:

The CCMsgServer service is the most common culprit in the reported scenario. If CCMsgServer crashes or becomes unresponsive on the server, the client cannot complete the WinCC message bus handshake. Ping works because the IP stack is healthy. The server-PLC connection continues because the S7 channel uses S7DOS, a different service, on its own socket.

Inspect service health with:

sc query CCMsgServer
sc query CCAgent
sc query CCDba
sc query S7DOS

Cross-reference with Event Viewer > Application for service stop events (Event ID 7036, 7034) around the fault time.

Verification Steps

After applying any fix, verify stability with the following protocol:

1. Restart both the WinCC Server runtime and all clients.
2. Confirm the client status shows Connected in the runtime status bar.
3. Trigger high-load activity: open multiple process screens, force a tag value change, generate an alarm.
4. Run a continuous ping from client to server for 24 hours, logging with: ping -t <server-ip> | tee ping.log. Verify zero loss.
5. Run a continuous archive read on the client for 24 hours, exporting a tag trend. Verify no gaps.
6. Inspect the server's NIC counters in Device Manager > Advanced > Statistics before and after 24 hours. Verify zero new CRC/fragment/discard counts.
7. Inspect the SCALANCE port counters before and after 24 hours. Verify zero growth in error counters.
8. Re-open the WinCC Diagnose files and verify no new exception traces, connection lost events, or service stop events.

Field-Proven Caveats Specific to WinCC V7.0 SP3

• WinCC V7.0 SP3 has a known issue with the License Server that causes brief re-acquisition cycles. This produces exactly the symptom described: a momentary client disconnect with no server-side fault. The fix is to upgrade to V7.0 SP3 Update 13 (or later) where the license handling was hardened. Reference: Siemens WinCC V7.0 SP3 Readme.
• WinCC V7.0 SP3 on Windows 7 SP1 and Windows Server 2008 R2 SP1 is sensitive to Windows updates that touch the DCom subsystem. Pin WinCC hosts to a tested OS image and apply only security updates after regression testing.
• Some Intel NIC drivers (e.g., i217, i218, i219 families) had stability issues in early driver versions that produced intermittent link flaps. Always install the OEM-certified driver from the IPC manufacturer (Siemens, Advantech, Beckhoff) rather than the generic Intel driver.
• The Windows Firewall on the server may silently start blocking the WinCC client-server ports (TCP 2308, 2309) after a Windows Update. The firewall state can change without an obvious notification. Verify with: netsh advfirewall show allprofiles.
• The SQL Server used by WinCC for archiving can be auto-paused by the SQL Server service if it is configured for "Auto-close" or runs out of memory. Disable auto-close and cap the SQL Server memory so it does not contend with the WinCC services.

When the Reported Fix (Moving the Server) Is the Right Answer

If the troubleshooting protocol above localises the fault to the original server host's hardware (NIC, disk, RAM, motherboard) or to a non-reproducible OS-level fault (driver, registry, DCom), the most efficient path is exactly what the field engineer did: redeploy the project to a known-good host. This is the correct engineering decision when:

• The fault is intermittent and has caused production losses.
• The diagnostic window has expired (the fault is no longer reproducible on demand).
• Hardware swap-in of the suspected subsystem (NIC, disk) is operationally disruptive.
• The replacement host is from the same WinCC compatibility list as the original.

Document the original host's hardware, OS, driver, BIOS, and WinCC versions. Quarantine the original host for offline root-cause analysis. The data recovered from the quarantine host often reveals the exact subsystem that was failing.

Preventive Recommendations

1. Maintain a hardware refresh cycle for WinCC server hosts. Industrial PCs with 24/7 runtime accumulate NIC and disk failures over time.
2. Use SCALANCE switch port error counters as a leading indicator. Set up SCALANCE SNMP traps for any non-zero error counter on a WinCC server port. Reference: SCALANCE SNMP Configuration.
3. Schedule periodic review of the WinCC Diagnose folder. Archive the logs to a network share so historical correlation is possible.
4. Run the WinCC Server in a virtual machine (Hyper-V, VMware) where VM-level hardware abstraction can isolate host hardware faults from the WinCC application stack.
5. Maintain a documented baseline of NIC driver, BIOS, and Windows Update level. Any change to the baseline must be regression-tested before production deployment.
6. Configure the Windows Event Viewer to forward WinCC and hardware events to a central SIEM or to the SCADA historian for cross-correlation with process disturbances.

FAQ