Resolving WinCC V6 CCEServer CONNECT FAILED Log Entry

1. Problem Description

A Siemens WinCC V6 SP2 server (running on Windows 2000 Server SP4 with Windows 2000 SP4 workstations) generates a recurring entry in the runtime log file cceserver_sys_01.log:

date time 00000000-0000-0000-0000-00000000000 ((null)) CONNECT FAILED

Observed behavior:

• The entry repeats every 10 seconds continuously from the moment the WinCC runtime starts until the runtime is closed.
• The message appears regardless of whether any client workstations are connected.
• The message appears with no print jobs open and with no user-driven activity.
• All other log files in the WinCC diagnostic set are clean.
• Siemens APDiagnose reports no fault.
• VBScript graphics and script debugging are enabled but yield no script-level clues.
• The HMI runtime, alarm logging, tag logging, and operator screens function normally — only the log entry is anomalous.

2. CCEServer Process Architecture in WinCC V6

CCEServer is the Windows service that brokers client/server communication for the WinCC V6 runtime layer. It is also responsible for publishing the server in the Windows Explorer SIMATIC Shell folder so that WinCC Explorer, clients, and configurator tools can locate the project.

Default log location on the server:

C:\Program Files\Siemens\WinCC\diagnose\

The 10-second cadence is the CCEServer client polling interval. Each cycle, CCEServer probes the configured transport. If the probe cannot complete, the diagnostic logger records CONNECT FAILED against a NULL GUID (00000000-0000-0000-0000-00000000000), which represents a system-level socket rather than a project object.

3. Log Entry Decoding

Because the GUID is null and the user is null, the issue is at the CCEServer transport layer (TCP/DCOM), not at the WinCC project layer (graphics, scripts, archives).

4. Root Cause Analysis

For WinCC V6 SP2 on Windows 2000, the documented causes of repeated CONNECT FAILED entries in cceserver_sys_01.log cluster into four families:

1. Network interface mis-selection — CCEServer binds to the wrong NIC (e.g., a disabled or virtual NIC, or a NIC without a route to the configured subnet).
2. Auto-negotiation mismatch — NIC set to Auto Detect speed/duplex; the negotiated value does not match the switch port, causing the socket to flap.
3. SIMATIC Shell not bound to the production NIC — the published computer name resolves to an IP that is not reachable from clients.
4. Corrupted CCEServer autostart registration — service starts before the network stack is fully ready (Windows 2000 only).

5. Pre-Diagnostic Checklist

Run these checks before any configuration change. They establish a baseline and rule out environment-level issues that look like CCEServer problems.

1. Network connectivity from the server to itself and to at least one client:

   ping 127.0.0.1
   ping <server_static_ip>
   ping <client_static_ip>

2. Confirm static IPs are assigned on both the server and all workstations. DHCP is not supported for the WinCC V6 server's primary network adapter in production.
3. Disable unused NICs in Device Manager → Network Adapters. Multi-NIC servers should run with exactly one active production NIC.
4. Verify Windows networking is installed and that File and Printer Sharing for Microsoft Networks and Client for Microsoft Networks are bound to the production NIC only.
5. Verify DNS / WINS resolution of the server's hostname from a client. If the client resolves the name to the wrong IP, the SIMATIC Shell publish point is wrong.
6. Check Windows Event Log (System and Application) for DCOM, WinSock, or DHCP errors at the time of the CCEServer probe.

6. SIMATIC Shell Configuration Editor

The SIMATIC Shell configuration editor is the primary control point for which NIC and which IP CCEServer uses to publish the server.

1. On the server, open Windows Explorer.
2. Locate the SIMATIC Shell folder (it appears as a virtual folder in My Network Places / Network Neighborhood).
3. Right-click the computer name representing the local server and choose Configuration.
4. In the editor, confirm the following:

   Field	Required value
   Network card selected	The single production NIC only.
   IP address	The static IP assigned to that NIC.
   Computer name	Matches HKLM\System\CurrentControlSet\Control\ComputerName\ComputerName.

5. Click OK to apply.

If the field is empty, grayed, or showing a non-production NIC, the CCEServer probe will resolve to a dead socket and the 10-second CONNECT FAILED log entry will follow.

7. Network Card Advanced Settings

Auto-negotiation is the single most common cause of intermittent WinCC V6 socket failures on Windows 2000. Hard-code the NIC to match the switch port.

1. Open Device Manager → Network Adapters → <production NIC> → Properties → Advanced.
2. Set the following properties to fixed values (do not leave on Auto):

   Property	Recommended value
   Speed & Duplex	100 Mbps Full Duplex (or 1000 Mbps Full Duplex for GbE)
   Wake on Magic Packet	Disabled
   Wake on pattern	Disabled
   Power Management → Allow this device to wake the computer	Disabled

