WinCC V7.0 to V7.0 SP3 Migration: Alarmlogging Error Fix

When upgrading a WinCC runtime station from a 32-bit Windows 7 SP1 host to a 64-bit Windows 7 SP1 host, the natural first step is moving to SIMATIC WinCC V7.0 SP3, the first WinCC V7.0 service pack that officially supports the 64-bit operating system. A common error encountered during this transition is the WinCC Migration Tool refusing to open the existing project and returning a database inconsistency error originating in the Alarmlogging subsystem. This reference explains why that error appears, why a migration from V7.0 to V7.0 SP3 is generally not required, and how to repair the Alarmlogging configuration database (the .mcp, .ldf, and .mdf files) when the project was inherited from V5/V6 and has been migrated across multiple main versions.

1. Problem Overview

A WinCC V7.0 project originally created on a 32-bit Windows 7 SP1 Ultimate workstation must be moved to a 64-bit Windows 7 SP1 Ultimate workstation. Because WinCC V7.0 base (RT/U) only supports 32-bit Windows 7, the operator must use WinCC V7.0 SP3, which is the first service pack with certified 64-bit Windows 7 support. On launching the WinCC Migration Tool against the existing .mcp, the tool fails with an inconsistency error tied to the Alarmlogging configuration database.

1.1 Symptoms

• The WinCC Migration Tool displays a database error referencing the Alarmlogging configuration tables (commonly classes MSRT_MsgFilterData, MSRT_MsgClassData, or MSRT_ConfigData).
• SQL Server error messages in the Windows Application log reference the project database file (<project>.mdf) and transaction log (<project>_Log.ldf).
• WinCC Explorer opens the project on the new host only after the migration copy step is bypassed (running the V7.0 SP3 project file directly without using the migrator).
• Unrelated runtime symptoms appear: a color animation bound to a STEP 7 input (I10.7) does not update even though the tag and DB value are confirmed TRUE in the WinCC tag management and STEP 7 online view.

1.2 Environment Details

2. WinCC Versioning Model and Migration Rules

Siemens separates WinCC version changes into three categories, each with a different handling requirement:

Service packs in WinCC V7.0 use the same internal project layout. The SQL Server database schemas that back Alarmlogging, Taglogging, User Archives, and the Text Library are backward-compatible within a main version. Therefore, copying the project directory from the 32-bit host and opening it in WinCC Explorer on the 64-bit host with V7.0 SP3 installed will load the project without invoking the Migration Tool. The migration tool should only be used when crossing a major version boundary.

2.1 Why the Migration Tool Was Started in the First Place

The Migration Tool launches automatically when WinCC Explorer detects that the .mcp header stamp indicates an older main version. In projects inherited through multiple main versions (V5 → V6.0 → V6.2 → V7.0), the database schema has accumulated compound transformations. Opening the V7.0 project on a fresh V7.0 SP3 installation usually does not trigger the migrator at all; if it does, the error is almost always downstream of the Alarmlogging subsystem because Alarmlogging retains the largest number of schema-bound objects across versions.

3. Root Cause: Alarmlogging Configuration Database Inconsistency

The Alarmlogging runtime component persists its configuration into the WinCC project database, which Microsoft SQL Server Express stores in two files in the project directory:

• <project>.mdf — primary data file containing configuration tables, message classes, and archive definitions
• <project>_Log.ldf — transaction log file for the same database
• <project>.mcp — WinCC master project file (references the database files and graphics, scripts, etc.)

When the project was originally authored in WinCC V5, the Alarmlogging tables had a different column layout than V6 or V7. Each migration step rewrites these tables. If any migration was interrupted (power loss, disk full, killed process) or if a custom add-in wrote to the database outside the WinCC API, residual rows can reference columns or lookups that no longer exist in the current schema. When the V7.0 SP3 Migration Tool validates the database, it executes internal consistency checks and aborts on the first orphaned reference.

3.1 Specific Failure Modes

4. Step-by-Step Recovery Procedure

The following procedure repairs the Alarmlogging database without losing the graphics, scripts, or tag configuration of the V7.0 project. It uses SQL Server Management Studio Express (SSMSE) which is included with the WinCC V7.0 SP3 installation media or available as a free download for SQL Server 2008 R2.

4.1 Prerequisites

1. Local administrator rights on the target 64-bit host.
2. WinCC V7.0 SP3 installed and licensed (RC license key applied).
3. SQL Server 2008 R2 SP1 or SQL Server 2008 SP3 installed (WinCC V7.0 SP3 ships the Express edition).
4. SQL Server Management Studio installed (matched to the SQL version).
5. A full backup copy of the project directory from the 32-bit source PC.
6. WinCC Explorer closed on the target host.

4.2 Procedure

1. Copy the entire project directory from the 32-bit PC to the 64-bit PC. Preserve the original directory structure exactly.
2. Verify that the three files below are present and not marked read-only:
   • <project>.mcp
   • <project>.mdf
   • <project>_Log.ldf
3. Open SQL Server Management Studio and connect to the local instance \.\WinCC using Windows authentication. WinCC V7.0 SP3 creates the instance name WinCC by default.
4. Right-click Databases and select Attach…. Add the <project>.mdf file. SSMS will automatically pair it with the corresponding .ldf.
5. If the attach succeeds with a warning about database version, run the following T-SQL script to upgrade the database to the current SQL Server compatibility level:

