Backing Up WinCC Projects: Solving SQL Database Lock Failures

This field reference documents the procedure for backing up Siemens WinCC v7 SCADA projects on a single-user or distributed multi-client system when the Microsoft SQL Server instance MSSQL$WINCC holds file handles open against the runtime database files. Root causes, recovery tools, an automated batch script, verification steps, and a troubleshooting matrix are included.

1. Problem Overview

When archiving a WinCC runtime project from disk to a backup location (external drive, network share, or local archive folder), Windows file-copy operations fail with access-violation errors on the database files. The error occurs even when the project has been closed through WinCC Explorer. The MSSQL$WINCC service continues to hold locks on the .MDF and .LDF files of the archive database, blocking the copy.

Typical symptoms:

• Copying a WinCC project folder with Windows Explorer returns The process cannot access the file because it is being used by another process.
• Robocopy reports ERROR 5 (0x00000005) Access is denied and retries the operation.
• Third-party archivers (WinZip, 7-Zip, NTBackup) return sharing-violation errors on the .MDF database files.
• Even after selecting Close project and Exit Explorer in WinCC Explorer, the database files remain locked.

2. WinCC Project Directory Layout

Understanding the layout is required to choose the right copy strategy. The default install creates a project root with the structure below.

The files that are guaranteed to require a clean WinCC shutdown (or a SQL service cycle) are the CC_<ProjectName>_<ComputerName>.MDF configuration database and the ARCHIVE.MDF runtime archive. Configuration files (graphics, scripts, text library) can be copied at any time, although the running runtime may overwrite an inconsistent copy if it is not stopped.

3. Root Cause: Database Detachment Behaviour

WinCC v7 stores runtime data in a Microsoft SQL Server database instance named MSSQL$WINCC. The archive database file ARCHIVE.MDF and the configuration-related CC_<ProjectName>_<ComputerName>.MDF files are attached to this instance when the project is opened. Under a normal shutdown, WinCC issues sp_detach_db to the SQL instance so that all handles are released and the files can be operated on externally.

In rare cases this automatic detachment does not occur on project close. The known causes are documented below.

Once the handles remain, the only guaranteed way to release them is to either restart the MSSQL$WINCC service or to use the recovery tool Reset_WinCC.vbs shipped with the WinCC installation.

4. Prerequisites

1. Local administrator privileges on the WinCC server, or membership in SQLServerMSSQLUser$<COMPUTERNAME>$MSSQLSERVER with explicit permission to stop/start the SQL service.
2. Backup destination with sufficient free space. Allocate 2× the on-disk project size to accommodate deflated copies, transaction logs, and growth between runs.
3. Project directory location. Default is C:\UFO_WINCC_PROJ\<ProjectName>\ for the project root.
4. Service name. The default instance name is MSSQL$WINCC (the literal WINCC suffix, not the project name). Confirm with sc queryex type= service state= all | findstr /I "MSSQL" in an elevated command prompt.
5. Credentials. The Windows user running the backup must be the same user that started the SQL service, or hold the SQL sysadmin server role.
6. SQL Server Management Studio (SSMS) for the optional native-database backup path described in section 7.

5. Proper WinCC Project Shutdown Procedure

To minimise the chance of stale database locks, follow this ordered shutdown sequence.

1. On every WinCC client connected to the server, close all faceplates and log off the runtime. Do not simply click the Windows close button on the client window; the connection persists.
2. On the WinCC server, open WinCC Explorer.
3. From the menu bar select File → Close Project. A dialog appears with two options:
   • Exit Explorer — leaves the SQL instance attached.
   • Close project and Exit Explorer — issues the proper detach sequence.
4. Select Close project and Exit Explorer. Wait for the WinCC Explorer window to close. Do not force-close via Task Manager.
5. Open Computer Management → Services and Applications → Services and verify that the following services are stopped:
   • SIMATIC WinCC Explorer (CCExplorer.exe)
   • CCAgent
   • SQL Server (WINCC) (display name), service name MSSQL$WINCC
   • SIMATIC WinCC CCArchiveServer (only present on multi-client systems)

If, after step 4, the database files are still locked, proceed to the recovery procedure in the next section.

6. Recovery Tool: Reset_WinCC.vbs

Siemens ships a VBScript recovery tool that forces WinCC components and attached SQL databases into a known clean state. The tool is intended for exceptional cases only and should not be used for routine shutdown.

To execute:

1. Open an elevated command prompt: right-click Command Prompt and choose Run as administrator.
2. Navigate to the bin folder and run:

   cscript //NoLogo "C:\Program Files\Siemens\Automation\WinCC\bin\Reset_WinCC.vbs"

3. The script terminates all WinCC processes, stops the CCAgent, and detaches all configured project databases from MSSQL$WINCC.
4. After the script returns (typically under 30 seconds), verify the project files are unlocked. Open the project directory in Windows Explorer and try to delete the <ProjectName>.MDF file. If deletion succeeds, the detach completed.

