WinCC Alarm Logging Not Working: Redundancy and PC Setup Fix

Problem Summary

WinCC V7 alarm logging fails to display or record messages on a secondary computer after a WinCC project is transferred from the development workstation. The AlarmControl in the Graphics Designer is inserted and configured, the Alarm Logging editor contains message classes and individual messages, and the runtime starts without obvious errors, yet the alarm list remains empty on the target machine. The project is functionally identical between the source workstation (where alarm logging works) and the target workstation (where alarm logging does not work). The most frequent root cause is the persistence of the Activate redundancy flag in the computer properties, which forces the runtime to expect a partner server before alarm messages are accepted into the queue. The temporary solution is to uncheck Activate redundancy on the target machine in WinCC Explorer under Computer > Properties > Redundancy. The remainder of this article explains the underlying architecture, the diagnostic procedure, the resolution, and the verification steps required to confirm a permanent fix.

WinCC V7 Alarm Logging Architecture

WinCC V7 separates alarm generation, alarm archiving, and alarm presentation into three distinct subsystems. Understanding this architecture is essential to diagnose why a configuration that works on one computer silently fails on another. The official WinCC V7 system manual documents the Alarm Logging editor in the chapter Alarm Logging Configuration, available at the Siemens Industry Online Support portal.

Alarm Logging Editor

The Alarm Logging editor is a WinCC Explorer sub-component that defines the message classes, message types, and individual message numbers. Each message is assigned to a single archive. WinCC stores the configuration in the project database under the Alarms subfolder and references it from the files WinCC_AlarmLog.MDF (primary) and WinCC_AlarmLog_Log.LDF (log). When a WinCC project is duplicated to a target computer, these database files are copied along with the project tree, but the SQL Server instance attaches them only if the local SQL Server is reachable and the file paths match the new machine layout.

Graphics Designer AlarmControl

The WinCC AlarmControl is a smart object inserted into a process picture. It binds to the internal message system of the running WinCC project. The key properties that affect cross-machine behavior are MessageBlock (which message lists are queried), ServerName (default @local), and SourceFilter. When the AlarmControl is configured on the source machine without a server prefix, the runtime resolves to @local only on the source machine. On the target machine, the binding may fail silently if the local computer name is not explicitly selected in the AlarmControl property dialog. The @local macro expands to the value of the Computer Name field of the running WinCC project; if the project computer name does not match the Windows hostname, the macro resolves to a name that no longer exists on the network.

Runtime Message Queue

The runtime message queue is a memory-resident structure fed by the alarm detection engine. The detection engine is implemented inside the WinCC Runtime processes PDLRT.exe, CCAlgRtSrv.exe, and CCArchiveMgr.exe. When a redundant configuration is enabled, the message queue is not flushed to the local archive until the redundancy handshake with the partner server completes. On a workstation without a configured partner, the message queue remains in a waiting for partner state and the AlarmControl shows zero entries even though alarms are generated in the PLC tags.

Root Cause: Redundancy Activation on a Standalone Workstation

WinCC V7 stores the redundancy state in the project file WinCC_Project.cfg and in the computer properties dialog. The flag persists regardless of the project name. If the original project was built or tested with a temporary redundancy license, or if a partner server was once configured and later removed, the flag remains set to true. After the project is copied to a target computer that has no partner and no redundancy license, the runtime behavior is deterministic:

1. The CCAlgRtSrv process starts and reads the project configuration.
2. It detects that redundancy is activated but no partner server is reachable.
3. It enters a wait for partner loop for the message subsystem.
4. It does not write incoming alarms to the local archive, even if the archive path exists and is writable.
5. The AlarmControl subscribes to the message queue and receives zero records.

The following state diagram illustrates the runtime states and the conditions under which alarms are blocked:

This is the exact scenario observed when a project is moved from a Windows 7 development workstation to a Windows XP virtual machine on a second computer, and it is also the scenario observed when a project is built from a redundant template and then deployed to a single machine. The fix is to clear the redundancy flag in the project on the target machine, or to apply a redundancy license and configure a partner.

Diagnostic Procedure

Perform the following diagnostic steps in order. Document each step to avoid the trap of fixing one symptom while masking another.

Step 1: Confirm the Computer Name Property

Open WinCC Explorer on the target computer, right-click the computer name entry in the navigation tree, and select Properties. On the General tab, the field Computer Name must exactly match the Windows computer name. Verify by opening sysdm.cpl and reading the Computer Name tab, or by running hostname in a command prompt. If these names differ, the project is launched as an unnamed server instance and many internal handles fail to resolve.

Step 2: Inspect the Redundancy Property

On the same Properties dialog, switch to the Redundancy tab. Note the value of Activate redundancy. If it is checked, this is the primary suspect. Do not uncheck it yet; record the current state. If a partner server is listed, record the partner name and the redundancy type (master, standby, or single-master).

Step 3: Verify the Alarm Logging Editor Loads

