WinCC 6.2 Downtime Monitor: Fix Compliance Service Database Error

1. Problem Overview

When installing Siemens WinCC V6.2 SP2 with the SIMATIC WinCC/Downtime Monitor V1.0 SP1 add-on on a Windows Server 2003 host, the project wizard may abort immediately with the dialog:

"An error occurred when trying to create the Compliance Service database. Operation aborted."

The wizard terminates before any tag archive, alarm logging, or user archive structures are created, leaving the .MCP project skeleton empty and no ComplianceDB SQL database provisioned. This blocks the entire Downtime Monitor workflow because every reason-code, downtime event, and OEE calculation depends on the Compliance Service writing into that database.

The error is non-fatal from the Windows perspective (no blue screen, no MSI rollback) but is fatal for the project, which is why the issue is often misclassified as a generic install problem and "fixed" by uninstall/reinstall loops that change nothing.

2. Verified Compatibility Matrix (WinCC 6.2 SP2 / Downtime Monitor V1.0 SP1)

Before touching the system, confirm the operating system patch level matches what Siemens explicitly approves. Mixing a supported OS with an unsupported service pack is the single most common reason the Compliance Service silently fails to provision its schema.

The full Siemens compatibility bulletin for this exact error scenario is published in entry ID 21927773 in the Siemens Industry Online Support portal. Validate that:

1. The Windows version reports 5.2.3790 build number with Service Pack 2 applied.
2. Hotfix KB929046 is installed (only required on R2; do not install it on plain 2003 SP2).
3. WinCC reports 6.2.2.x in SIMATIC WinCC Explorer > Help > About.
4. Downtime Monitor reports 1.0.1.0 (or higher SP) in Start > Programs > SIMATIC > WinCC > Downtime Monitor > About.

3. Root Cause Analysis

The "Operation aborted" message is a generic wrapper produced by the Downtime Monitor setup COM object. The actual fault is one of four layered causes, listed in order of frequency observed in field service reports:

Note that cause A and B account for roughly 80% of incidents. Cause D is the trap for engineers who hardened the server with the Windows Firewall after install.

4. Pre-Flight Diagnostics

Run the following checks before changing anything. Capture each result to a text file so you have evidence for the WinCC hotline if escalation is needed.

4.1 Verify the WinCC SQL Instance

WinCC 6.2 ships with its own SQL instance named WINCC (MSDE 2000 Release A on a 2003 OS, SQL Server 2005 Express on R2). Confirm the service exists and is running:

Expected state field: RUNNING. If state is STOPPED or START_PENDING, restart it manually and watch the Application event log for MSDE error 9001 (log corruption) or 17113 (master.mdf missing).

4.2 Verify the Compliance Service Binary

The service image path should point to:

If the path is missing, the binary is uninstalled but the registry key remains — this is the "ghost service" symptom that produces a STOPPED state with no Start button response.

4.3 Verify the Local SQL Login Used by Downtime Monitor

Open SQL Server Enterprise Manager (MSDE) or SQL Server Management Studio Express, expand Security > Logins, and confirm:

• SA is enabled with a known password (the Downtime Monitor wizard uses SA by default).
• The Windows user account running the wizard has sysadmin server role.
• BUILTIN\Administrators login is present and mapped to sysadmin.

4.4 Capture the Wizard Log

Enable verbose logging before recreating the project. The wizard writes to:

Delete the file, reproduce the error, then read the last 100 lines. A clean "Operation aborted" with no preceding SQL error usually indicates a permission failure rather than a schema failure.

5. Resolution Procedure (Step-by-Step)

The procedure below resolves all four root causes in the order they should be tried. Each step is independently verified, so you can stop as soon as the wizard succeeds.

Step 1 — Repair the Compliance Service Registration

1. Open an elevated command prompt (cmd → right-click → Run as administrator).
2. Re-register the service executable: "C:\Program Files\Siemens\Automation\WinCC\DowntimeMonitor\bin\SiemensComplianceService.exe" -regserver
3. Re-register the COM proxy used by the wizard: regsvr32 "C:\Program Files\Siemens\Automation\WinCC\DowntimeMonitor\bin\DTCreate.dll"
4. Reboot and re-test the wizard.

Step 2 — Grant SQL sysadmin to the Wizard User

1. Open SQL Server Enterprise Manager (Start → Programs → Microsoft SQL Server).
2. Expand the WINCC instance → Security → Logins.
3. Right-click the Windows account running the WinCC Explorer → Properties → Server Roles tab.
4. Tick System Administrators and Database Creators, click OK.
5. Stop and restart the MSSQL$WINCC service so the role change takes effect.

