Fixing SIMATIC Manager Retrieve Error: CC_WINCCOMSQL.mdf Lock

1. Problem Overview

When retrieving a multi-component SIMATIC Manager project that contains integrated WinCC configuration, the operation may abort with a dialog stating "Cannot delete directory". The detail view of the error points to a file named CC_WINCCOMSQL.mdf inside the WinCC subdirectory of the project. The retrieval appears to succeed for the S7 PLC sub-projects but fails before WinCC data is fully extracted, leaving the engineering station with a partially populated project tree.

This symptom is most commonly reported on systems that combine:

• SIMATIC Manager (Step 7 V5.x) with an integrated WinCC station
• WinCC V6.0 SP4 (also seen on V6.0 SP3 and SP5) with the WinCC OLE DB archive component
• Microsoft SQL Server 2000/2005 Express hosting the WinCC runtime and archive databases
• Distributed topology: 1 engineering station, 1+ WinCC server (redundant), 6 WinCC clients, DataMonitor

The issue is intermittent — same project, same hardware, same engineering station, and same operator will succeed on one retrieval and fail on the next. The file referenced is always the SQL Server primary data file (extension .mdf) used by the WinCC OLE DB provider. The dialog text is generated by the Step 7 archive/retrieve subsystem, not by SQL Server itself, which is why standard SQL troubleshooting rarely surfaces the real cause.

2. Affected Software Components and Versions

The path of the offending file inside the project tree is typically:

On integrated engineering stations where the WinCC project has been opened in WinCC Explorer at any point, the .mdf may still be attached to a running SQL Server instance (default instance name WINCC or CC_WINCC_<Project>_<Server>) and therefore locked at the operating-system level.

3. Root Cause Analysis

SIMATIC Manager's Retrieve operation extracts the project archive into the temporary working directory %TMP%\<random>, then renames the result into the final s7proj location. If any file in the archive cannot be overwritten during the final copy phase, the rename fails and the dialog reports the first non-deletable path — usually the WinCC archive .mdf because it is the largest single file in the WinCC subdirectory and the most likely to be touched by a background process.

The five real causes that produce the symptom are:

1. Residual SQL Server handle. WinCC Explorer was opened previously on the engineering station, and the local SQL Server Express instance attached the WinCC database during configuration. Even after closing WinCC Explorer, the MDF can remain attached to a hung or idle SQL Server process.
2. Remote SQL connection. A WinCC client or DataMonitor on the network initiates a connection to the engineering station's SQL instance (e.g. for archive browsing) and holds an open transaction at the moment of retrieve.
3. Antivirus / file-system filter driver lock. On-access scanners (Symantec, McAfee, Trend, Windows Defender real-time) hold a transient read or scan handle on the .mdf during the copy phase, causing the delete to time out.
4. Project fragmentation. Repeated Save operations without Save As (with Reorganization) leave the project database (the .s7p / s7pj SQL store) in a state where the WinCC subtree references files that have stale path entries. The retrieve tries to delete a file that does not exist on disk in a directory that does exist, generating a misleading "cannot delete" message.
5. Volume shadow copy / System Restore lock. Windows creates a snapshot of files modified in the \SIEMENS project area; the snapshot agent briefly owns the file while the retrieve is running.

Because the dialog text always reads "cannot delete", the operator is led to suspect a permissions or anti-virus problem, when the actual cause is one of the five above. The fact that the operation sometimes works confirms an external handle race rather than a structural project corruption.

4. Pre-Retrieval Best Practices

Apply the following checklist before initiating any retrieve on an engineering station that contains integrated WinCC. These steps are the standard pre-flight in the Siemens WinCC service documentation and in the Step 7 V5.x archive/retrieve manual.