7. Automated Backup Script

When the shutdown procedure above still leaves handles open — a common situation on multi-client systems where one client fails to release its connection cleanly — the most reliable approach is to cycle the SQL service during the backup window. The batch script below implements that approach and is hardened against repeated runs and partial copies.

@echo off
REM =============================================================
REM  WinCC v7 project backup with SQL service cycle
REM  Run this script from an elevated command prompt on the
REM  WinCC server. It refuses to run from any other host so that
REM  the user has the right to stop the SQL service and to read
REM  the security descriptors on the files.
REM =============================================================

setlocal EnableExtensions EnableDelayedExpansion

REM --- Safety: host check -------------------------------------
if /i "%COMPUTERNAME%" neq "SRVWINCC" (
    echo -------------------------------------------------
    echo  Execute this from SRVWINCC to ensure all
    echo  permissions and SQL handles are scoped to the
    echo  correct server. Aborting.
    echo -------------------------------------------------
    exit /b 1
)

REM --- Configuration ------------------------------------------
set "SRC=C:\UFO_WINCC_PROJ\UFO_WINCC_RUN"
set "DST=D:\UFO_WINCC_PROJ\UFO_WINCC_RUN"
set "SVC=MSSQL$WINCC"
set "LOG=%~dp0backup_%DATE:~10,4%-%DATE:~4,2%-%DATE:~7,2%.log"

echo [%DATE% %TIME%] Backup start  src=%SRC% dst=%DST% > "%LOG%"

REM --- Optional: force a clean WinCC close --------------------
REM cscript //NoLogo "C:\Program Files\Siemens\Automation\WinCC\bin\Reset_WinCC.vbs" >> "%LOG%" 2>&1
REM Remove the REM above if you want to force a detach before
REM stopping the SQL service. Required only when Reset_WinCC
REM is needed (see notes above).

REM --- Stop SQL ------------------------------------------------
echo [%DATE% %TIME%] Stopping %SVC%...                         >> "%LOG%"
net stop "%SVC%"                                                >> "%LOG%" 2>&1
if errorlevel 1 (
    echo [%DATE% %TIME%] ERROR: could not stop %SVC%. Aborting. >> "%LOG%"
    type "%LOG%"
    exit /b 2
)

REM --- Robocopy mirror with security descriptors --------------
REM  /E       = subdirectories, including empty ones
REM  /COPYALL = D A T S O U (data, attributes, timestamps,
REM             security, owner, audit info)
REM  /R:1 /W:1 = one retry with a one-second wait on transient
REM             errors
REM  /NP     = no progress, easier log parsing
REM  /LOG+   = append to log file
robocopy "%SRC%" "%DST%" /E /COPYALL /R:1 /W:1 /NP /LOG+:"%LOG%"
set "RC=%ERRORLEVEL%"

REM --- Restart SQL --------------------------------------------
echo [%DATE% %TIME%] Starting %SVC%...                         >> "%LOG%"
net start "%SVC%"                                               >> "%LOG%" 2>&1

REM --- Report --------------------------------------------------
if %RC% GEQ 8 (
    echo [%DATE% %TIME%] ERROR: robocopy returned %RC% - some files failed. >> "%LOG%"
    type "%LOG%"
    exit /b 3
) else (
    echo [%DATE% %TIME%] Backup complete, robocopy RC=%RC%. >> "%LOG%"
    type "%LOG%"
    exit /b 0
)

7.1 Script behaviour notes

• The host check at the top prevents the script from being run on the wrong machine, which would silently produce a half-empty backup because the local SQL service would be unaware of the remote project.
• Stopping the service takes 5–20 seconds depending on the size of the open archive segment. Plan a backup window of at least two minutes.
• Robocopy return codes 0–7 indicate success with various levels of file copy. Codes 8 and above mean errors. The script treats ≥8 as failure.
• The /COPYALL switch copies NTFS ACLs, audit settings, owner, and timestamps. This is critical for WinCC projects because the runtime reads security descriptors on the project directory at start-up. A copy without ACLs may fail to start the project on the new server.
• Re-running the script is incremental: files that exist at the destination with matching content and ACLs are skipped on the second run.

7.2 Robocopy switch quick reference

Reference: Microsoft Learn: robocopy.

8. Alternative: Native SQL Database Backup

For a database-consistent backup of the WinCC archive data, use the SQL Server native backup path in addition to the file copy. This produces a transactionally consistent backup independent of the file copy.

1. Open SQL Server Management Studio (SSMS) and connect to SRVWINCC\WINCC with Windows authentication.
2. Right-click the database CC_<ProjectName>_<ComputerName> and select Tasks → Back Up.
3. Set backup type to Full, destination to a .bak file, and click OK.
4. Repeat for the ARCHIVE database if archiving is enabled.

The native SQL backup is safe to perform while WinCC is running, in contrast to the file copy, which is the operation that originally fails due to file locks.

9. Step-by-Step Backup Procedure