In WinCC Explorer, open the Alarm Logging editor. Confirm that the message classes, message types, and messages are visible. If the editor reports that the database cannot be opened, the issue is database related rather than redundancy related. Check the logfile in the WinCC project directory and the Windows Event Viewer (Application log) for entries from WinCC AlarmLogging. The logfile is located at <ProjectPath>\logfile and contains a chronological list of internal WinCC messages.

Step 4: Check the WinCC Runtime State

Start WinCC Runtime and observe the system tray icon and the logfile. Look for the sequence ALGRT: started, ALGRT: redundancy state, and any partner not found entries. The presence of partner not found within the first five seconds of runtime confirms the redundancy flag as the cause. The following command filters the relevant lines from the logfile:

type "<ProjectPath>\logfile" | findstr /I "ALGRT"

Step 5: Verify the AlarmControl Configuration

In the Graphics Designer, open the process picture containing the AlarmControl. Right-click the control and select Properties. On the General tab, the Message Server should be set to the local computer name or to @local. If it is hard-coded to the source computer name, the control binds to a server that does not exist on the target machine and shows zero alarms even when the queue is healthy.

Step-by-Step Resolution

The following procedure resolves the redundancy-flag issue while preserving the rest of the project configuration. Run each step on the target computer.

1. Close WinCC Runtime on the target computer if it is running. Use the system tray icon or the Windows Task Manager to confirm that PDLRT.exe and CCAlgRtSrv.exe are no longer present.
2. Close the WinCC Explorer on the target computer.
3. In Windows Explorer, navigate to the WinCC project folder. The default location on Windows 7 is C:\Program Files (x86)\Siemens\Automation\WinCC\WinCCProjects\<ProjectName>. On Windows XP, the path is C:\Program Files\Siemens\Automation\WinCC\WinCCProjects\<ProjectName>.
4. Create a full backup copy of the project folder by copying it to <ProjectName>_backup_<date> in the same parent directory.
5. Open WinCC Explorer on the target computer and load the project.
6. Right-click the computer name in the navigation tree and select Properties.
7. Switch to the Redundancy tab.
8. Uncheck Activate redundancy.
9. Click OK to close the dialog.
10. Confirm the prompt about restarting the runtime when the configuration changes take effect.
11. Save the project (File > Save in WinCC Explorer).
12. Start WinCC Runtime and trigger a test alarm (for example, set a tag with limit monitoring above a configured threshold).
13. Confirm the alarm appears in the AlarmControl and is written to the configured archive.

Verification

After the fix, run the following verification sequence to ensure alarm generation, display, and archiving all work correctly. Each test must pass before commissioning the target workstation.

Alarm Generation Test

Configure a test tag with limit monitoring in the Tag Management. Set the high limit to 50 and assign a known message number that is configured in the Alarm Logging editor. In the Graphics Designer, insert an input field bound to the test tag and force the value above 50. The alarm must appear in the AlarmControl within one second. If the alarm does not appear, check the tag connection and the message number in the Alarm Logging editor.

Archive Write Test

Confirm the alarm is written to the configured archive. The default alarm archive path is <ProjectPath>\ArchiveManager\AlarmLogging\ with a rotating file named ALG_<date>.LOG. Open the file in a text editor and verify the alarm entry includes the timestamp, message number, and tag value. The line format is DD.MM.YYYY HH:MM:SS;State;MsgNr;Tag;Value;.

Runtime Stability Test

Leave the runtime running for at least 15 minutes and verify that no partner not found or redundancy handshake failed entries are written to the logfile. If such entries reappear, the redundancy flag is still active or a second project file (such as Redundancy.cfg) contains a conflicting setting. In that case, search the project folder for files that contain the string Redundancy and inspect each file in a text editor.

Multi-Computer Project Transfer Checklist

Use this checklist whenever a WinCC project is moved to a new computer. The checklist prevents the symptom described in this article and most related configuration mismatches.

The topology of a typical source/target pair is shown below. The dashed lines indicate a project copy, not a live runtime link.

WinCC Redundancy Package: When to Enable

The WinCC Redundancy option (part of the WinCC Redundancy V7 add-on) is licensed and configured for high-availability scenarios where two WinCC servers replicate alarms, archives, and internal tags. The license is keyed to the Microsoft Windows SID and the software option set. Enabling redundancy on a single workstation is a common mistake during testing because the WinCC project templates for redundant systems are sometimes the only ones available in the installation media.

When the redundancy package is correctly installed and licensed on both partners, the project configuration includes the partner computer name, the synchronization mode (master/standby or single-master), and the archive path. The CCAlgRtSrv process on each partner opens a dedicated TCP connection to its peer. Until this connection is established, alarms are buffered locally and are not flushed to the local archive. Once the connection is healthy, alarms are written to both archives in a deterministic order based on the message time stamp and the partner priority.

Enable redundancy only when both of the following are true:

• Both partner computers have the WinCC Redundancy license installed and activated.
• The Redundancy tab of the computer properties lists the partner computer name and the partner is reachable on the network.

