Troubleshooting 'No Connection to the Data Server' and Alarm Logging Server (CCAlgRtServer.exe) Crashes After Power Outages in WinCC

In SIMATIC PCS 7 and WinCC runtime stations, a persistent 'No connection to the data server' error accompanied by blank alarm windows following an ungraceful power outage indicates that the WinCC Alarm Logging runtime server process (CCAlgRtServer.exe) has failed to initialize or crashed during startup. Hard power loss frequently leaves the Microsoft SQL Server database in a suspect/recovering state or corrupts the active Alarm Logging database segment (.mdf / .ldf) in the project ArchiveManager folder. Resolving the fault requires verifying SQL Server service health, detaching corrupted active archive segments, and executing the Siemens 'Reset_WinCC.vbs' diagnostic recovery script.

Architecture of the WinCC Alarm Logging Data Server

In SIMATIC PCS 7 Operator Stations, process alarms, operator actions, and system diagnostic events are managed by the WinCC Alarm Logging Server subsystem:
- Core Runtime Executable (CCAlgRtServer.exe):
* Hosts the real-time event queue, evaluates incoming ALARM_8P telegrams from AS controllers, and communicates with the WinCC Alarm Control display OCX in Graphics Runtime.
* Connects to the local Microsoft SQL Server instance (WINCC) to read historical alarm tables and write new event records.
- Client-Server Data Binding:
* The visual alarm banner in process pictures acts as an OLE-DB / COM client.
* When Graphics Runtime initializes, the alarm control establishes an inter-process communication (IPC) channel with CCAlgRtServer.exe.
* If CCAlgRtServer.exe terminates prematurely or fails to attach to the SQL archive catalog, the visual control displays:
text No connection to the data server.
* All alarm rows remain completely blank, leaving operators unaware of active plant trips.

How Power Outages Cause Database Corruption and Process Crashes

Sudden ungraceful power loss on an industrial PC (IPC) creates severe database synchronization faults:
1. Uncommitted SQL Transaction Rollback:
- At the moment of power loss, SQL Server is actively writing alarm events and tag archives into write-ahead transaction logs (.ldf).
- Upon reboot, Microsoft SQL Server enters Recovery Mode for the WinCC database instance. If the database file headers exhibit torn pages or CRC checksum errors, the database is flagged as SUSPECT.
2. Active Segment Lock in ArchiveManager:
- The active alarm segment (<Project_Name>_ALG_<Timestamp>.mdf) requires an orderly detachment.
- When the PC reboots, CCAlgRtServer.exe attempts to attach to the last known active segment. If the file header is corrupt, the executable encounters an unhandled exception and crashes immediately after launch.
3. Computer Startup List Discrepancy:
- In rare instances, project configuration corruption unchecks the Alarm Logging Runtime option in the WinCC Computer Properties Startup tab, preventing the server process from being spawned at all.

Step-by-Step Recovery Procedure for CCAlgRtServer.exe

Follow this verified recovery protocol to restore alarm server operations:

Terminate Stalled WinCC Processes via Reset Script:
- Close WinCC Explorer and all open project dialogs.
- Open Command Prompt as Administrator.
- Execute the native Siemens reset script:
cmd "C:\Program Files (x86)\Siemens\WinCC\bin\Reset_WinCC.vbs"
- Wait for the confirmation prompt: 'Reset WinCC finished'.
Verify SQL Server Health:
- Open Windows Services (services.msc).
- Verify that SQL Server (WINCC) is running.
- Open Windows Event Viewer (eventvwr.msc) and check Windows Logs > Application. Filter by Event Source MSSQL$WINCC.
- Confirm that no Error 823, Error 824 (I/O corruption), or databases stuck in RECOVERY_PENDING / SUSPECT mode are logged.
Isolate Corrupted Alarm Logging Segments:
- Open Windows Explorer and navigate to the project directory:
<Project_Dir>\wincproj\<OS_Name>\ArchiveManager\AlarmLogging\
- Locate the most recent .mdf and .ldf files whose timestamps coincide with the power outage.
- Cut and move these recent files into a temporary backup directory outside the project folder (e.g. C:\Temp\Corrupted_ALG\).
- Leave the configuration database files in the project root untouched!
Verify Startup Properties in WinCC Explorer:
- Open the project in WinCC Explorer.
- Right-click Computer > Object Properties.
- Navigate to the Startup tab.
- Verify that Alarm Logging Runtime has an active checkmark.
Re-activate WinCC Runtime:
- Click Activate in WinCC Explorer.
- During startup, CCAlgRtServer.exe detects that no valid active segment exists, creates a fresh, uncorrupted .mdf segment automatically, and connects successfully to the Alarm Control.

WinCC Runtime Process and Service Diagnostic Table

The following table details core WinCC runtime executables and their diagnostic roles:

Process NameSubsystem RoleNormal Operating StateCommon Failure SymptomCCAlgRtServer.exeAlarm Logging Server EngineRunning when runtime active'No connection to the data server', blank alarm listCCTlgServer.exeTag Logging Server EngineRunning when runtime active'No trend data available', blank historical curvesCCProjectMgr.exeMaster Project ManagerRunning whenever WinCC openWinCC crashes upon opening .mcp project fileCCDMCommand.exeData Manager Runtime EngineRunning when runtime activeProcess variables frozen with yellow question markssqlservr.exe (WINCC)Microsoft SQL Database ServerRunning as Windows ServiceDatabase errors, project fails to activate, 0x80004005

Verification

To confirm that the Alarm Logging server has recovered full functionality:
1. Open Windows Task Manager on the OS station. Under Details, verify that CCAlgRtServer.exe is actively running with steady memory and normal CPU usage.
2. In WinCC Runtime, open the main alarm screen. Confirm that the message banner loads without the 'No connection to the data server' error.
3. Test event generation: trigger a simulated process alarm in CFC or toggle a test digital input.
4. Verify that:
- The alarm appears immediately in the active alarm list with correct timestamp and message text.
- The alarm horn / sound buzzer activates.
- Acknowledging the alarm updates the status to 'Acknowledged' and clears upon de-actuation.

Limitations and Operational Precautions

When managing industrial PC power reliability:
1. Mandatory Industrial UPS Deployment: All PCS 7 OS Servers, OS Single Stations, and Engineering Stations must be powered through an online Uninterruptible Power Supply (UPS) with automated shutdown signaling (e.g. via SITOP UPS500 / UPS1600) to ensure graceful Windows and SQL Server shutdown during grid failure.
2. Never Delete Root Project Databases: When isolating archive segments, never delete the master project database files located in the root of the OS folder (<Project_Name>.mdf and <Project_Name>.ldf). Deleting these files destroys the entire WinCC project structure.
3. Avoid Hard Power Cycling: Never power off an active OS station by holding the physical PC power button. Always use the WinCC runtime shutdown button or Windows Start > Shut Down.

Engineer FAQ

What causes 'No connection to the data server' to appear intermittently on an OS Client?

On an OS Client, this error indicates a severed network connection to the OS Server hosting the project package, an unselected network adapter in Simatic Shell, or an active firewall blocking SQL port 1433 and DCOM ports.

Can I recover the alarms from the corrupted MDF file that I moved to Temp?

Yes, via the WinCC Alarm Logging Archive Configuration > Link Archive utility. Once the system is stable, you can attempt to link the file as an external archive. If the file is readable, WinCC will import the historical events.

Where can I find the crash logs for CCAlgRtServer.exe?

Inspect the WinCC diagnostic directory at: C:\Program Files (x86)\Siemens\WinCC\Diagnostics\. Review WinCC_Sys_01.log and CCAlgRtServer.log for access violation entries and SQL error codes.

Why does Reset_WinCC.vbs take several minutes to run?

Reset_WinCC systematically signals all WinCC child processes to detach database handles gracefully before issuing termination commands, preventing further SQL database corruption.