Combine the procedures above into the following ordered workflow. This is the recommended sequence for a planned maintenance window.

1. Announce the backup window to operations. Tag logging and alarm logging continue until step 3.
2. On each WinCC client, close the runtime. Confirm in WinCC Explorer on the server that the client count is zero: Tools → Status of Server → Connections.
3. On the server, use File → Close Project and select Close project and Exit Explorer. Wait for the Explorer window to close.
4. Verify with handle.exe -a | findstr /I wincc from Sysinternals that no WinCC process is running. (If Sysinternals is not available, use Task Manager with Show processes from all users enabled.)
5. Attempt a file copy. If it succeeds, go to step 9. If it fails with a sharing violation, continue to step 6.
6. Open an elevated command prompt and run cscript //NoLogo "<wincc-bin>\Reset_WinCC.vbs".
7. Retry the file copy. If it fails again, continue to step 8.
8. Stop the SQL service with net stop MSSQL$WINCC and perform the copy. Restart the service after the copy with net start MSSQL$WINCC.
9. Once the copy is complete, perform a native SQL backup of the project database and the archive database for an additional safety net.
10. Restart WinCC Explorer and validate the project by switching to runtime for at least 60 seconds. Confirm tag logging and alarm logging are updating.

10. Verification

After a backup, validate it by performing the following checks before relying on the archive.

Reference for the integrity check: Microsoft Learn: DBCC CHECKDB.

11. Troubleshooting Matrix

12. Edge Cases and Field-Proven Caveats

12.1 Project folder named "WinCC"

A documented internal issue exists when the WinCC project folder is named WinCC (case insensitive). The detach sequence uses the project name as part of an internal key, and the literal name causes a key collision. Rename the project to a unique name (for example, the company name or plant identifier) and the symptom disappears.

12.2 WinCC client keeps a connection

On a multi-client system, simply logging off a client is not enough. The client must close the runtime from the WinCC Explorer toolbar, or the connection is reused on the next login. Use netstat -ano | findstr :<port> on the server, where the port is the WinCC server port (default 5017), to identify clients that still hold TCP sessions.

12.3 Anti-virus interference

Real-time anti-virus scanners (Windows Defender, Trend Micro, McAfee) take brief file locks during on-access scans. The locks are short but frequent enough to cause robocopy to retry and to cause random zip-archive failures. Configure an exclusion for the WinCC project directory in the AV console, or run the backup during a maintenance window where real-time scanning is paused.

12.4 VSS snapshots versus file copy

Some administrators use Volume Shadow Copy Service to back up the WinCC project while it is running. This is generally safe for the configuration files but does not guarantee a transactionally consistent copy of the SQL database files unless the SQL Server VSS writer is registered and active. For a project where the archive database is mission-critical, run a native SQL .bak backup in addition to any VSS-based file copy.

12.5 Distributed system with redundant servers

On a WinCC Redundancy configuration, both servers attach the same project database at start-up. The backup must be performed on the server that is currently the master, or the SQL service must be stopped on both servers before the file copy. After the copy, restart the services and re-establish the redundancy pair with the WinCC Redundancy control panel.

12.6 Scheduled task integration

To schedule the script, create a Windows Scheduled Task with the following settings:

• Run as: a domain account that is a local administrator on the WinCC server and a member of SQLServerMSSQLUser$<COMPUTERNAME>$MSSQLSERVER.
• Run whether user is logged on or not: enabled.
• Run with highest privileges: enabled.
• Trigger: weekly at the planned maintenance window.
• Action: C:\Windows\System32\cmd.exe /c C:\Scripts\backup_wincc.bat

12.7 Disk space and growth

Tag logging segments grow over time. A project that fits in 4 GB at commissioning can exceed 50 GB within a year. Configure the SQL archive to retain only the last 90 days in the primary database, and back up the older segments separately using the WinCC Segment Manager or the SQL Server maintenance plan. The file copy of the live project should still fit in 2–3× the on-disk size of the configuration files plus the current archive segment.

12.8 UAC and elevated services

The net stop and net start commands only succeed when the prompt is elevated, even if the calling user is a local administrator. The backup script in section 7 must therefore be invoked from an elevated Scheduled Task, or from an interactive admin console. Otherwise the stop command silently returns a permission error after a 30-second timeout.

12.9 Network share destination latency

Copying the WinCC project to a network share (UNC path) at gigabit speeds can take 30–60 minutes for a 20 GB project. The SQL service is stopped for the duration; tag logging and alarm logging are paused, and any client request fails with server unavailable. Schedule the window accordingly and inform the operations team. Where possible, copy to a local USB drive first and then copy from the drive to the network share, so the SQL service downtime is minimised.

12.10 What does NOT need a SQL service stop

Graphics files (*.pdl), C and VBS scripts, the text library, and the alarm logging configuration can be backed up at any time, even while the runtime is active. The runtime briefly opens the .pdl files but releases them after the picture cache is loaded. A copy of those files is useful for source control but is not a full project backup.

Frequently Asked Questions