Resolving WinCC V6.2 Activation Stuck at 77% on Dual-Core Systems

When Siemens WinCC V6.2 Runtime projects are deployed to a PC that uses a multi-core CPU, the project activation can hang indefinitely at the 77% progress milestone. The runtime is otherwise functional in simulation mode, the WinCC services are running, and a fresh OS install reproduces the same fault. This reference documents the root cause (an internal scheduling race condition between the WinCC event server and the multi-core kernel dispatcher), the official Siemens hotfix that resolves it (Entry ID 24740694), and a field-proven diagnostic and verification workflow.

1. Problem Description

The fault presents with the following repeatable pattern:

• Project is created in the WinCC Explorer and compiles without error.
• Project runs correctly in the integrated simulator (RT-simulator from the WinCC Explorer).
• On first or subsequent machine restarts, project activation is invoked manually or via auto-start. The progress bar reaches 77% and stalls.
• All listed WinCC services report Started in the services.msc console. Manually stopping and restarting individual services (e.g., CCProjectMgr, CCESvr) does not move the progress bar past 77%.
• Re-imaging the PC and re-loading the same project reproduces the hang. The project is not the cause; the host platform is.

The activation phase at which the fault occurs corresponds to the CCESvr (Central Component Event Server) registration handshake. At 77%, the Event Server has finished internal initialization and is attempting to register the configured data channels and alarms with the core WinCC services. The operation requires a deterministic thread-to-processor affinity that the multi-core scheduler does not honor in the unpatched V6.2 build.

2. Affected Versions and Platforms

3. Root Cause: Multi-Core Scheduling Race

WinCC V6.2 was engineered and validated against single-core Windows NT kernels. The CCESvr component (process CCESvr.exe, located under %ProgramFiles%\Siemens\Automation\WinCC\bin) is responsible for the central event routing between the data manager (CCDmPrc), the alarm logging service, and the picture objects loaded into Runtime.

On multi-core systems, Windows distributes CCESvr's worker threads across both logical processors. The internal initialization sequence of CCESvr contains a tight spin-then-yield loop that depends on monotonic single-processor scheduling. Under the multi-core kernel:

1. Thread A acquires the initialization mutex on CPU0 and spins waiting for Thread B's semaphore signal.
2. The Windows scheduler migrates Thread B to CPU1.
3. Thread B's signal is delivered, but the cache line containing the semaphore is now stale on CPU0. The spin loop continues, but the pre-emption on Thread A has fired first.
4. The result is a soft deadlock visible to the user as "activation stuck at 77%". The process is alive (visible in Task Manager) but the activation state never advances.

Microsoft's multi-processor synchronization model permits this class of race. The WinCC V6.2 internal synchronization primitives do not use the InterlockedCompareExchange-based busy-wait that the SMP kernel expects, and they do not declare the SetThreadAffinityMask required to keep the dance localized to one logical CPU.

4. Diagnostic Verification

Before applying the hotfix, validate the root cause and isolate from other classes of activation failure (corrupt project, missing authorization, OPC driver failure, PLC link failure).

4.1 Confirm Multi-Core Host

Verify the host has more than one logical processor visible to the WinCC process:

wmic cpu get NumberOfLogicalProcessors, NumberOfCores, Name

Expected output on a confirmed defective host: NumberOfLogicalProcessors=2 (or higher). If NumberOfLogicalProcessors=1, the symptom has a different cause — continue to §4.4.

4.2 Confirm WinCC Process Is Alive

While the activation is stuck at 77%, open tasklist or Task Manager and verify the WinCC Runtime processes are running with non-zero CPU activity:

tasklist /FI "IMAGENAME eq CCESvr.exe"
tasklist /FI "IMAGENAME eq CCRTLServer.exe"
tasklist /FI "IMAGENAME eq CCHMIEServer.exe"
tasklist /FI "IMAGENAME eq CCDmPrc.exe"

All four should be present. If CCESvr is in a steady-state CPU plateau (0-2% but non-zero), you are likely looking at the soft deadlock. If CCESvr is not present, this is a service-startup failure, not a scheduling race.

