WinCC 6.2 SP3 CCHierarchySrv Process Hang: Diagnosis and Fix

Problem Description

On WinCC V6.2 SP3 stations, the HMI/SCADA Runtime can shut down unexpectedly. When the operator (or technician) attempts to deactivate Runtime from the WinCC Explorer, the supporting process WinCC.CCHierarchySrv.1 enters a non-responsive state. The Windows shutdown tracker raises a 2-minute "Application not responding" warning, and only a forced termination of the process returns control to the operator. The Runtime can then be restarted, but the failure repeats after a variable interval (typically minutes to hours).

This symptom set is a regression introduced when migrating from WinCC V6.2 SP2 to V6.2 SP3 on Windows XP SP3. Sites that ran the same project under SP2 on the same hardware and OS image report no failures. The fault therefore originates in the SP3 update of the WinCC COM/DCOM layer rather than in the user project itself.

Environment and Affected Versions

The fault is observed under the following configuration matrix. Values not confirmed by the source are marked as "case to evaluate".

For projects originally authored under older WinCC releases, the Project Migrator path described in the Siemens migration documentation is a relevant diagnostic step. See the official PDF Migration of WinCC Projects from V4 to V6.2 SP3 for the upgrade flow and the location of the diagnostic file written by the migrator.

WinCC.CCHierarchySrv.1 Architecture Overview

WinCC Runtime is built as a set of cooperating COM/DCOM processes. WinCC.CCHierarchySrv.1 is the central component that owns the in-memory hierarchy of all WinCC objects: tag connections, alarm classes, archive configurations, picture tree, user archive structure, and the S7/MPI/TCP driver bindings. Other WinCC Runtime processes (Graphics Runtime, Alarm Logging, Tag Logging, User Archive, Report Designer) register their COM objects against the hierarchy server. When the hierarchy server cannot shut down cleanly, the dependent processes are also torn down by the OS, which is why the Runtime window disappears.

The component is registered as a Windows service. Its identity, launch permissions, and access permissions are stored in the registry and in the COM+ catalog. SP3 added stricter validation of these permissions and of the caller's authentication level, which is the proximate cause of the hang.

Root Cause Analysis

The hang is caused by a permission or authentication mismatch during COM object teardown. The SP3 installer refreshes the COM+ application registration for the WinCC components. When the WinCC Explorer issues the Deactivate Runtime command, the Explorer process and the CCHierarchySrv.1 process exchange a sequence of COM calls protected by Windows authentication. If the authentication level, identity, or launch/access ACL of either side was not refreshed to match the SP3 catalog, the call blocks on a security negotiation. Because the Explorer is waiting for the deactivation to complete, and the server is waiting for permission to release, the process appears frozen for the duration of the OS-defined timeout (default 120 s on Windows XP/Server 2003).

Common contributing factors confirmed by Siemens support patterns for WinCC 6.2 SP3:

1. Service account password rotation. The WinCC services were originally installed under a domain or local user whose password was subsequently changed. The COM+ catalog still holds the old password.
2. DCOM hardening applied by Windows XP SP3. The default DCOM authentication and encryption levels are stricter in XP SP3. The legacy WinCC components expect the pre-SP3 levels.
3. Local security policy / UAC-equivalent restrictions. Group Policy that restricts "Log on as service" or "Log on as batch job" prevents the COM+ identity from starting.
4. Antivirus / EDR file-locking on the project directory. Real-time scan holds an open handle on a project file; CCHierarchySrv.1 cannot flush and blocks on the file close.
5. Corrupt or partial migration of the project tree. The Project Migrator diagnostic file lists the components it could not translate. A partial hierarchy causes the server to enter a recovery loop on shutdown.
6. Operator discipline: deactivation requested from the WinCC Explorer rather than from within the running Runtime, which is the path the SP3 service expects.

Pre-Diagnostic Data Collection

Collect the following artefacts before changing configuration. This protects the option of opening a Siemens support ticket with full evidence.

Resolution Procedure

Apply the steps in the listed order. Each step ends with a verification check; do not advance until the check passes.

Step 1 — Confirm a Clean Service Account

1. Open services.msc and list every service whose name starts with WinCC or CC.
2. For each entry, record the Log On As account. The account must be a known local or domain user with a non-expired password.
3. If any account is LocalSystem and the project lives on a network share, change it to a domain user with Log on as service and Log on as batch job rights.
4. Re-enter the password in the service properties even if it is unchanged, to refresh the LSA secret.

