WinCC Explorer 15-Minute Project Load: Root Cause and Fix Guide

1. Problem Description and Field Signature

Symptom: launching the WinCC Explorer on a WinCC V7 project hangs for 10–20 minutes at the splash screen before the runtime database, editor tree, and configuration views become responsive. The WinCC Explorer process appears in Task Manager but consumes little CPU; disk activity is intermittent. Closing and reopening the project reproduces the delay on every launch, not just the first run.

This pattern is distinct from a slow first-time compile or a slow Graphics Designer open. The bottleneck sits in the project activation sequence that WinCC Explorer performs before handing control to the user, namely mounting the configuration database, opening the alarm and tag logging archives, and resolving all tag and picture references.

The reported database footprint in the originating incident was approximately 1.8 GB. While not pathological in absolute terms, this is well above the 200–500 MB envelope of a typical mid-sized WinCC V7 project and forces WinCC Explorer to scan, integrity-check, and link a large number of archive segments on every open.

2. WinCC V7 Project Architecture You Must Understand

WinCC V7 stores every project in a self-contained folder rooted by the project file <ProjectName>.mcp. The default location is C:\Program Files (x86)\Siemens\Automation\WinCC\WinCCProjects\<ProjectName>\, although projects are commonly moved to a dedicated data partition such as D:\WinCC\<ProjectName>\.

Three distinct Microsoft SQL Server databases are mounted by WinCC Explorer on open:

• Configuration database — holds pictures, scripts, tag definitions, and user administration. Size scales with the number of graphics and tags.
• Alarm Logging database — stores the alarm archive. Grows with the number of configured alarm messages, retention time, and the runtime traffic.
• Tag Logging database — stores the process value archive. Grows with the number of logged tags, logging cycle, and retention time. This is the database that most often bloats to hundreds of MB or multi-GB.

On open, WinCC Explorer performs a connection handshake to the SQL Server instance WinCC, validates the MDF/LDF pair for each archive, and rebuilds internal indices referenced by the project tree. Any path that is slow, contended, virtual, or scanned by a security product directly multiplies the open time. For the official V7 project structure, refer to the Siemens Industry Online Support documentation portal and the WinCC V7.5 SP2 manual under entry ID 109768387.

3. Symptom Classification Matrix

4. Root Cause Inventory

Field evidence groups the causes of slow WinCC Explorer opens into five categories. Walk through them in order; usually one is dominant and others are amplifiers.

5. Diagnostic Procedure

Run the checks below in sequence. Each step takes less than five minutes and produces a measurable result.

1. Capture WinCC diagnostics. Open <ProjectPath>\<ProjectName>\Diagnostics and review WinCC_Sys_<ComputerName>_<Timestamp>.log and WinCC_TrendServer.log. Look for repeated lines containing SQL Server, timeout, or I/O request.
2. Measure the archive footprint. In Windows Explorer, right-click the ArchiveManager folder inside the project path and select Properties. Record the total size and the number of *.mdf segments.
3. Check the SQL service. Launch SQL Server Configuration Manager (Start → Programs → Microsoft SQL Server → Configuration Tools). Confirm that the SQL Server (WINCC) service is in state Running and the startup type is Automatic. Verify the instance name with:
   SELECT @@SERVICENAME; in a query against the WINCC instance via sqlcmd.
4. Inspect the project path. In WinCC Explorer, the path is visible at Project → Properties. Confirm the path is local and on a fixed disk. A leading \\ confirms a network share.
5. Profile disk I/O. Open Resource Monitor (resmon.exe) on the Disk tab. Click WinCCExplorer.exe and observe which file is being read. If the dominant file is a *.mdf in ArchiveManager, database size is the cause.
6. Check antivirus exclusions. Confirm that the project root and C:\Program Files (x86)\Siemens\Automation are excluded from real-time scanning. Microsoft Defender logs are under Microsoft-Windows-Windows Defender/Operational.
7. Rule out VM overhead. If the host is virtual, check for active snapshots and the storage controller type. Paravirtual (PVSCSI) is recommended; LSI Logic SAS is acceptable; IDE is unacceptable for SQL workloads.

6. Resolution: Database Size and SQL Reorganization

If the ArchiveManager folder exceeds ~500 MB or holds more than ~200 segments, the dominant cost is archive validation. Two complementary actions are required.

6.1 Reorganize the Tag Logging database

1. Open WinCC Explorer on the project.
2. Right-click Tag Logging in the tree and choose Reorganize….
3. In the dialog, set the time range to the full archive period and click Reorganize. The tool compacts the MDF, rebuilds indices, and removes freed pages.
4. For Alarm Logging, repeat with Alarm Logging → Reorganize….

Reorganization is non-destructive. For the official procedure, see the Siemens Industry Online Support entry "Reorganizing the tag logging database" in the WinCC V7 information system.

6.2 Switch to segmented archives with a hard size cap

Continuous archives produce a single MDF that grows until it is reorganized. Segmented archives split the data into time- or size-bounded files that SQL Server can open in parallel and that are faster to back up.

• Open Tag Logging → Properties → Archive in WinCC Explorer.
• Set Segment size to 50 MB or to a weekly boundary.
• Set Retention explicitly, for example 90 days, and enable Automatic deletion of segments.
• Apply the same pattern to Alarm Logging.

Result: the project database settles to a bounded size and the open cost is proportional to the number of segments actually in the retention window, not the historical maximum.

7. Resolution: Network and UNC Path Issues

WinCC V7 supports projects on UNC paths but is not designed for it. Every archive open triggers hundreds of small random reads. On a 1 Gbps LAN with typical 1–5 ms latency this multiplies into minutes.

• Move the project folder to a local NTFS volume. Use WinCC Explorer → Project → Save As… to a local path, verify open time, then transfer the project to the engineering workstation via ROBOCOPY or a compressed archive.
• If a multi-user scenario is required, deploy WinCC Server/Client rather than sharing the project folder. The server holds the runtime; clients connect via the WinCC client application, not by opening the same MCP from multiple machines.
• Never store WinCC projects on OneDrive, Dropbox, Google Drive, or any user-mode sync client. These tools take file locks and rewrite files asynchronously, which corrupts the SQL MDF/LDF pair.

8. Resolution: Virtualization and Disk I/O

When the engineering station is a virtual machine, four settings dominate performance:

1. Storage controller. Use VMware Paravirtual SCSI (PVSCSI) or, on Hyper-V, the virtual SCSI adapter. Avoid IDE emulated controllers for any disk that holds WinCC data.
2. Disk format. Provision the VMDK/VHD as thick-provisioned, eagerly zeroed. Thin provisioning causes hypervisor-level zeroing during write bursts, which stalls SQL Server.
3. Snapshots. VMware snapshots put the VMDK into a redo-log chain. Every disk write becomes two writes. Delete all snapshots before commissioning the engineering station.
4. Backup agents. Application-aware backup agents (Veeam, NetBackup, Commvault) often quiesce SQL Server and freeze VSS writers during the snapshot. Run these only outside engineering hours.

Inside the guest, install VMware Tools / Hyper-V Integration Services and keep the balloon driver and time-sync service active. Ballooning reclaims host RAM and forces the guest to swap, which devastates SQL performance. For VMware-specific tuning, see the VMware performance best practices documentation for Microsoft SQL Server.

9. Resolution: Antivirus, Search Indexing, and File Locks

Two background services routinely make WinCC Explorer unusable: real-time antivirus scanning and Windows Search indexer.

• Exclude the project root and C:\Program Files (x86)\Siemens\Automation from real-time scanning. For Microsoft Defender, configure Exclusions → Folder via Group Policy or PowerShell:
  Add-MpPreference -ExclusionPath "D:\WinCC\Project1"
• Exclude the same paths from Windows Search indexer. In Indexing Options → Modify, remove the WinCC project folders from Indexed Locations and add them under Excluded Folders in the Indexing Options → Advanced → File Types dialog.
• Never run disk defragmentation on the MDF/LDF files of an open WinCC project. Windows defragmenter holds a brief lock that can interrupt SQL Server and force a recovery cycle on next open.

10. Corrupt Project Recovery

If WinCC Explorer reports SQL errors, the configuration database or one of the archives is damaged. The recovery ladder is:

1. Stop the SQL Server (WINCC) service.
2. Copy the entire project folder, including the hidden ArchiveManager subfolder, to a safe location.
3. For the configuration database, the file <ProjectName>.mdf in the project root, attach it via SQL Server Management Studio and run DBCC CHECKDB with REPAIR_ALLOW_DATA_LOSS as a last resort.
4. For the archive database, prefer restoring from the last good backup. WinCC V7 supports Project → Backup in the WinCC Explorer, which produces a consistent snapshot. If no backup exists, attach the MDF and run the same DBCC CHECKDB procedure.
5. Restart the SQL Server (WINCC) service and open the project. Verify functionality in a test runtime before deploying.

For SQL Server error codes 9003 (LSN invalid), 3414 (recovery error), and 824 (I/O error), refer to the Microsoft SQL Server error catalog.

11. Verification Checklist

After applying the resolution, confirm the fix with the following measurable checks:

• Open time of WinCC Explorer from double-click to fully responsive project tree: target under 60 seconds for a healthy mid-sized project, under 3 minutes for a multi-archive system.
• ArchiveManager folder size: stable across one week of runtime, not growing without bound.
• Number of MDF segments in ArchiveManager: matches the configured segmentation (one per time/size window).
• Disk Queue Length in Resource Monitor during open: average < 1.
• WinCC diagnostic log: no timeout, I/O request, or SQL Server lines during open.
• Runtime start, picture change, and tag read latency: unchanged before and after the fix, proving the reorganization did not damage archives.

12. Frequently Asked Questions