Resolving WinCC Alarm Logging Runtime Startup Failure

Problem Description

When activating a Siemens SIMATIC WinCC (WinCC 7.x) project, the Runtime activation stalls at the Alarm Logging subsystem initialization. The WinCC Explorer status remains in the Activating state indefinitely, with the Alarm Logging Runtime Server process CCAlgRtServer.exe consuming CPU cycles but never completing the database bring-up sequence. The graphic Runtime and Tag Logging start normally when Alarm Logging is disabled, but enabling the Alarm Logging Runtime (AlrmLogRT) reproduces the hang at the same position in the startup sequence every time the project is activated.

This symptom typically appears in WinCC 7.0, 7.2, 7.3, 7.4, and 7.5 projects, including migrated projects on Windows 7 SP1, Windows Server 2008 R2 SP1, and Windows 10 LTSC engineering stations. End-user symptoms reported alongside the hang include:

• No alarms displayed in the WinCC AlarmControl picture window
• No entries written to the Alarm Logging archive database
• Historical alarm queries return empty result sets for events that were visually acknowledged
• WinCC Explorer shows AlarmLogging as Fault after a manual stop attempt
• Terminating CCAlgRtServer.exe via Task Manager no longer releases the project activation

How WinCC Alarm Logging Starts

Alarm Logging is one of three optional Runtime subsystems loaded by WinCC Explorer, alongside Tag Logging, Graphics Runtime, and the Report System. When Activate is pressed, WinCC launches the configured subsystems in the order defined under Computer > Properties > Startup. For Alarm Logging the bring-up sequence is:

1. WinCC Explorer contacts the local MSDE / SQL Server Express instance WINCC (default) and attaches <ProjectPath>\<ProjectName>Alg.mdf.
2. The ArchiveManager reads its Config.xml and the segment configuration from the registry path HKLM\SOFTWARE\Siemens\WinCC\ArchiveManager to determine online and short-term archive windows.
3. CCAlgRtServer.exe opens the message configuration, the user-defined message classes, and the ASL (Alarm Segment Logging) files under \ArchiveManager\AlarmLogging.
4. Pending ASOs (archive segments) are verified against the database. If the segment check fails, the server attempts a recovery; on unrecoverable errors the process enters a retry loop.
5. The AlarmControl picture windows are bound to the message channel and refresh begins.

If step 4 loops indefinitely, the WinCC Explorer Activating progress bar will halt at the same point on every restart. The screenshot in the original case (background pink banner with the Alarm Logging bar partially filled) corresponds to this segment-verification phase.

Root Cause Analysis

Three root cause families account for the majority of CCAlgRtServer.exe hang-during-activation cases observed in the field:

In the specific case described, the user noted that the project did activate successfully when AlarmLogging was excluded, then failed again on the next attempt once AlarmLogging was re-enabled. This pattern is diagnostic of primary database corruption, because removing the subsystem short-circuits the segment check and lets the rest of the project come up; the database is then reattached the next time AlarmLogging is enabled and the hang recurs.

Pre-Fix Diagnostics

Before deleting or recreating any database file, capture the following baseline so you can roll back if the fix does not resolve the issue.

1. Stop the Runtime in WinCC Explorer. If WinCC Explorer is unresponsive, terminate CCExplorer.exe, CCAlgRtServer.exe, and CCArchiveManager.exe in that order. Do not terminate sqlservr.exe manually unless the documented clean stop fails after 5 minutes.
2. Verify the SQL Server state using the WinCC internal tool Start > Siemens Automation > WinCC > Tools > SQL Server Management Studio. Connect to localhost\WINCC with Windows authentication. Run:
   SELECT name, state_desc, is_read_only, is_in_standby FROM sys.databases WHERE name LIKE '%Alg%';
   A state of SUSPECT confirms database corruption. A state of RECOVERING indicates the segment check is still in progress and may self-resolve in 1–2 minutes if you wait.
3. Inspect the WinCC log directory at <ProjectPath>\<ComputerName>\WinCC_S<Number>_<Date>.log. Search for AlarmLogging, Error, 0x8004, CONSISTENCY, and ArchiveManager. The log entry just before the hang is the failure origin.
4. List the archive folder contents:
   dir "C:\WinCC_Projects\<Project>\ArchiveManager\AlarmLogging" /a /od
   Look for segment files whose Date Modified is later than the last successful project stop. These are the candidate corrupt segments.
5. Back up the suspect files before deletion. Create a recovery directory and copy the contents of \ArchiveManager\AlarmLogging and the two primary database files into it.