USE [master]
GO
ALTER DATABASE [<project>] SET COMPATIBILITY_LEVEL = 100
GO
DBCC CHECKDB ('<project>', REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS
GO
USE [<project>]
GO
DBCC CHECKCONSTRAINTS WITH NO_INFOMSGS
GO

6. After repair completes, detach the database cleanly:

   USE [master]
   GO
   EXEC sp_detach_db '<project>', 'true'
   GO

7. Open WinCC Explorer and load the .mcp file. Because the project version stamp is V7.0 and the installed WinCC is V7.0 SP3, the project opens without invoking the Migration Tool.
8. Launch the Alarmlogging editor. Confirm that the message classes, message types, and archive configurations appear correctly. Re-save the configuration to force WinCC to rewrite the cleaned rows to the SQL database.
9. If the Alarmlogging editor reports no messages, the message class structure was lost. Restore the project from the source backup and skip step 6 (the REPAIR_ALLOW_DATA_LOSS removed orphaned rows).

5. Diagnosing the Separate Color Animation Issue

The user also observed that a motor icon whose color is bound to the value of the STEP 7 input I10.7 remains in the wrong color even though both the WinCC tag and the STEP 7 input show TRUE. This symptom is not caused by the Alarmlogging inconsistency and must be diagnosed independently. The most common causes, in order of frequency:

5.1 Quick Diagnostic Procedure for the Color Animation

1. Open WinCC Tag Management and confirm the tag linked to I10.7 shows the expected current value in the diagnostics view.
2. Open the affected Graphics Designer picture and select the motor object. Open the configuration dialog for the color animation (right-click → Properties → Color → right-side icon).
3. Verify that the trigger expression uses the same tag name as the one shown in Tag Management. Tags are case-sensitive.
4. Use the WinCC internal variable @CurrentUser or a test tag in the same animation trigger to isolate whether the issue is the trigger or the property assignment.
5. If the trigger is correct and the tag updates, replace the icon's color binding with a simple C-action (in the "Appearance" property of the object):

// C-Action bound to "Background color" of motor object
if (GetTagBit("MotorRunning")) // Tag linked to I10.7
{
  return CO_GREEN;
}
else
{
  return CO_YELLOW;
}
return CO_BLACK; // fallback

6. Save the picture and re-test. If the C-action changes color, the original dynamic dialog binding had a stale expression cache. Delete and re-create the dynamic dialog.

6. Verification and Validation

After both the Alarmlogging repair and the color animation fix, execute the following verification sequence on the 64-bit host before declaring the migration complete.

1. Open WinCC Explorer; verify the project loads without warnings.
2. Activate the project in Runtime. The WinCC RT title bar should appear within 30 seconds.
3. Trigger at least one alarm of each configured class from STEP 7 (force a bit in the corresponding DB). Confirm the alarm appears in the Alarmlogging runtime view within 2 seconds.
4. Acknowledge the alarm from the keyboard. Confirm the acknowledgment is logged in the SQL archive.
5. Verify the motor color changes between green and yellow based on the state of I10.7.
6. Stop Runtime. Re-activate Runtime from a cold start to ensure the project starts cleanly on reboot.
7. Run the WinCC Project Duplicator and create a backup of the repaired project on an external drive.

7. Preventive Measures for Future Migrations

When a WinCC project will be migrated across multiple major versions during its lifetime, the following practices reduce the probability of database inconsistencies.

• One main version per migration cycle. Migrate V5 → V6 first, validate, then V6 → V7, validate. Avoid skipping versions.
• Detach the project database cleanly before any major operation. Use the WinCC Project Duplicator or sp_detach_db rather than copying files while WinCC is running.
• Maintain scheduled SQL transaction log backups. Configure SQL Server Maintenance Plans to back up <project>_Log.ldf every hour so a corrupted log can be replayed rather than rebuilt from the MDF alone.
• Avoid direct SQL writes. All Alarmlogging changes should be made through the WinCC Alarmlogging editor so the internal schema versioning is respected.
• Document the version chain. Keep a project log noting each migration: source version, target version, date, operator, and any error encountered. This log is the first place to look when an inherited project fails to open.
• Test on a copy before applying to production. Always run the Migration Tool on a duplicate directory; the tool modifies files in place.

8. When to Escalate to Siemens Support

If the Alarmlogging repair procedure above still leaves the project unopenable, gather the following artifacts before opening a Siemens Support Request (SR) via the Support Request tool:

• Complete project directory copy (compressed as .zip or .rar; exclude the redundancy folder if file size is a concern).
• The full <project>.mcp, <project>.ldf, and <project>.mdf files.
• Windows Application event log export (eventvwr.msc → Action → Save All Events As…).
• Output of DBCC CHECKDB with WITH ALL_ERRORMSGS, NO_INFOMSGS.
• WinCC version information: open WinCC Explorer → Help → About and capture the dialog.

Reference these in the SR along with Siemens Support entry ID 44029132 to ensure the support engineer has the migration context.

9. Frequently Asked Questions