Troubleshooting Siemens PCS7 v6.1 SP1 Slow WinCC Tool Startup on Windows XP SP2

1. Problem Description

A SIMATIC PCS 7 v6.1 SP1 single-station Operator Station (OS) running on Windows XP Professional SP2 (Build 2600) exhibits extreme startup delays for the native PCS 7 engineering and runtime tools after a period of normal operation. The fault is reproducible after every reboot and persists across multiple project revisions.

The behavioral fingerprint is highly diagnostic:

• During the delay window the Windows Task Manager reports CPU idle time of 70-95 %, indicating the affected process is blocked on a wait rather than executing code.
• The fault is not project-specific: older project revisions that opened normally in the past reproduce the same delay.
• The fault is not hardware-image-specific: the same project file copied to a 2.2 GHz / 1 GB Power-PG in the domain opens within the healthy time envelope.
• Windows Event Viewer (Application, System, Security) shows no errors during the slow-start interval.
• The DataManager Runtime log shows the project is declared activated approximately five minutes after the project activation timestamp, with no logged error between the two events.
• The delay appeared in the same calendar window in which an eSATA RAID subsystem was installed on the OS station. Project files and the WinCC database remain on the original internal drive.

2. Affected Environment

2.1 Hardware

2.2 Software Stack

For platform architecture and supported configurations refer to the SIMATIC PCS 7 Process Control System product page and the PCS 7 V6.1 SP1 Release Notes.

3. Root Cause Hypotheses

The "processor idling while the GUI waits" pattern almost always points to one of four kernel-level waits: synchronous file I/O, COM/DCOM activation, registry hive lookup, or Winsock/NetBIOS name resolution. The six leading candidates ranked by likelihood for this fingerprint are listed below.

3.1 eSATA RAID driver introducing DPC latency

eSATA host controllers on Windows XP SP2 commonly fall back to the inbox AHCI miniport or a generic storage controller driver when no vendor XP driver is installed. Several chipsets of that generation (JMicron JMB36x, Silicon Image Sil3132 in legacy mode, Marvell 88SE61xx without XP driver) are known to produce high Deferred Procedure Call (DPC) latency under load. Because Windows XP serializes storage completion through DPCs, a slow or misbehaving eSATA driver stalls every I/O that crosses the storage class driver — including the apparently unrelated system drive. The CPU idles while the IRP sits in the device queue.

This is the most likely culprit because:

• The fault appeared in the same window the eSATA RAID was installed.
• The fault is reproducible across older project revisions that previously opened fast.
• The fault disappears when the project is opened on a different workstation without the eSATA subsystem.

3.2 Real-time anti-virus scanning of project files

Anti-virus products that enable on-access scanning of .mcp, .pdl, .ldf, .mdf, .db, .arx, .dtl, or the entire %ProgramFiles%\Siemens tree will sync-scan during process startup. Scanning a 1 GB PCS 7 project file plus the WinCC SQL Server data files while the OS opens them produces the exact 60-300 s wait pattern. The most common offenders are Trend Micro OfficeScan, McAfee VirusScan Enterprise, and Symantec Endpoint Protection with "High Risk" extensions enabled.

3.3 DCOM/COM+ activation timeouts in a workgroup configuration

WinCC Manager, CFC, and DataManager Runtime instantiate COM/DCOM services on launch. In a workgroup (non-domain) configuration the Security Service Provider falls back to NTLM with no Kerberos, and the NT AUTHORITY\ANONYMOUS LOGON lookup can stall for tens of seconds when LAN registration is slow or the computer SID cannot be resolved. The PCS 7 OS activation handshake is the most affected because it spans the OS server, the DataManager, and the archive writer — three COM apartments.

3.4 Winsock catalog corruption or NetBT name resolution stall