If either condition is false, the runtime enters the wait for partner state and alarm logging is blocked. This is by design to prevent split-brain scenarios where both partners write the same alarms independently. The detailed license matrix and supported topologies are documented in the WinCC V7 documentation set at the Siemens Industry Online Support portal.

Windows 7 vs Windows XP / VMware Considerations

WinCC V7.4 SP1 is the last version that fully supports Windows XP. WinCC V7.5 supports Windows 7 SP1 (Professional, Enterprise, Ultimate) and Windows Server 2008 R2. The compatibility matrix changes between service packs and must be verified against the official WinCC V7 installation requirements before deploying to a new operating system. The current compatibility list is published in the WinCC V7 readme and in the installation manual at the Siemens Industry Online Support portal.

When the target computer runs WinCC inside VMware on a Windows XP guest, the following additional checks apply:

1. VMware Tools must be installed and current. Missing VMware Tools causes incorrect time synchronization and can break archive file rotation.
2. The Windows hostname inside the guest must be unique on the network and must match the WinCC project computer name exactly.
3. The VMware network adapter must be set to bridged mode, not NAT, if the WinCC project integrates with a distributed system on the physical LAN.
4. USB and serial port passthrough can affect hardware dongle licensing. Use a software license (License File) or a network license server if the dongle is on a physical machine.

Windows 7 introduces User Account Control (UAC) which can prevent WinCC from writing to C:\Program Files (x86)\ even when the user has Administrator rights. Run the WinCC Explorer with administrative elevation (right-click, Run as administrator) or store the project in a non-protected path such as D:\WinCCProjects\ to avoid this issue. Windows XP does not have UAC, so projects stored under C:\Program Files\ work without elevation on that operating system.

License, Database, and Archive Considerations

License and Authorization

WinCC V7 uses a license model where each runtime feature is unlocked by a license key. The RT base license allows configuration and runtime on a single station. The RC license allows a remote configuration client. The Redundancy license unlocks the redundancy feature. The Archives license enables the long-term archive subsystem. When a project is copied to a new computer, the project configuration does not require a new license, but the runtime does. If the new computer has only an RT base license and the project includes features such as redundancy, the runtime may either fall back to a degraded mode or fail to start certain subsystems. Use the License Analysis tool (Start > Siemens Automation > License Analysis) on the target computer to confirm that all required licenses are present and active. Authorizations that are signed by a non-default License Server may also be rejected. Always check the validity period of the license file, the License Server availability, and the network reachability of the License Server (default TCP port 1947).

SQL Server and Database Files

The alarm logging database is stored in the project folder under Alarms as WinCC_AlarmLog.MDF and WinCC_AlarmLog_Log.LDF. SQL Server Express (bundled with WinCC V7) attaches these files automatically when the project is opened in WinCC Explorer. The bundled version is SQL Server 2014 Express on WinCC V7.4 and later. If the database files are in a read-only folder, are locked by another SQL Server instance, or are stored on a network share without the proper Windows delegation, the attachment fails and alarm logging is disabled. Verify the SQL Server service status with sc query "MSSQL$WINCC" and the database attachment with the SQL Server Management Studio Express bundled with WinCC.

Archive Path Configuration

The runtime archive path is configured in the Time Period properties of each archive in the Alarm Logging editor. The path is stored as an absolute path in the project file. When the project is moved to a new computer, the path may point to a non-existent drive or directory. Edit the archive properties and reconfigure the path to a valid local directory. The default recommended path is D:\WinCCArchives\<ProjectName>\ on a dedicated data partition. If the path contains invalid characters or exceeds the 260-character Windows path limit, the runtime reports an archive error and silently discards the alarms.

Best Practices and Diagnostics Reference

The following commands help diagnose configuration and runtime state from the Windows command prompt on the target computer. Run them as a Windows user with administrative rights.

The following matrix maps common alarm logging symptoms to their cause and resolution. Use this matrix to triage field reports without reproducing the issue on the bench.

Adopt the following best practices for multi-computer WinCC projects:

• Maintain a single source of truth for the project on a shared file server with a controlled change process.
• Use a naming convention that includes the OS, WinCC version, and project purpose (for example, Plant1_Win7_WinCC75_Main).
• Document the computer name, redundancy state, and license key in a project header file inside the project folder.
• Test the project on the actual target hardware and OS before commissioning.
• Use WinCC project passwords to prevent accidental editing of runtime properties.
• Run the License Analysis tool before each deployment to confirm runtime authorization.
• Back up the project folder after every change, not only before a major change.
• Use a dedicated partition (for example D:\) for archives and databases to keep them separate from the OS partition.

For new projects on TIA Portal, WinCC Unified provides a modern alarm subsystem with native OPC UA Pub/Sub support. The Unified alarm configuration is described in the official Creating a data log and an alarm log (RT Unified) documentation. The Unified runtime does not use the file-based WinCC_AlarmLog.MDF database; it uses a log database that is automatically created by the runtime, and the redundancy settings are in the HMI device runtime settings rather than in a separate Redundancy tab.

FAQ