Solution 1: Reset Corrupt Archive Files (Primary Fix)

The resolution confirmed in the original case is the file-reset procedure. This rebuilds the archive database and the segment list from scratch on the next Runtime start.

1. Close WinCC Explorer and confirm the SQL Server instance is stopped (use the WinCC service control panel: Start > Siemens Automation > WinCC > Tools > WinCC Service Mode).
2. In Windows Explorer, navigate to the project folder, by default C:\WinCC_Projects\<ProjectName>.
3. Delete the contents of the segmented archive subfolder:
   <ProjectPath>\ArchiveManager\AlarmLogging
   This folder contains the .ASL (alarm segment logging) files generated by the ArchiveManager. Deleting it does not delete configuration; it deletes the historical segment data only.
4. Delete the primary Alarm Logging database files at the project root:
   <ProjectPath>\<ProjectName>Alg.mdf
<ProjectPath>\<ProjectName>Alg.ldf
5. Do not delete the Tag Logging database (TLG) or the user archives; those are separate files and unaffected by this procedure.
6. Restart the SQL Server Express instance, then start WinCC Explorer and activate the project.

On the next startup, WinCC will recreate <ProjectName>Alg.mdf from the message configuration, the ArchiveManager will build a fresh first segment in \ArchiveManager\AlarmLogging, and CCAlgRtServer.exe will complete its segment check. Runtime activation then proceeds to the Graphics Runtime and the rest of the project.

Solution 2: Selective Database Repair (If History Must Be Preserved)

If the alarm history is required for compliance reporting, attempt a SQL Server repair before falling back to Solution 1.

1. Detach the suspect database in SQL Server Management Studio: Tasks > Detach. Tick Drop Connections.
2. From a command prompt run an emergency-mode repair:
   sqlcmd -S localhost\WINCC -E -Q "DBCC CHECKDB('<ProjectName>Alg', REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS"
3. If CHECKDB reports 0 errors, reattach with Tasks > Attach and restart WinCC Runtime.
4. If CHECKDB reports errors but the repair succeeds, validate that the most recent ASL segment still loads by checking the ArchiveManager log.
5. If CHECKDB fails to repair or reports allocation errors that cannot be fixed with REPAIR_ALLOW_DATA_LOSS, fall back to Solution 1. The SQL Server internal consistency check is the only reliable way to determine whether the database is salvageable.

Solution 3: Optimize WinCC Startup Order

If the activation hang is intermittent and correlates with high system load, review the subsystem startup order. WinCC 7.x allows per-subsystem delays and ordering under Computer Properties > Startup.

• Desired order: Internal Tags > Tag Logging Runtime > Alarm Logging Runtime > Graphics Runtime > Report Runtime. Activating Graphics Runtime before Alarm Logging inflates the working set of CCAlgRtServer.exe while it is trying to attach the database.
• Insert a delay of 2–5 seconds between each subsystem. The default of 0 s is appropriate for small projects but insufficient for projects with more than 50,000 configured messages or more than 5 GB of historical alarm data.
• Disable unused subsystems on operator stations. If the OS is used as a client and does not log alarms locally, uncheck Activate Alarm Logging Runtime on that client.

After applying any startup change, deactivate the project, wait until the SQL Server instance reports Stopped in the service control panel, then activate again. A full cold start is required because WinCC caches the startup order in CCProjectMgr.exe.

Solution 4: Legacy boot.ini /PAE Removal (Windows XP / Server 2003 only)

On 32-bit Windows XP SP3 and Windows Server 2003 hosts, a /PAE switch in C:\boot.ini combined with more than 4 GB of physical RAM has been observed to cause CCAlgRtServer.exe to hang during segment verification. The resolution steps are host-specific and should be applied only on the affected legacy platform.

1. Open Folder Options and uncheck Hide protected operating system files.
2. Edit C:\boot.ini in Notepad run as Administrator. The [operating systems] section contains an entry similar to:
   multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect /PAE
3. Delete the /PAE token, save, and restart the computer.
4. Activate the WinCC project. Alarm Logging should complete its bring-up within the same window in which it previously hung.

Solution 5: Reinstall WinCC Runtime and Configuration Tools

If Solutions 1–4 do not resolve the hang, or if the project also fails to activate on a clean engineering station, the WinCC installation itself may be damaged. This is occasionally observed after incomplete Windows updates, third-party antivirus interference, or disk-level corruption.

1. Capture a full project backup: archive the entire <ProjectPath> directory and the CCConfig folder under %ProgramData%\Siemens\Automation.
2. Uninstall in this order: SIMATIC WinCC Runtime, SIMATIC WinCC Configuration, SIMATIC WinCC SQL Server, SIMATIC WinCC Internet Explorer Extensions. Use the Windows Programs and Features control panel.
3. Reboot the host. Confirm the SQL Server instance WINCC no longer exists in services.msc and the CC* processes are absent in Task Manager.
4. Reinstall the same WinCC version with the same options selected (Runtime + Configuration + SQL Server). Apply the latest service pack available for that version (for example SP2 for V7.4, Upd 18 for V7.5).
5. Restore the project backup and attempt activation.

For general Windows-level runtime errors that persist after the application reinstallation, Microsoft documents a clean-boot procedure that disables non-Microsoft services and startup items; this isolates whether a third-party driver or service is preventing CCAlgRtServer.exe from acquiring the resources it needs. Refer to the Microsoft Learn guidance on resolving runtime errors for the clean-boot steps.

Verification Procedure

After applying any of the above solutions, perform the following checks to confirm a clean state:

1. Open WinCC Explorer. Right-click AlarmLogging. The state should be Running (active), not Fault.
2. Open the AlarmControl picture window in the Graphics Runtime. Generate a test alarm by toggling a configured bit in the internal tag area. The new alarm should appear in the active list within one second.
3. Wait for the configured archive segment rollover (default 1 day for short-term, configurable in the ArchiveManager). Verify that a new .ASL file is created in \ArchiveManager\AlarmLogging at the rollover boundary.
4. Re-query the database in SQL Server Management Studio:
   USE [<ProjectName>Alg]; SELECT TOP 10 MsgNr, TimeCome, State FROM MSGCOMES ORDER BY TimeCome DESC;
   The most recent row timestamp should match the test alarm time from step 2.
5. Deactivate the Runtime. Confirm that CCAlgRtServer.exe exits within 30 seconds and that the SQL Server database state returns to ONLINE in sys.databases. A persistent RECOVERY_PENDING state on the next activation indicates the database is still corrupt and Solution 1 should be applied.

Prevention and Best Practices

• Schedule consistent archive segment rollovers so the working set of CCAlgRtServer.exe stays bounded. A 24-hour short-term window with weekly long-term rollovers is a sensible default for plants with steady-state alarm rates below 10 events per second.
• Monitor archive disk space. The ArchiveManager cannot roll over a segment to a drive that is full; if the alarm path runs out of disk, the runtime will fall into a retry loop on the next activation. Provision at least 20% free space on the archive volume.
• Exclude WinCC directories from real-time antivirus scanning. The \ArchiveManager\AlarmLogging folder, the project database files (*.mdf, *.ldf), and the SQL Server data directory must be added to the antivirus exclusion list. Scanning these files mid-write has been observed to produce database header corruption that exactly matches the symptoms in this article.
• Avoid forced power-off on the engineering station while the Runtime is active. An abrupt power loss during segment rollover is the single most common cause of corrupt .ASL files in the field.
• Test project migrations on a cloned engineering station before deploying to the production HMI server. A migration that changes the message configuration schema (for example V7.0 → V7.4) can leave the archive files in an incompatible format even when the configuration loads successfully.
• Maintain a project backup taken immediately after the Runtime has been successfully activated at least once. The backup captures a known-good state of the message configuration and the freshly built primary database.

Related WinCC Runtime Issues

Engineers often encounter the same hang signature for different underlying causes. The following matrix maps symptoms to the relevant subsystem:

The last row mirrors an issue documented for the OPC DA / KEPServerEX runtime service, where the service mode activation fails when the underlying Windows service is disabled or the service account is missing the Log on as a service right. The resolution pattern is identical in WinCC: the Alarm Logging service must be present, automatic, and have a valid service account. The PTC community entry on service-mode activation failures provides a useful cross-reference for that error pattern.

Service-Mode Activation Caveat

When the WinCC project is started as a Windows service (Runtime service mode, started from Start > Siemens Automation > WinCC > Runtime Service), the activation is not visible interactively. If CCAlgRtServer.exe hangs in service mode, the WinCC Service Control Manager logs an event 7000, 7013, or 7034 in eventvwr.msc > Windows Logs > System. The fix is the same file-reset procedure described in Solution 1, followed by a service restart from services.msc rather than a re-activation from WinCC Explorer. This is consistent with the general troubleshooting pattern for SCADA runtime services that start as background services, as also documented in the AWS AgentCore Runtime troubleshooting guide, which covers service-startup diagnosis for managed runtimes in a similar context.