Fixing WinCC V7.2 CCRtsLoader.exe Data Manager Startup Hang

Problem Overview

WinCC V7.2 Runtime (RT) systems deployed for 24/7 operation may exhibit a symptom where the "Data Manager Runtime" appears frozen at activation. The process CCRtsLoader.exe does not complete initialization, leaving the operator station wedged for 30 to 40 minutes before the runtime eventually activates, or worse, the process aborts and the user receives a "Data Manager has stopped working" dialog from Windows Error Reporting.

In a continuous-process environment (power, water, refinery, pharmaceutical) this hang is unacceptable because the operator loses trend, alarm, and archive visibility during the stall. The defect is documented against WinCC V7.2 without later service packs and is corrected by installing the cumulative WinCC V7.2 Update 10 package. For systems that already run Update 10 but still exhibit the hang, the next diagnostic step is to capture a manual user-mode memory dump (userdump) of CCRtsLoader.exe during the stalled window and submit it to Siemens Technical Support via a Service Request.

Affected Versions

Symptom Details

The hang presents with one or more of the following user-visible signals:

• The "Data Manager Runtime" splash dialog persists and the progress bar does not advance for 30 to 40 minutes.
• The Windows Error Reporting dialog appears with text similar to "Data Manager has stopped working" or "CCRtsLoader.exe has stopped working. Windows is checking for a solution to the problem."
• The WinCC Explorer taskbar icon shows the runtime as "Activating" indefinitely.
• The Microsoft SQL Server Express "WINCC" instance shows status "Starting" or "Recovery Pending" in SQL Server Configuration Manager for the duration of the stall.
• CPU consumption on the SQL Server Express WINCC instance remains at 0-5% while the loader is stalled, indicating the loader is blocked rather than busy.
• The Windows Application event log records a sequence of MSSQLSERVER Information event ID 17137 (database starting) and Warning event ID 9003 (database recovery failed) messages during the stall window.
• The WinCC alarm window remains empty even after forced tag value changes through the internal WinCC tag simulator.
• Operators lose all historian trend visibility for the duration of the stall.

If any of these conditions appear together, treat the host as affected by the V7.2 baseline loader regression.

Root Cause Analysis

CCRtsLoader.exe is the WinCC V7.2 process that initializes the central data manager of the runtime database (Logging, Tag Logging, Alarm Logging, and the underlying Microsoft SQL Server Express / WinCC instance). At startup the loader performs several blocking tasks in sequence:

1. Mounts the configured project path and resolves the project GUID against the project database under C:\Siemens\WinCC\WinCCProjects\<ProjectName>\.
2. Establishes connections to the project database via ODBC data source "CC_WINCC_72_<Project>" configured in the Windows ODBC Data Source Administrator.
3. Loads the Tag Logging (CTL) and Alarm Logging (CML) components and binds them to the configured archive segments stored under C:\Siemens\WinCC\ArchiveManager\.
4. Synchronizes archive configuration with the SQL Server Express instance installed by WinCC (instance name "WINCC", listening on dynamic port).
5. Allocates the shared memory segments used for the WinCC process-to-process channel (default name "Global\Siemens.Automation.WinCC").
6. Registers the alarm and tag change notification ports with the WinCC process tree (default port 4110 for alarms, 4111 for tag changes).
7. Initializes the User Archive component if the project uses user archives (separate shared memory segment).
8. Triggers the SQL Server Express recovery sequence if the WINCC instance was not cleanly shut down.

If any of those steps encounters inconsistent configuration, corrupted cached archive segments, or a SQL Server Express instance that has not completed recovery from the previous shutdown, the loader can deadlock against itself or against the SQL Server. The user-visible symptom is the "Data Manager Runtime" splash stuck on screen.

In the V7.2 baseline (without Update 10), Microsoft security patches and SQL Server Express hotfixes shipped after the WinCC V7.2 release introduced a regression in the loader path that was corrected in Update 10. Update 10 is the cumulative roll-up released for WinCC V7.2 and contains fixes for the CCRtsLoader hang, tag logging performance regressions, and several MS SQL / Windows compatibility corrections.

The deadlock is typically between CCRtsLoader.exe holding a critical section while waiting on a SQL Server response that requires the same critical section. The 30-40 minute wait corresponds to the SQL Server connection timeout escalation chain.

Process Tree at Fault

If the loader (CCRtsLoader.exe) hangs, CCArchiveManager.exe and PDLRT.exe will be in a waiting state and the WinCC operator shell will not open. This is the standard signature of a Data Manager Runtime stall and is the indicator for the procedure in this article.

To inspect the process tree during a hang:

The "Status" column for each should be "Running"; a status of "Not Responding" on CCArchiveManager.exe or PDLRT.exe confirms that the loader deadlock has propagated.

Prerequisites

Before applying the fix, gather the following:

• WinCC V7.2 installation with administrative rights on the engineering station / server.
• Local Administrator account on the Windows host (required to install updates and create user-mode dumps).
• WinCC V7.2 Update 10 installer available from Siemens Industry Online Support (entry 109476283).
• Internet or terminal access to the Siemens Service Request portal.
• Free disk space for the dump file (typically 1x to 4x the CCRtsLoader.exe working set; budget 4-8 GB on the affected volume).
• Backup of the WinCC project database: WinCC Explorer -> Project -> Backup.
• Backup of the SQL Server WINCC instance: stop the instance and copy the entire MSSQL\DATA folder.
• Sysinternals Process Explorer (procexp.exe) or procdump utility.
• 7-Zip for compressing dumps that exceed upload limits.

Solution Path A - Install WinCC V7.2 Update 10

The primary remediation for the hang is to bring the installation up to Update 10. This is the cumulative fix pack Siemens released specifically to address the loader regression. The installer is delivered through the Siemens support entry "SIMATIC WinCC V7.2 including Updates" referenced in entry 109476283.

Pre-Update Backup Procedure

1. Stop all WinCC services from WinCC Explorer.
2. Stop the WinCC SQL Server instance from SQL Server Configuration Manager.
3. Stop the CCArchiveManager and CCEServer Windows services.
4. Back up the project directory: xcopy /E /H /K "C:\Siemens\WinCC\Projects\<ProjectName>" "D:\Backup\WinCC_Project\"
5. Back up the WinCC SQL Server data files: xcopy /E /H /K "C:\Siemens\WinCC\SQLData" "D:\Backup\WinCC_SQL\"
6. Export the WinCC project as a WinCC Backup file (*.zip) using WinCC Explorer -> Project -> Backup.
7. Record the installed WinCC build: WinCC Explorer -> Help -> About.
8. Record the SQL Server Express version: open SQL Server Management Studio Express, connect to WINCC instance, execute SELECT @@VERSION.
9. Record the Windows version: run winver at a command prompt.
10. Record the .NET version: reg query "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full" /v Release.

Update Installation Procedure

1. Stop all WinCC services and exit the WinCC Explorer / Runtime.
2. Stop the WinCC SQL Server instance ("WINCC" instance) and the CCArchiveManager service.
3. Close all instances of CCRtsLoader.exe and CCEServer.exe via Task Manager.
4. Mount the Update 10 image or extract the contents to a local folder.
5. Launch Setup.exe as Administrator from the update folder.
6. Select "Update existing installation" and choose the WinCC V7.2 installation.
7. Accept the license terms and follow the wizard through the database migration step. The installer will upgrade the WinCC SQL Server database schema from the V7.2 baseline to the V7.2 Update 10 schema.
8. Reboot the workstation when prompted.
9. Verify the installed version by opening WinCC Explorer and navigating to Help -> About. The build string should report WinCC V7.2 + Update 10 (internal build 7.2.0.10).

Update Rollback Considerations

WinCC V7.2 Update 10 does not include an automatic uninstaller. If the update introduces a new defect not present in the baseline, the rollback procedure is:

1. Stop all WinCC services.
2. Stop the WINCC SQL Server instance.
3. Restore the project directory and SQL data files from the backup created in the Pre-Update Backup Procedure.
4. Restore the registry hive HKLM\SOFTWARE\Siemens\WinCC from the backup.
5. Reboot and verify WinCC Explorer opens against the baseline V7.2.

Contact Siemens Support before performing a rollback; in most cases the correct path is to capture a dump against the new build rather than revert.

Solution Path B - Capture a Diagnostic Memory Dump

If the hang persists after Update 10, or if the system cannot be taken offline to install updates immediately, capture a user-mode memory dump while the loader is stuck. The dump preserves the call stacks, heap, and module list at the moment of the stall and is the only reliable way for Siemens Technical Support to identify the underlying blocker.

The procedure below uses the Sysinternals Process Explorer tool, which is the standard utility Siemens documents for WinCC diagnostics (entry 45020870).

Capture Procedure (Process Explorer)

1. Download Process Explorer from the Microsoft Sysinternals site and extract it to a folder on the WinCC host.
2. Launch procexp.exe as Administrator.
3. Sort the process list by Name and locate CCRtsLoader.exe.
4. Wait for the Data Manager Runtime dialog to appear or for the runtime to be in its 30-40 minute stalled state.
5. Right-click CCRtsLoader.exe and choose "Create Dump" -> "Create Full Dump". Process Explorer writes a .dmp file into its own folder.
6. Confirm the .dmp file size is non-zero and growing (the write may take several minutes for a full dump of a 1 GB working set).
7. Move the .dmp file off the host before any cleanup.

Capture Procedure (procdump command line)

If Process Explorer is not available, use the Sysinternals procdump utility:

The -ma flag requests a full dump including all process memory; without it procdump writes a mini-dump that lacks heap data and is unsuitable for loader deadlock analysis.

For multiple captures during a recurring hang, add the -s flag for sequential captures:

This captures 5 full dumps spaced 30 seconds apart and is useful for identifying the deadlock progression.

Capture Procedure (Task Manager Fallback)

On Windows 10 / Windows Server 2016 and later, the built-in Task Manager provides a "Create memory dump file" option from the Details tab. Right-click CCRtsLoader.exe -> "Create memory dump file". The Task Manager fallback produces a smaller mini-dump and is acceptable as a last resort if neither Process Explorer nor procdump is available on the host.

Dump File Characteristics

The .dmp file size will be roughly equal to the working set of the process plus its private bytes, commonly 500 MB to 2 GB for a fully loaded Data Manager. A full dump of a loader with a 1.5 GB working set will produce a .dmp file of approximately 1.5 GB. If the loader has been running for several hours and accumulated historical tag data, the dump may be larger.

Compress the dump with 7-Zip in 7z format before upload:

The 7z format typically achieves 2:1 to 4:1 compression on memory dumps dominated by repetitive structures (string pools, archive segment metadata).

Escalation to Siemens Technical Support

After capturing the dump, the next step is to open a Service Request through the Siemens Industry Online Support portal.

1. Navigate to the Siemens support portal and create a new Service Request.
2. Attach the CCRtsLoader.dmp file (compressed with 7z). If the file exceeds the upload size limit, split it using split-dump utilities.
3. Attach the WinCC project backup (WinCC Explorer -> Project -> Backup) so Support can reproduce the loader sequence.
4. Include the installed build string from WinCC Explorer -> Help -> About.
5. Include the SQL Server Express version (run SELECT @@VERSION against the WINCC instance).
6. Include the Windows Event Viewer Application and System logs covering the loader hang window. Export the logs as .evtx files from Event Viewer -> Action -> Save All Events As.
7. Reference the WinCC FAQ entry "How do you create a memory dump for diagnostics purposes in WinCC and PCS 7?" (Siemens support entry 45020870) in the SR description so the support engineer can correlate the procedure with the dump.
8. Provide the Windows version and build (winver output).
9. Provide the SQL Server Express cumulative update level.

The Service Request must be created while the original hang is reproducible; do not reboot the host or clear the dump file before submitting.

Diagnostic SQL Queries

Before opening the Service Request, capture the state of the WinCC SQL Server instance. Connect via SQL Server Management Studio Express to the WINCC instance and run:

Expected: all rows show state_desc = ONLINE, recovery_model_desc = SIMPLE.

Expected: clean output. Errors here indicate archive segment corruption and the loader hang will recur until the archive is repaired or cleared.

Expected: standard WinCC project objects (PDE#..., RT#..., UA#...). Unexpected object names may indicate database corruption.

WinCC V7.2 vs WinCC Unified - Loader Behavior

WinCC V7.2 (classic) and the newer WinCC Unified line use different runtime architectures and different loader binaries. WinCC Unified runtime on a PC is started through the SIMATIC Runtime Manager tool (see the TIA Portal cloud documentation at Starting and stopping runtime (RT Unified)). If the affected project is being migrated from V7.2 to Unified, note that:

• The CCRtsLoader.exe process does not exist on Unified PC RT. Unified uses a different process tree (CCUnifiedSvc, CCUnifiedRT).
• Startup hangs on Unified are typically resolved by clearing the project cache under %ProgramData%\Siemens\Automation\WinCCUnified\RTDB and reloading the project.
• The Update 10 fix does not apply to Unified; Unified fixes are delivered through TIA Portal updates and WinCC Unified Runtime updates.

If the operator station is running V7.2, do not attempt to migrate or apply Unified updates as a remediation.

Distributed System Considerations

In a WinCC V7.2 distributed server / multi-client topology the loader hang on a single server is contained to that server. The redundancy partner takes over and the clients reconnect automatically. However, the hang on the primary server corrupts the archive segments if the loader aborts during the SQL recovery step.

Sequence to recover a redundant server pair:

1. Stop the runtime on the affected server.
2. Force failover to the partner (if not already automatic): WinCC Explorer -> Tools -> Redundancy -> Force failover.
3. Apply Update 10 to the affected server offline.
4. Rejoin the server to the redundant pair.
5. Resynchronize the archive segments: WinCC Explorer -> Tools -> Redundancy -> Synchronize archives.

If the partner server also shows the same stall, both servers require Update 10 before the pair can be brought back online.

Verification

After applying Update 10 and restarting the host, perform the following verification sequence:

1. Start WinCC Runtime from WinCC Explorer.
2. Confirm the Data Manager Runtime splash completes in under 60 seconds.
3. Open the WinCC Tag Logging editor and confirm archives are accessible.
4. Trigger a tag value change and confirm it is logged.
5. Trigger a discrete alarm and confirm it appears in Alarm Logging.
6. Open the SQL Server Configuration Manager and confirm the WINCC instance is running.
7. Open the SQL Server Management Studio Express instance and run: SELECT name, state_desc FROM sys.databases WHERE name LIKE 'CC_%';
8. Confirm all CC_ databases report state_desc = ONLINE.
9. Leave the runtime active for 24 hours and confirm no recurrence of the loader hang.
10. Open Performance Monitor and confirm CCRtsLoader.exe handles remain stable across the 24-hour run.
11. Confirm CPU and memory consumption on the SQL Server Express WINCC instance remain within the design baseline (typically <10% CPU and <4 GB working set for a mid-sized project).
12. Confirm the WinCC alarm window continues to update and that operators can acknowledge and clear alarms.
13. Confirm the trend window loads historical data within 5 seconds for the last 8 hours.

If any of the verification steps fail, repeat the dump capture procedure from Solution Path B and open a Service Request.

Troubleshooting Matrix