1. Close every Siemens application on the engineering station except SIMATIC Manager itself: WinCC Explorer, WinCC Runtime, WinCC Channel Diagnosis, S7-PCT, S7-F Configuration, NetPro (close from the SIMATIC Manager integration if open), and any redundant server client.
2. Stop the local SQL Server instance used by WinCC from the SQL Server Configuration Manager or by net stop "SQL Server (WINCC)". Stopping the service releases every file handle on CC_WINCCOMSQL.mdf.
3. Disable real-time antivirus scanning for the \SIEMENS\Automation\S7Proj and %TEMP% folders for the duration of the retrieve, or use the vendor's recommended application/process exclusion list (e.g. s7wnfkdx.exe, CCExplorer.exe, SQLSERVR.EXE).
4. Confirm no remote WinCC client or DataMonitor is connected to the engineering station. Open SQL Server Management Studio Express, expand Management → Activity Monitor, and check the Process Info column for the database name matching the project. A live connection from a client IP must be terminated (KILL command or by stopping the remote WinCC Runtime).
5. No project open in SIMATIC Manager. The Retrieve command requires that the active project be closed. Choose File → Close on the project tree root, then start the retrieve.
6. Sufficient disk space on the destination volume — at minimum 2× the size of the project archive, plus the temp extraction buffer. For a multi-station WinCC project with 6 clients, plan 1.5 GB free on a single-C drive install.

5. Solution A — Slow Reorganization (Save As)

The Slow Reorganization option rebuilds the internal Step 7 project database and rewrites the WinCC sub-tree pointers to the current physical file layout. It is the first remedy to apply when the project has been transported on removable media or repeatedly saved on a different workstation. It is accessed from the SIMATIC Manager menu:

1. Open the project on the source laptop.
2. Choose File → Save As.
3. In the Save As dialog, set the destination path on the same laptop (do not save directly to a network share — write to a local *.zip via the Archive option to follow Solution B).
4. Tick the option "Reorganization (Slow)". This option rewrites every .s7p and .s7l entry, defragments the project SQL store, and re-paths the WinCC CC_WINCCOMSQL.mdf reference.
5. Confirm with OK. The reorganization may take 10–25 minutes for a 6-client, 2-server WinCC project — do not interrupt.
6. Once complete, perform a Save As again to a fresh *.zip archive (Solution B).

The Slow Reorganization is preferred over the Fast variant when the project has been opened on a machine where the WinCC component was never fully installed — for example, the laptop has Step 7 but only the runtime-side WinCC libraries. Fast reorganization is a metadata-only rebuild and will not rewrite the WinCC file references correctly.

6. Solution B — Archive / Retrieve Round Trip

The Archive command is the only legitimate way to move a SIMATIC Manager project from one engineering station to another, and it produces a single compressed .zip-style file (extension *.arc in older versions, *.zip since V5.4) that contains the complete project tree including WinCC sub-trees. The Retrieve operation on the target machine expands the archive and lays it down under a fresh project directory.

1. On the source engineering station, after running Solution A: File → Archive → select project → choose destination *.zip.
2. During the archive, watch the log for any Error archiving <path> line. A clean archive produces a single PASS line. Errors during the archive step almost always reappear during the retrieve, so do not proceed with a flawed archive.
3. Copy the *.zip to the target engineering station via removable media, SMB share, or RDP-mapped drive. Avoid direct retrieve over a slow WAN — the timeout of the WinCC MDF copy frequently fails and presents the same dialog.
4. On the target: open SIMATIC Manager, File → Retrieve, browse to the *.zip, select a destination directory on a local drive with no WinCC project pre-existing.
5. If the retrieve again fails on CC_WINCCOMSQL.mdf, proceed to Solution C — the issue is then definitively a file-handle race, not an archive integrity issue.

7. Solution C — Manual Unzip Outside SIMATIC Manager

When both A and B continue to fail, the underlying cause is a handle on the destination folder held by a non-Siemens process (antivirus, Windows Search indexer, VSS). Bypassing the SIMATIC Manager extract engine eliminates the file-handle race because the unzip is performed by a single Win32 process that is not subject to the Step 7 rename-into-place step.

1. Copy the *.zip archive to C:\SIEMENS\Automation\S7Proj\<NewProject>\ on the target engineering station. Do not place it inside a directory that already contains a partial extract from a previous failed retrieve — delete that directory first.
2. Use 7-Zip or Windows' built-in ZIP extraction to expand the archive to a temporary location such as D:\Temp\<NewProject>_raw.
3. Open SIMATIC Manager and use File → Open → User Project, then browse to the expanded directory. SIMATIC Manager will detect the project marker file (s7proj) and mount the project without performing any copy or rename operation.
4. Open the WinCC sub-project by right-clicking the WinCC station and selecting Open in WinCC Explorer. WinCC will re-attach the local SQL Server instance to CC_WINCCOMSQL.mdf from the new path.