3. On the switch port, hard-code the same speed/duplex. Auto on both ends is acceptable only when both are managed and have been verified.
4. Reboot the server after saving.

8. CCEServer Autostart Review

On Windows 2000, the CCEServer autostart entry can be left over from an older installation or an attempt to remove SIMATIC Shell. The service may then start before the network stack is ready, producing a continuous CONNECT FAILED heartbeat until the next reboot.

1. Open Control Panel → Administrative Tools → Computer Management → Services and Applications → Services.
2. Locate CCEServer (and SIMATIC WinCC Explorer if present).
3. Confirm Startup Type is Automatic and that the service is started after the Workstation and Server services.
4. If dependencies are missing, set them under the Dependencies tab of the service properties.
5. Stop and re-start the service. Watch cceserver_sys_01.log for the next 60 seconds.

If the autostart entry points to a path that no longer exists, fix the path or remove and recreate the service via:

sc delete CCEServer
sc create CCEServer binPath= "C:\Program Files\Siemens\WinCC\bin\CCEServer.exe" start= auto

9. Script and Autostart Project Items

Even though VBS debugging yields nothing for the 10-second entry, it is still good practice to rule out a project-level cause.

1. Open the WinCC project in WinCC Explorer.
2. Check Computer → Autostart: confirm only the standard WinCC runtime components are listed.
3. Check Graphics Designer for any scheduled C/VBS action running on a 10-second timer — these would appear in GS_<computername>.log, not cceserver_sys_01.log, so a clean GS_ log rules out a project script.
4. Disable any third-party OPC server or custom service that uses the same DCOM endpoint as CCEServer.

10. APDiagnose and Extended Diagnostics

If APDiagnose reports clean, run the deeper WinCC diagnostic toolchain before opening a support request.

1. WinCC Diagnosis Files — Start → Programs → SIMATIC → WinCC → Tools → WinCC Diagnosis. Bundle the .zip of all log files for the incident window.
2. DCOMCNFG — confirm the default DCOM authentication and access is set to Default and that the SYSTEM account has launch and activation rights for CCEServer.
3. Port check on the server. CCEServer uses DCOM dynamic ports (1024-65535). Confirm no firewall (Windows 2000 Filter Driver or third-party) is blocking the loopback or the local subnet.

netstat -an | findstr :135
netstat -an | findstr :<cceserver_port>

Port 135 (RPC endpoint mapper) must be listening and reachable locally for the CCEServer probe to succeed.

11. Escalation to Siemens Support

If Steps 5–10 do not clear the entry within one runtime cycle (≤10 s), escalate to Siemens Industrial Online Support with the following package:

• The full cceserver_sys_01.log showing at least 60 seconds of entries.
• Output of ipconfig /all from the server and one client.
• Output of netstat -an from the server during the runtime.
• Hard-coded speed/duplex screenshot of the production NIC.
• SIMATIC Shell configuration screenshot.
• WinCC version: V6.0 SP2 plus all installed hotfixes (check Add/Remove Programs → SIMATIC WinCC for the build number).
• Windows 2000 SP4 plus the most recent post-SP4 rollup (this matters; some rollups change Winsock behavior).

Reference Siemens entry ID 23337902 (WinCC V6 SP2 — CCEServer connectivity) and 21927374 (SIMATIC Shell — network card binding) when opening the ticket.

12. Verification Procedure

1. Close the WinCC runtime on the server.
2. Delete or rename cceserver_sys_01.log to start a fresh log window.
3. Apply one configuration change (for example, hard-code speed/duplex).
4. Reboot the server.
5. Start the WinCC runtime.
6. Wait 60 seconds with no clients connected.
7. Open the new cceserver_sys_01.log and confirm no CONNECT FAILED entries.
8. Connect a client, exercise a screen change, an alarm acknowledgment, and an archive read, and re-check the log.

A clean 60-second log window with no clients is the minimum acceptance criterion. A 24-hour clean log under full client load is the production acceptance criterion.

13. Prevention and Hardening Checklist

• Single production NIC, disabled all others.
• Static IP on the server and every client.
• NIC speed/duplex hard-coded on both ends (server NIC and switch port).
• SIMATIC Shell configuration editor pointing to the production NIC and IP.
• Windows 2000 post-SP4 rollup current.
• Server reboot scheduled at least monthly to clear stale DCOM endpoint mappings.
• WinCC V6 SP2 hotfix baseline applied (reference the Siemens WinCC V6 SP2 readme for the latest build).
• Daily cceserver_sys_01.log review as part of operator shift handover.