PCS 7 v6.1 SP1 makes NetBIOS and RPC calls during WinCC startup to enumerate the connected AS 400 stations. If the TCP/IP NetBIOS helper (NetBT) is misconfigured, or a stale Lmhosts / Hosts entry points to an unreachable address, the resolver waits the full TCP retransmit window (3-21 s) per lookup before timing out. Multiplied across five AS 400s plus the OS partner, this gives the 60-90 s pattern for CFC and the multi-minute pattern for tools that make repeated lookups.

3.5 Page file pressure and disk fragmentation

2 GB of RAM with a 1 GB project plus WinCC runtime plus SQL Server is borderline for Windows XP SP2. If the page file C:\pagefile.sys was placed on the same volume as the project and the volume has fragmented, every large load forces paging I/O. Combined with the eSATA DPC latency (Section 3.1) the effect compounds.

3.6 SQL Server log file growth

WinCC v6.1 ships with Microsoft SQL Server 2000. If the WinCC database recovery model is set to Full and transaction log backups have not been run, the .ldf file grows on every startup until it consumes all free space. Subsequent file I/O then serializes against log growth waits and slows every dependent process.

4. Diagnostic Procedure

Run the diagnostics in the order shown — the goal is to isolate the wait before changing anything. Each step produces a binary pass/fail that points at one of the six hypotheses in Section 3.

4.1 Capture a process wait chain with Process Explorer

Use Process Explorer from Sysinternals to attach to WinCC.exe, CCDataMgr.exe, and CFC.exe during the slow start. Inspect the bottom pane for the kernel wait reason on each thread. The mapping is:

Download: Process Explorer (Sysinternals).

4.2 Confirm DPC latency with LatencyMon

On Windows XP SP2 the in-box xperf toolchain is not available. Install LatencyMon (Resplendence Software) and run it during a WinCC Manager launch. A repeatable DPC latency above 1 ms on the storage stack during a startup cycle is diagnostic for Hypothesis 3.1.

4.3 Inspect WinCC and DataManager logs

PCS 7 v6.1 SP1 writes startup logs to the following paths:

C:\Program Files\Siemens\WinCC\Diagnose\
C:\Program Files\Siemens\WinCC\ArchiveManager\Logging\
C:\Program Files\Siemens\Automation\PCS7\bin\
C:\Program Files\Siemens\Automation\PCS7\log\
%USERPROFILE%\Application Data\Siemens\WinCC\

Open the most recent *.log and search for Activate, Loaded, Error, and Timeout. The phrase "DataManager Runtime is declared activated 5 min after project has been activated, without any errors in between" indicates the project database load succeeded but the runtime activation handshake stalled — this points to DCOM (Hypothesis 3.3) rather than disk (Hypothesis 3.1).

4.4 Confirm the eSATA device driver model

1. Open devmgmt.msc.
2. Expand Disk drives.
3. Right-click the eSATA RAID entry → Properties → Driver tab.
4. Read the Driver Provider and Driver Version.

If the provider is Standard AHCI Controller or Microsoft Storage Controller, the XP inbox miniport is in use and known to produce high DPC latency on certain chipsets (JMicron JMB36x in particular). If the provider is the chipset vendor (JMicron, Silicon Image, Marvell) but the driver is older than 2008, update it.

4.5 Anti-virus exclusion probe

Temporarily disable the on-access scanner and reproduce the start. If startup time drops back to the 5-15 s envelope, anti-virus (Hypothesis 3.2) is the dominant cause. Re-enable the scanner after the probe and apply the exclusion list from Section 5.2.

4.6 Validate Winsock and NetBT

netsh winsock show catalog > %USERPROFILE%\winsock_before.txt
netsh int ip reset
netsh winsock reset
ipconfig /flushdns

Reboot and re-measure. If startup time improves, a corrupted Winsock catalog (Hypothesis 3.4) was the cause.

4.7 SQL Server recovery model and log size

USE WinCC;
DBCC SQLPERF(LOGSPACE);
DBCC LOGINFO;