8. SQL Server and WinCC Database Lock Diagnostics

Use the following diagnostic sequence when the retrieve fails repeatedly and Solutions A–C have been applied. The goal is to identify which process holds the lock on the WinCC MDF.

The most reliable production fix is to perform a scheduled Retrieve with a one-time batch script that runs net stop "SQL Server (WINCC)" immediately before the SIMATIC Manager command and net start "SQL Server (WINCC)" after. The script can be wrapped in s7wncmd.exe /job <jobname> for hands-off transfers between the engineering laptop and the customer station.

9. WinCC V6.0 SP4 Specific Notes

WinCC V6.0 SP4 ships with SQL Server 2000 MSDE and uses the WinCC OLE DB provider for tag logging and alarm logging. The CC_WINCCOMSQL.mdf file is the primary data file of the WinCC OLE DB archive database and is created on first activation of the WinCC project. On integrated engineering stations the file size is typically 30–80 MB even with no runtime data, because it contains the configured archive tag metadata.

Known WinCC V6.0 SP4 hotfixes that affect file-handling behaviour:

• WinCC V6.0 SP4 Hotfix 13 — corrects an SQLServerAgent hang on detach that previously left handles open after WinCC Explorer close.
• WinCC V6.0 SP4 Hotfix 19 — addresses the CC_WINCCOMSQL.ldf log file growth that interacted with the retrieve temp path on FAT32 volumes.
• WinCC V6.0 SP4 Hotfix 22 — required for projects with the Redundancy option; corrects a secondary attach on the standby server that could lock the MDF when the active server polls the partner.

For the engineering station described (3 S7 PLCs, WinCC redundant server pair, 6 clients, DataMonitor), Hotfix 22 is the minimum acceptable level. A station that ships with an earlier SP4 hotfix must be upgraded using the Siemens Support download portal before a reliable retrieve can be performed.

10. Verification Procedure

After applying one of Solutions A–C, perform the following verification sequence to confirm the retrieve completed without data loss:

1. Confirm the s7proj directory size on disk equals the unpacked archive size within ±1%.
2. Open the project in SIMATIC Manager; expand the WinCC station and the S7 sub-projects. Every station in the source tree must appear.
3. Right-click the WinCC station and select Open in WinCC Explorer. The project must open without a Database not found or Cannot attach database prompt.
4. In WinCC Explorer, choose Tools → Status → Project Status. All configured servers, clients and the DataMonitor must report a green status dot.
5. Compile the OS — Station → Compile and Check Objects. Compilation must end with 0 errors, 0 warnings. A failed compile is the strongest indicator that the retrieve left a stale reference in the project tree.
6. Perform a Save As (Fast Reorganization) on the engineering station. A clean fast-reorg implies the project is internally consistent.
7. Run a Consistency Check from the WinCC Explorer Tools menu. This invokes CCConfigCheck.exe which validates every tag, every connection, and every archive against the OLE DB.

11. Field-Proven Preventive Measures

• Maintain a single canonical engineering station and a single laptop that is used to edit offline. Never edit on a customer's runtime server.
• Schedule all retrieves for a maintenance window where no WinCC Runtime, client, or DataMonitor is active on the network.
• Apply a consistent policy: every project closes with File → Close, and every project transfers with Save As (Slow Reorganization) → Archive → Retrieve. Do not copy s7proj directories with Windows Explorer.
• Exclude the entire \SIEMENS tree and %TEMP% from the real-time antivirus scanner.
• Document the SQL Server instance name (typically WINCC) and the detach command in the project's README.txt so the next engineer can reproduce the working retrieve.
• Keep a written log of every WinCC hotfix level applied; each engineering station and runtime server must report the same hotfix level before a retrieve is attempted.

12. Related Errors and Cross-References

The same "cannot delete directory" dialog can be triggered by a different underlying problem with the same symptom. Use the matrix below to disambiguate: