Troubleshooting WinCC V6.0 Alarms Not Displaying in Runtime

Problem Description

When a WinCC V6.0 project is started in Runtime, the operator screens load and process tags continue to update through the configured channel (PLC, S7-PLCSIM, OPC, or internal tags), but the Alarm Window, Alarm Control, or the WinCC Alarm Control OCX remains empty. The License Manager does not report any missing licenses, the project activates without an error dialog, and the tag connection status indicator reports a healthy link. The fault is therefore not a licensing, channel, or PLC-side issue, but a Runtime configuration or component registration defect on the HMI station itself.

The two fault signatures that appear most often in the field are:

• Signature A - A status line inside the Alarm Control reports No database available or the Alarm Control simply shows a blank grid with column headers but no rows.
• Signature B - The Alarm Control loads with no error message but does not refresh when an alarm bit toggles in the PLC. No acknowledgment, incoming, or outgoing events are recorded, and the message archive file remains at 0 KB.

Both signatures share the same root family: a component of the WinCC V6.0 alarm pipeline is either not started, not registered, or not reachable from the Graphics Runtime process. The procedures in this document isolate which link in the chain is broken on a specific station.

WinCC V6.0 Alarm Architecture

Before touching any configuration, map the runtime data path so the diagnostic is targeted. In WinCC V6.0, alarm messages travel through a multi-process pipeline:

1. Tag management reads the configured trigger tags from the AS via the channel DLL (e.g. S7MCS.DLL for S7 MPI/TCP, SIMATIC S7 Protocol Suite channel).
2. Alarm Logging Runtime (process CCAlgRt.exe) subscribes to those trigger tags, evaluates the configured limits, message classes, and acknowledgment model, and writes events to the in-process queue.
3. The Alarm Logging database (a Microsoft Access MDB file or a SQL Server database on multi-user stations) receives the event record through the Alarm Logging server.
4. The WinCC Alarm Control OCX (CCAlgCtl.ocx) embedded in the Graphics Designer picture subscribes to the Alarm Logging server and renders the active alarms.

Any break in the chain - a missing start flag, an unregistered OCX, a corrupt MDB, or a misnamed server on a multi-user client - produces a symptom consistent with the field report: tags work, alarms do not appear.

Root Cause Analysis

Five root causes are responsible for the vast majority of "alarms not visible in Runtime" tickets on WinCC V6.0:

R1 and R3 dominate. R1 is the most common fault because the option is silently off on newly restored projects. R3 typically follows a partial or interrupted Service Pack install on the engineering station where the project was last edited.

Diagnostic Procedure

Run the following checks in order. Stop at the first check that fails and apply the matching solution in the next section before continuing.

Check 1 - Verify Alarm Logging Runtime is started

1. Close the active Runtime on the HMI station.
2. In WinCC Explorer, right-click the local computer name and select Properties.
3. Open the Startup tab.
4. Confirm that the Alarm Logging Runtime checkbox is selected. The entry must read exactly Alarm Logging Runtime with a check mark; an unchecked box means the subsystem will not be spawned when Runtime starts.
5. While in the same dialog, also verify the startup order. WinCC V6.0 requires the Graphics Runtime to start after the Alarm Logging Runtime. If the order is reversed or one entry is missing, reorder by selecting the row and using the up/down buttons.

Check 2 - Inspect Runtime process list

1. Activate Runtime on the engineering station or operator station.
2. Open Windows Task Manager (Ctrl+Shift+Esc) and switch to the Processes tab.
3. Confirm the presence of the following executables:
   • CCExplorer.exe - WinCC Explorer shell
   • CCRt.exe - Main Runtime coordinator
   • CCAlgRt.exe - Alarm Logging Runtime
   • CCMessageRt.exe - Message routing service
   • CCArchRt.exe - Archive Runtime (only if archiving is enabled)
4. If CCAlgRt.exe is missing, the Alarm Logging subsystem did not start. The most common reasons are a missing check mark in the Startup tab (Check 1) or a corrupted project file (Check 4).

Check 3 - Inspect the Alarm Control OCX

1. In the WinCC Graphics Designer, open the picture that contains the Alarm Window.
2. Right-click the Alarm Control object and select Properties.
3. On the General tab, confirm the control name is WinCC Alarm Control and the version listed matches the installed WinCC build (e.g. 6.0.0.0 for the base release, 6.0.1.0 for SP1, up to 6.0.4.0 for SP4).
4. If the property dialog shows a CLSID of {xxx} with a not registered marker, the OCX was unregistered. Re-register the control (see Solution 3).

Check 4 - Validate the project database

1. Close WinCC Runtime and WinCC Explorer.
2. Browse to the project folder, by default C:\Siemens\WinCC\WinCCProjects\<ProjectName>\.
3. Confirm the presence of the following files:
   • <ProjectName>.MCP - Master project file
   • <ProjectName>.LDF - Tag database
   • <ProjectName>.LDL - Alarm Logging database
   • GraCS\ folder - Graphics Designer pictures
4. Right-click <ProjectName>.LDL and confirm it is not 0 KB, not marked read-only, and not opened by another process.
5. On multi-user stations, confirm the path is a valid UNC path to the server share and that the Runtime user has write permission on the share and the file.

Check 5 - Validate the message configuration

1. In WinCC Explorer, open the Alarm Logging editor.
2. Open the message list and select a configured message.
3. Inspect the Trigger column. The value must be a valid tag reference, e.g. PLC1::DB10.DBX0.0 for an S7 bit, not an empty string or a tag that does not exist in the tag management.
4. Inspect the Message Class assignment. The class must be visible in the Alarm Control filter; a message in a class that the control is configured to suppress will not render even though the alarm is active.

Solution 1 - Enable Alarm Logging Runtime in the Startup Tab

This is the canonical fix for the most common field symptom. Apply it whenever Check 1 returns an unchecked box.

1. In WinCC Explorer, right-click the station name and select Properties.
2. Click the Startup tab.
3. Tick the Alarm Logging Runtime checkbox.
4. If you use long-term archiving, also tick Archive Runtime.
5. Click OK to apply.
6. Restart Runtime. Confirm in Task Manager that CCAlgRt.exe is now present.

The behavior is consistent with the WinCC V6.0 documentation: the Alarm Logging Runtime is a separately startable subsystem that must be explicitly enabled. The original WinCC V6.0 basic manual documents the startup list and the individual Runtime modules; refer to the SIMATIC WinCC V6.0 Delivery Release entry for the module roster. Detailed behavior is described in the SIMATIC HMI WinCC V6.0 Basic Manual (PDF).

Solution 2 - Restart the Alarm Logging Runtime Process

If the checkbox was already ticked but the process is not running, restart it manually from the Windows command line.

1. Open a command prompt with administrator rights.
2. Navigate to the WinCC binary folder: cd "C:\Siemens\WinCC\bin"
3. Stop the subsystem if it is partially running: CCAlgRt.exe -stop
4. Re-start the subsystem: CCAlgRt.exe -start
5. Activate Runtime and confirm the Alarm Control populates.

Solution 3 - Re-Register the Alarm Control OCX

If the Alarm Control picture shows a placeholder or class not registered, the OCX is unregistered, usually because a Service Pack installation was interrupted or rolled back.

1. Close WinCC Explorer, Graphics Designer, and Runtime.
2. Open a command prompt with administrator rights.
3. Navigate to C:\Siemens\WinCC\bin\.
4. Unregister the control first: regsvr32 /u CCAlgCtl.ocx
5. Re-register the control: regsvr32 CCAlgCtl.ocx
6. Confirm the success dialog "DllRegisterServer in CCAlgCtl.ocx succeeded".
7. Re-open the project and verify the Alarm Control renders.

Re-registering the OCX is the same action as the field-recommended remedy of re-installing the Service Pack when the Alarm Control registration is suspect. The targeted regsvr32 invocation is faster, leaves the rest of the installation untouched, and is the right first action when the rest of Runtime works correctly.

Solution 4 - Repair the Project Database Path or Permissions

If the Alarm Logging Runtime starts and immediately exits with a No database available message, the MDB cannot be opened at the configured path.

1. Close Runtime and Explorer.
2. Open Windows Explorer and navigate to the project folder.
3. Right-click <ProjectName>.LDL, select Properties, and uncheck Read-only.
4. On the Security tab, confirm that the user account running Runtime has Modify rights. On multi-user stations, use a domain account, not a local account, to avoid permission drift when the system password rotates.
5. If the MDB is corrupt, restore the most recent project backup and re-activate.
6. On multi-user clients, confirm the path under Computer > Properties > General > Project File Path uses a UNC path such as \\SERVER01\WinCCProj\<ProjectName> and not a mapped drive letter (mapped drives are user-session dependent and fail under the local SYSTEM account used by Runtime services).

Solution 5 - Correct Message Configuration

If the alarm is properly raised by Alarm Logging but the operator never sees it, the trigger or the message class is misconfigured.

1. Open the Alarm Logging editor.
2. For each message, set the Trigger column to a valid tag address. For an S7 BOOL on a bit, use the syntax PLC1::DB<Number>.DBX<Byte>.<Bit>. For a limit on a real number, use PLC1::DB<Number>.DBD<Byte> with the Type set to Analog.
3. Assign the message to a Message Class that the Alarm Control is configured to display. Common display filters are Errors, Warnings, and System. A message placed in a class not present in the filter is silently dropped.
4. Recompile the project and re-activate Runtime.

Verification

After applying any of the solutions above, perform the following verification sequence to confirm the alarm pipeline is healthy.

1. Activate Runtime.
2. Confirm CCAlgRt.exe is present in Task Manager.
3. Force a controlled alarm: in the Alarm Logging editor, right-click a message and select Trigger Now. The message must appear in the Alarm Control within one second.
4. Toggle the configured trigger bit in the PLC (or in S7-PLCSIM) and confirm the message appears, color-coded by message class, and that the incoming and outgoing events are timestamped in the message archive.
5. Acknowledge the alarm from the Alarm Control toolbar; confirm the Acknowledged column updates.
6. Open the message archive file in C:\Siemens\WinCC\WinCCProjects\<ProjectName>\Archive\ and confirm the event is recorded.

If all six checks pass, the alarm pipeline is operating correctly and the project is ready for production. If any check fails, repeat the diagnostic from Check 1 and re-verify.

Service Pack and Patch Considerations

WinCC V6.0 was shipped with a base release and four Service Packs (SP1, SP2, SP3, SP4). Several alarm-related defects were corrected in those Service Packs. As a rule, projects on stations that have not been updated past the base V6.0.0.0 build should be updated to the latest Service Pack available for the version line, in the same minor version line to avoid binary project format migration.

Always back up the project folder and the registry before applying a Service Pack. The exact OCX fix for a specific project can be confirmed in the SIMATIC WinCC V6.0 Delivery Release entry and in the readme of each Service Pack, both of which are linked from the Siemens Industry Online Support portal.

Multi-User and Redundant Station Caveats

On multi-user systems the Alarm Logging pipeline spans two or more computers. Two additional fault modes appear in this configuration:

• Server not reachable from client - The client Runtime cannot reach the server share because the UNC path is unreachable under the SYSTEM account. Resolve by mapping a real UNC path under Computer > Properties > General > Project File Path, never a mapped drive.
• Preferred server is offline - The client is configured to fail over to a redundant partner, and the partner is also down. In this state Alarm Logging on the client waits for the partner. Force the client to start in Standard mode through the WinCC.ini section [AlarmLogging] only as a temporary measure to confirm the rest of the pipeline; do not leave it in this state for production.

Operating System Interaction

WinCC V6.0 is built for Windows 2000 and Windows XP. Two OS-level issues interact with the alarm subsystem:

• DEP - Data Execution Prevention introduced in Windows XP SP2 can prevent the Alarm Logging OCX from loading if the WinCC binaries are not on the DEP exception list. Add C:\Siemens\WinCC\bin\ to the system DEP exception list under System > Advanced > Performance > Data Execution Prevention.
• DCOM - The Alarm Logging subsystem uses DCOM to communicate with the Graphics Runtime. If the Windows Firewall is enabled (default in XP SP2 and later), DCOM traffic on TCP port 135 plus the dynamic range must be opened. The Siemens default install adds the relevant firewall rules, but hardened images may not.

Frequently Asked Questions