4.3 Check the Windows Event Log

Open eventvwr.msc and inspect the Application log. Filter to Source: WinCC. Common event signatures for the 77% hang:

4.4 Distinguish From Project / Authorization Faults

Create a new empty project on the same PC with no PLC tags, no scripts, and no picture objects. Activate the empty project:

• If the empty project also hangs at 77%: confirmed host-level fault, proceed to the hotfix in §5.
• If the empty project activates to 100%: the production project has a corrupted tag connection or driver. Inspect the project's *.ldf log and the CCDataMgr.log in %ProgramFiles%\Siemens\Automation\WinCC\Diagnostics.

5. Solution: Install the Siemens Hotfix (Entry ID 24740694)

Siemens has published a hotfix that addresses the multi-core scheduling race in WinCC V6.2. The hotfix is identified by Entry ID 24740694 in the Siemens Industry Online Support portal.

5.1 Obtain the Hotfix

1. Open the official entry: https://support.industry.siemens.com/cs/document/24740694
2. Log in with a Siemens Industry Online Support account (free registration).
3. Download the .exe or .msi package attached to the entry. Note the precise SP level covered by the patch (SP2, SP3, or SP4) and verify it matches your installed WinCC version.
4. Record the SHA-256 hash of the downloaded package and compare it to the value published in the Siemens download metadata. Do not run a package with a non-matching hash.

5.2 Pre-Install Checklist

1. Deactivate any running Runtime project. If Runtime is stuck at 77%, end the CCESvr, CCRTLServer, and CCHMIEServer processes in Task Manager.
2. Close WinCC Explorer.
3. Stop all WinCC services from services.msc (set to Manual temporarily).
4. Back up the project directory (default: C:\Siemens\Automation\WinCC\WinCCProjects\<ProjectName>) and the project database folder.
5. Capture a system state baseline with the WinCC Diagnostic Tool (Siemens\Automation\WinCC\Tools\Diagnosis\DiagnosisTool.exe).

5.3 Install the Hotfix

1. Run the hotfix installer as Administrator (right-click → Run as administrator).
2. Accept the license terms. The installer will detect the installed WinCC build and refuse to proceed on a non-matching SP level.
3. Allow the installer to stop and restart the dependent services.
4. When prompted, choose Update installation rather than a full re-install.
5. Reboot the PC when the installer reports success.

5.4 Post-Install Validation

Verify the patch is in place by inspecting the WinCC version registry key:

reg query "HKLM\SOFTWARE\Siemens\Automation\WinCC\Setup" /v Version

The returned version string should now include the hotfix build identifier referenced in the Entry 24740694 release notes. Compare the build string to the table in the entry's History section.

6. Alternative Workarounds

If the hotfix cannot be applied immediately, three field-proven workarounds are available. Each carries trade-offs and should be considered a temporary measure.

6.1 CPU Affinity Pinning

Force CCESvr and CCRTLServer to a single logical processor. The soft deadlock is avoided because the spin/yield loop executes on one CPU without pre-emption from the migration that triggers the cache-line race.

1. Open Start → Run → mmc.exe, add the Task Scheduler snap-in if not present, or simply create a startup script.
2. Create SetAffinity.cmd in C:\Siemens\Automation\WinCC\bin:

@echo off
REM Pin WinCC core services to CPU 0 to avoid multi-core scheduling race
start /affinity 1 "" "%ProgramFiles%\Siemens\Automation\WinCC\bin\CCESvr.exe"
start /affinity 1 "" "%ProgramFiles%\Siemens\Automation\WinCC\bin\CCRTLServer.exe"
start /affinity 1 "" "%ProgramFiles%\Siemens\Automation\WinCC\bin\CCHMIEServer.exe"

3. Disable the equivalent Windows service-start entries for those processes and replace with the script via Group Policy or a Task Scheduler entry on system start.

6.2 BIOS-Level Logical Processor Disable

Many OEM BIOS setup screens expose a Logical Processor or Hyper-Threading toggle. Disable the second logical processor so the OS sees a single-core host. The WinCC scheduling race cannot occur.

6.3 Service-Start Ordering Adjustment

Manually start the WinCC services in the correct dependency order after a clean boot, leaving a 2-3 second delay between each start. This gives the Event Server's initialization mutex enough time to settle before the data manager requests its handshake:

net start "WinCCService"
ping -n 3 127.0.0.1 > nul
net start "CCESvr"
ping -n 3 127.0.0.1 > nul
net start "CCProjectMgr"
ping -n 3 127.0.0.1 > nul
net start "CCAgent"

This workaround is fragile and does not address the underlying race. Use only for diagnosis; do not deploy to production.

7. Verification After Patch Application

After installing the hotfix and rebooting, perform the following verification steps in order.

7.1 Empty Project Activation

1. Create a new empty WinCC V6.2 project.
2. Activate the project.
3. Confirm the progress bar reaches 100% within 15 seconds on a single-core PC and within 30 seconds on a dual-core PC.

7.2 Production Project Activation

1. Activate the original production project.
2. Confirm activation reaches 100%.
3. Open the WinCC picture tree in Runtime and load all configured pictures. Each picture load should complete in < 1 second.
4. Trigger a forced tag change from the PLC side and confirm it is reflected on a WinCC input/output field within the configured update cycle (typically 250 ms or 1 s, depending on the channel driver).

7.3 Stress Test

1. Deactivate Runtime.
2. Reactivate the project ten times in succession.
3. Confirm all ten activations reach 100% without intervention. A 10-of-10 pass rate is the acceptance criterion for production release.

7.4 Event Log Hygiene

1. Open eventvwr.msc and clear the Application log.
2. Activate the project.
3. Confirm that no Source: WinCC events with Level: Error are written during the activation window.
4. Confirm the Event Server: registration pending event is no longer followed by a stall.

8. Related Issue: WinCC Unified "Preconditions Not Met"

Modern WinCC Unified (V16 and later) projects loaded in the TIA Portal environment can present a related but distinct fault: "Loading will not be performed because preconditions are not met". This is not a scheduling race. It is a configuration-state check that fails when one of the following is true:

• The HMI simulation is disabled in Tools → Settings → Simulation → HMI Simulation but the project is being launched through the RT-Simulator.
• The TIA Portal and the Unified Runtime versions are mismatched (e.g., TIA V17 project opened on TIA V18 + Unified Runtime V18).
• The compiled HMI panels are out of date relative to the configured PLC tags. A re-compile of the HMI station is required.

To resolve, enable the HMI Simulation check box under Tools → Settings → Simulation → HMI Simulation and re-attempt the load. If the fault persists, recompile the HMI station and confirm version consistency between the engineering and runtime. The official entry is Entry ID 109775493.

9. Prevention and Best Practices

Apply these rules when commissioning a WinCC V6.2 PC to keep the 77% hang out of the field.

1. Pre-validate on the same CPU architecture. Commission the production project on a PC that matches the production hardware SKU exactly. A bench test on a single-core spare PC is a false positive for this defect.
2. Apply the hotfix as part of the image. Include the 24740694 hotfix in the gold image for every WinCC V6.2 deployment. It is free, signed, and does not change project files.
3. Document the SP level and hotfix build. Record WinCC Version, SP, and the post-hotfix Build string in the PC's asset record. This accelerates support calls and audit reviews.
4. Avoid disabling multi-core at the OS level. The CPU affinity workaround in §6.1 is acceptable for the data manager services, but do not globally disable the second logical processor unless the BIOS workaround in §6.2 is your only path.
5. Run the WinCC Diagnostic Tool quarterly. The Diagnosis tool writes a .zip that includes the CCDataMgr.log, the Event Log filter to Source: WinCC, and the current reg query output of the version key. Submit to Siemens support if a recurrence is observed post-patch.

10. Quick-Reference Matrix

FAQ