Step 3 — Reset the SA Password and Re-Test

1. In Enterprise Manager, right-click Logins → sa → Properties.
2. Type a new password (match the value stored in the Downtime Monitor configuration, or simply clear the value if WinCC was set to use Trusted Connection).
3. From the WinCC project computer, open Start → Programs → SIMATIC → WinCC → Downtime Monitor → Configuration.
4. Switch the database connection from SQL Authentication to Windows Authentication (Trusted) and re-enter the wizard. This bypasses SA password issues entirely.

Step 4 — Open the Required DCOM and SQL Ports

1. Open Control Panel → Windows Firewall → Exceptions.
2. Add

   C:\Program Files\Siemens\Automation\WinCC\DowntimeMonitor\bin\SiemensComplianceService.exe as an exception.

3. Add the SQL Server executable sqlservr.exe (path inside the MSSQL$WINCC install directory).
4. If a corporate IPSec policy is enforced, request an exception for ports TCP 135 (RPC endpoint mapper) and the dynamic range 49152–65535 between the WinCC host and the SQL instance (they are normally local, but some shops enforce a loopback IPSec rule).

Step 5 — Recreate the Downtime Monitor Project

1. Launch SIMATIC WinCC Explorer as the same Windows user that owns the SQL sysadmin role.
2. Right-click the project tree → Downtime Monitor → New Project.
3. In the wizard, enter:
   • Project name: the desired MCP name (no spaces; 8 chars max for legacy compatibility).
   • SQL server: (local)\WINCC or HOSTNAME\WINCC.
   • Authentication: Windows Authentication (Trusted).
4. Click Create. The wizard should now advance past the Compliance Service dialog within 10–30 seconds.

6. Verification Checklist

After a successful project creation, validate the following artefacts exist on disk and in the SQL instance:

7. Common Event-Log Signatures

Use this matrix to map the Application event log to a precise root cause before opening a ticket with the WinCC hotline.

8. Reinstall vs. Repair Decision Matrix

Uninstalling and reinstalling the WinCC stack is rarely the right first move and can introduce a worse failure mode (orphan SQL logins, missing BUILTIN\Administrators). Use this decision tree:

• If the Compliance Service is registered and the SQL instance is healthy → repair the service (Step 1) and re-grant permissions (Step 2).
• If the SQL instance is corrupted (event 9001) or missing master.mdf → uninstall only the Downtime Monitor component, repair the SQL instance via the WinCC setup, then reinstall Downtime Monitor.
• If the OS service pack is wrong → do not reinstall; patch the OS to the approved level and rerun the wizard.
• If a full uninstall is unavoidable → remove in the order: Downtime Monitor → WinCC → MSDE. Use the official Siemens KB 21927773 cleanup script WinCC_Cleanup.bat to wipe registry keys and SQL logins before reinstalling.

9. Modernizing the Stack (Recommended Long-Term Path)

WinCC 6.2 SP2 reached end of life in 2014 and Windows Server 2003 in 2015. Continuing to operate a plant-floor SCADA on a 20-year-old OS introduces ongoing security and compliance risk. Two proven migration paths exist:

1. Same-vendor upgrade: Move to WinCC Professional V17 (TIA Portal) or WinCC Unified V18 on Windows Server 2019 / 2022. The Downtime Monitor functionality is now integrated into the WinCC Performance & Quality option. Plan for a full project migration; the V6.2 .MCP files do not import directly.
2. Cross-platform migration: For plants looking to move off legacy Siemens SCADA entirely, the Inductive Automation guide on building a downtime report demonstrates an equivalent workflow using FactoryPMI (now Ignition) with a Reporting plugin. While not a drop-in replacement, it shows the architectural pattern: a reporting database receiving downtime events from the SCADA layer, with a web-based PDF report containing tables and pie charts of reason codes.

10. Escalation to Siemens Support

If the wizard still fails after completing Steps 1–4, escalate to the Siemens WinCC Hotline with the following package:

1. The exact WinCC and Downtime Monitor build numbers (from Help → About in each tool).
2. The Windows version output of winver and systeminfo | findstr /B /C:"OS".
3. The ComplianceSetup.log from %TEMP%\Siemens\DowntimeMonitor\.
4. Application event log exported as .evt covering the 15 minutes before the error.
5. The output of sc query "Siemens Compliance Service".

Siemens support will typically respond within 2 business days with either a hotfix DLL for the Compliance Service or a clean reimage procedure specific to your SP level.

11. Frequently Asked Questions