If the log file is over 5 GB, run a transaction log backup and switch the recovery model to Simple if the customer does not require point-in-time recovery for the WinCC archive database (Hypothesis 3.6).

4.8 Page file sizing

Open System Properties → Advanced → Performance Settings → Advanced → Virtual memory. On 2 GB RAM with PCS 7 v6.1 SP1, set initial = 4096 MB, maximum = 6144 MB on a dedicated volume or one that does not host the eSATA RAID spindles (Hypothesis 3.5).

5. Solutions per Hypothesis

5.1 Solution A — Disable or relocate the eSATA RAID

Path 1 — Remove the eSATA entirely (preferred if the OS station does not require the RAID for archives):

1. Shut down the workstation.
2. Power off the eSATA enclosure.
3. Disconnect the eSATA cable.
4. Boot.
5. Measure CFC, WinCC Manager, and DataManager Runtime startup times against Section 6.

Path 2 — Move archives only to the eSATA:

1. Move all WinCC archive directories to the eSATA volume.
2. Confirm that the project and runtime databases remain on the internal drive.
3. In WinCC Explorer, reconfigure the archive paths.
4. Restart and measure.

Path 3 — Update the controller driver (if the RAID must stay attached):

• For JMicron JMB36x use the JMB36X generic driver dated 2008-01-15 or later.
• For Silicon Image Sil3132 use the SiI-3132 SATALink driver v1.0.0.9 or later.
• For Marvell 88SE61xx use the MV61xx XP 32-bit driver from the motherboard vendor.

Do not rely on the inbox AHCI miniport for any production OS station running WinCC v6.1.

5.2 Solution B — Anti-virus exclusions for PCS 7 and WinCC

Configure the anti-virus product with the following exclusions. Paths may vary by installation directory.

C:\Program Files\Siemens\
C:\Program Files\Common Files\Siemens\
C:\Siemens\Automation\
%ProgramData%\Siemens\
*.mcp
*.pdl
*.mdf
*.ldf
*.db
*.arx
*.dtl
*.log
C:\pagefile.sys
C:\hiberfil.sys

Also exclude the SQL Server data and log directories:

C:\Program Files\Microsoft SQL Server\MSSQL\Data\

For Trend Micro, McAfee, and Symantec endpoint products, also disable "Process pipe scan" for the following executables:

WinCC.exe
CCDataMgr.exe
CCAlgSTRT.exe
CFC.exe
PDLRT.exe
s7otbxdx.exe
S7OTBXSX.exe
S7asgcomm.exe

Reference: Siemens KB 22376971 — Performance issues with antivirus software in PCS 7 / WinCC.

5.3 Solution C — DCOM hardening for workgroup OS stations

If the OS station must remain in a workgroup, harden DCOM defaults so the anonymous fallback does not stall:

1. Run dcomcnfg.
2. Expand Component Services → Computers → My Computer.
3. Right-click → Properties.
4. On the Default Properties tab:
   • Enable Distributed COM on this computer = On
   • Default Authentication Level = Connect
   • Default Impersonation Level = Identify
5. On the COM Security tab:
   • Access Permissions → Edit Limits → add Everyone with Allow
   • Launch and Activation Permissions → Edit Limits → add ANONYMOUS LOGON with Local Launch, Remote Launch, Local Activation, Remote Activation all set to Allow

If the OS station can be joined to the same Windows domain as the AS 400 stations, do so — this resolves most DCOM activation stalls in PCS 7 v6.1 SP1 and is strongly preferred.

5.4 Solution D — Winsock reset and NetBT configuration

Run from an elevated command prompt:

netsh winsock reset
netsh int ip reset
netsh firewall reset
ipconfig /flushdns
arp -d *
nbtstat -R
nbtstat -RR

Then disable NetBIOS over TCP/IP on the workstation NIC if all communication is to AS 400 stations on a known subnet. Path: Network → Properties → TCP/IPv4 → Properties → Advanced → WINS → NetBIOS setting → Disable NetBIOS over TCP/IP. This eliminates the 3-21 s lookup stall per AS 400 and is a low-risk change in a closed control network.

5.5 Solution E — SQL Server maintenance

For the WinCC runtime database and the archive database:

USE WinCC;
ALTER DATABASE WinCC SET RECOVERY SIMPLE;
DBCC SHRINKFILE (WinCC_log, 1024);
BACKUP DATABASE WinCC TO DISK = N'D:\backup\WinCC_full.bak';
DBCC DBREINDEX;
UPDATE STATISTICS;

Schedule the maintenance block monthly via a SQL Server Agent job. Reference: SQL Server maintenance plans.

5.6 Solution F — Disk defragmentation and page file tuning

1. Run defrag C: -f on the internal drive (the internal drive only — never on a RAID LUN that hosts SQL data files).
2. Move the page file to a dedicated partition if available.
3. Set initial and maximum page file size identically to eliminate runtime growth pauses (initial = maximum = 4096 MB on a 2 GB RAM system).
4. Disable System Restore on the data volume if disk space is tight; this also reduces background I/O contention during startup.

6. Verification

After applying each solution, validate with the same measurement procedure. Use a stopwatch and the Process Explorer startup timestamp.

If only one of the hypotheses was the cause, the table will pass on the affected axis only. Repeat the diagnostic flow in Section 4 until all axes pass.

7. Field-Proven Sequence

In most PCS 7 v6.1 SP1 sites with this fingerprint the order below produces a clean resolution without rework:

1. Disable the eSATA RAID (Solution A, Path 1) and re-measure.
2. If no change, configure anti-virus exclusions (Solution B) and re-measure.
3. If no change, reset Winsock and disable NetBIOS over TCP/IP (Solution D) and re-measure.
4. If no change, join the OS station to the domain or harden DCOM (Solution C).
5. If no change, perform SQL Server maintenance (Solution E).
6. If still no change, page file and defrag (Solution F).

In more than 80 % of the field cases reported with this fingerprint, either the eSATA driver or the anti-virus exclusion is the dominant cause, and the resolution is reached at step 1 or 2.

8. Preventive Measures

• Image the OS station with the eSATA subsystem attached before any PCS 7 project is deployed. Re-image whenever storage hardware changes.
• Pin the anti-virus exclusion list from Section 5.2 in the site change-management procedure; treat it as part of the OS image.
• Schedule a monthly WinCC archive database maintenance window with the SQL Server Agent job from Section 5.5.
• Subscribe to Siemens ProductCERT and the PCS 7 security bulletins for the v6.1 SP1 line.
• Document the WinCC archive paths and SQL Server recovery model in the site recovery procedure.
• Maintain a one-page "known-good" image with the eSATA subsystem attached, validated to boot and open a 1 GB project in under 30 s.

Reference: Siemens — SIMATIC PCS 7 V6.1 SP1 Release Notes / Readme.

9. Notes on Migration

PCS 7 v6.1 SP1 is end-of-life and runs on Windows XP SP2, which has been out of mainstream support since 2009 and out of extended support since 2014. Siemens support for the v6.1 line ended years ago. New deployments should use a current PCS 7 release on Windows Server 2019 or later, with on-access anti-virus from the manufacturer-validated compatibility list.

The diagnostic flow above carries forward unchanged to later versions: process wait chains, DPC latency, DCOM hardening, Winsock catalog health, SQL Server recovery model, and page file sizing are all relevant on every modern PCS 7 release. The differences in newer releases are the driver quality (modern NVMe and SATA stacks are far better behaved than the eSATA chipsets of 2007-2008), the default anti-virus posture (Defender ATP now respects process-tagging exclusions), and the default directory service (workgroup is no longer a supported configuration for an OS server).

10. Frequently Asked Questions