Step 2 — Re-align the COM+ Identity

1. Open dcomcnfg → Component Services → Computers → My Computer → DCOM Config.
2. Right-click WinCC.CCHierarchySrv.1 → Properties.
3. On the Identity tab, select This user and enter the same user/password used in Step 1.
4. On the Security tab, set Launch and Activation Permissions to Customize and grant the WinCC operator group both Local Launch, Remote Launch, Local Activation, and Remote Activation.
5. Set Access Permissions to Customize and grant the same group Local and Remote Access.
6. On the Endpoints tab, leave the default static endpoints; do not select Use any available port on a firewalled system.

Repeat the same identity/security configuration for every WinCC DCOM application, in particular:

• WinCC.Picture
• WinCC.AlarmLogging
• WinCC.TagLogging
• WinCC.UserArchive
• WinCC.Connectivity (if used)

Step 3 — Restore the DCOM Authentication Level for the WinCC Components

1. Still in dcomcnfg for WinCC.CCHierarchySrv.1, open the General tab.
2. Note the AppID. It is a GUID of the form {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}.
3. Close dcomcnfg.
4. Open regedit and navigate to HKEY_CLASSES_ROOT\AppID\<AppID>.
5. Create or modify the value AuthenticationLevel as DWORD = 0x00000002 (Connect) if it is not present, and confirm AccessPermission and LaunchPermission have non-null security descriptors.

Step 4 — Verify and Re-apply Project File Permissions

1. Open a command prompt as Administrator.
2. Run icacls "C:\Siemens\WinCC\Projects\<ProjectName>" /T /C /Q > before.txt to capture the current ACL.
3. Run the WinCC project editor's Project → Properties → Computer → Permissions dialog and re-grant the operator and service accounts. This rewrites the ACLs in the canonical form expected by the SP3 server.
4. Re-run the icacls command to a new file and diff against the original.

Step 5 — Exclude the Project Path from Real-Time Antivirus

1. Identify the antivirus or EDR product in use.
2. Add the following paths to the real-time scan exclusion list, including the executable image files:

3. Repeat the Runtime deactivation cycle five times to confirm the hang is no longer triggered by an AV lock.

Step 6 — Re-Register the Project Migrator Output (Projects Originating in V4 / V6.0 / SP2)

1. Open the Project Migrator diagnostic file. For V4 → V6.2 SP3 the layout is described in the Siemens document Migration of WinCC Projects from V4 to V6.2 SP3.
2. For every component listed as error or warning, open the affected object in the WinCC Explorer of the V6.2 SP3 project, re-save it, and let the hierarchy server re-cache it.
3. Repeat the runtime cycle to confirm the CCHierarchySrv.1 process stops cleanly.

Step 7 — Use the Runtime Internal Deactivation Path

The WinCC SP3 service expects the deactivation request to originate from the running Runtime. The Explorer button is a convenience wrapper that, on some installations, does not propagate the correct COM apartment context.

1. On a running Runtime, open the standard System picture (or the configured exit button).
2. Trigger the configured exit function. The Runtime shuts down internally; CCHierarchySrv.1 is asked to release its COM objects in the correct order.
3. Confirm the Runtime window closes within 10 seconds and the WinCC Explorer reports Runtime deactivated.

Step 8 — Process Priority and Memory Tuning

Verification Procedure

After applying the resolution steps, execute the following verification matrix. The system is considered healthy only when every row passes.

Escalation Path and Siemens Support

If the verification matrix still fails after applying all eight resolution steps, raise a Siemens support request. Provide the artefacts collected in the Pre-Diagnostic Data Collection section and quote:

• WinCC build string (Help → About → Installed Software → SIMATIC WinCC → Version)
• Service Pack level of Windows (e.g. Windows XP SP3, build 2600.x)
• Project origin (native, migrated from V4, V6.0, V6.2 SP2)
• The full Project Migrator diagnostic file if a migration was performed

Open the request via the Siemens Industry Online Support portal: https://support.industry.siemens.com. Cross-reference the WinCC V6.2 SP3 readme and the SP3 hotfix index from the same portal. The V4 → V6.2 SP3 migration PDF is also reachable from the portal at 44029132_wincc_upgrade_v4-v6.2_V2_3_en.pdf.

Troubleshooting Matrix