Reset_wincc.vbs PCS 7 OS Download: Root Cause and Recovery

Problem Summary: PCS 7 OS Download Blocked by "Target System Active" State

On a PCS 7 V6.1 SP4 system configured with redundant Operator Stations (OS), an engineer attempted to download OS changes from the Engineering Station (ES) to the OS server pair. The download was rejected with the condition "the target system was active." This state persisted even after the engineer performed the standard recovery actions:

• Closing the WinCC Explorer on the affected OS server
• Shutting down and rebooting both OS servers
• Rebooting the Engineering Station

Only after invoking reset_wincc.vbs from the affected OS server did the OS download succeed. This article documents the exact behavior of reset_wincc.vbs, the relationship with CCCleaner.xml, and the field-proven recovery sequence for this class of PCS 7 OS fault.

Root Cause: Stale WinCC Process Holding the Project Lock

The "target system is active" error during an OS change download is generated by WinCC when the runtime database, archive database, or message services on the target server report that the project is loaded and running. In a redundant OS pair, the lock can be held by several process categories:

• A user-mode WinCC Explorer process that did not release its handle to the runtime project file
• A hung archive subsystem instance holding an exclusive write lock on the archive database
• An orphaned child process spawned by a previous runtime load that the service control manager (SCM) did not cleanly terminate
• A non-service executable started by a startup entry that re-creates the lock before WinCC is fully initialized

A standard Windows reboot of the OS server normally releases these handles because the SCM stops WinCC services in dependency order. When the lock survives a full reboot — as in the reported incident — the lock is being re-acquired by a process that the standard shutdown sequence does not address. reset_wincc.vbs addresses this gap by walking the explicit process catalog defined in CCCleaner.xml and terminating every entry in a controlled sequence.

What reset_wincc.vbs Actually Executes

reset_wincc.vbs is a Windows Script Host (WSH) VBScript file shipped with the SIMATIC WinCC / PCS 7 installation. Its function is narrow and explicit:

1. Reads the process catalog from CCCleaner.xml (the WinCC Cleanup configuration file).
2. Iterates each <process> entry in the catalog.
3. Invokes a graceful shutdown signal first; if the process does not exit within a defined timeout, it issues a forced termination.
4. Stops the WinCC service group in the correct dependency order so that, for example, the archive subsystem is halted before SQL Server for the WinCC project database.

The script takes no command-line parameters and produces no GUI feedback. Execution completes silently apart from a brief command-window flash and entries in the Windows Application log.

CCCleaner.xml Structure and Process Catalog

CCCleaner.xml lives in the WinCC installation directory, typically C:\Program Files\Siemens\Automation\WinCC\bin or the PCS 7 equivalent path. The file lists every executable that the cleanup utility recognizes as part of the WinCC runtime. In a full PCS 7 V6.1 SP4 install, the printed list is approximately three pages of process names, covering the following functional groups:

The exact executable names and the catalog length are version-dependent. PCS 7 V6.1 SP4 uses the legacy CC process naming; V7.x and V8.x rename several components but the cleanup mechanism is functionally unchanged.

Step-by-Step Recovery Procedure

Use this procedure only when the standard "Close WinCC Explorer → redownload" path fails and the error "the target system is active" persists.

1. Confirm the ES download is staged. In WinCC Explorer on the ES, verify the project state is "Compiling" complete and the change list is ready. Do not initiate the download until step 6.
2. Identify the master server. On the redundant pair, determine which server currently holds the master role. The error is almost always raised against the master. The standby server will accept the download only after a switchover.
3. Stop user activity on the target server. Disconnect any WinCC clients (standard or WebNavigator) that may be holding read locks. In the OS project editor, verify active clients via Tools → WinCC Explorer → Computer → Runtime Properties.
4. Run reset_wincc.vbs on the locked server.

   cscript "C:\Program Files\Siemens\Automation\WinCC\bin\reset_wincc.vbs"

   Run the script from an elevated command prompt. Allow up to 60 seconds for the script to complete; the runtime depends on the number of catalog entries and the responsiveness of the target processes.
5. Verify the process list is clean. Open Task Manager and confirm that no CC* process, no PDLRT.exe, and no sqlservr.exe instance bound to the WinCC project database is still running. If a process remains, wait 10 seconds and re-check; do not terminate SQL Server manually.
6. Retry the OS download from the ES. In WinCC Explorer on the ES, select the OS server target and trigger the change download. The "target system is active" condition should clear because the process-level lock has been released.
7. Re-verify redundancy state. Once the download completes, open the redundancy diagnostics on both OS servers and confirm the partner connection is "Connected" and the role (Master/Standby) is correctly assigned.

Alternative Recovery Methods (in Order of Preference)

Before resorting to reset_wincc.vbs, attempt the following less invasive methods. The script is an emergency tool and should be used only when the standard path is exhausted.

Verification: Confirm the Lock Is Released

After the script completes, perform the following checks in order. Each must pass before proceeding to the next:

1. Process check. Task Manager shows zero entries for PDLRT.exe, CC*, and any WinCC-instance sqlservr.exe.
2. Service check. services.msc shows the SIMATIC WinCC service group in Stopped state. The SQL Server (WINCC) service may still be Running — this is normal; do not stop it.
3. File handle check. The WinCC project file (<OS_Project>.MCP) and the runtime project database files are not held open. Use openfiles /query /v | findstr "<OS_Project>" to confirm.
4. Download check. From the ES, the OS change download completes without the "target system is active" prompt.
5. Redundancy check. After the download, both servers re-establish their partner connection and the master/standby roles are correct.

Safety Constraints and Operational Guardrails

Because reset_wincc.vbs terminates processes without grace, the following constraints must be observed:

• Do not run the script while the process is in mid-write of an archive segment. Forcing a termination can leave an archive segment in an inconsistent state. Schedule the script during a planned maintenance window, or after stopping user activity.
• Do not run the script on a Master server while the Standby is still online. The redundancy protocol will detect the master's loss of state and trigger an uncontrolled failover. Perform a manual switchover first, or stop the Standby's redundancy service briefly to prevent the failover.
• Do not run the script on a server that is the active node for any PCS 7 batch or route control execution. Batch master role and route control master role must be released before termination.
• Always verify the SQL Server (WINCC) instance is healthy after the script. If the script terminates the SQL Server process itself (catalog-dependent), restart the SQL Server service manually and confirm the WinCC databases attach cleanly.

Process-Level Detail: Observable Behavior at Runtime

For the field engineer who needs to predict the impact of running reset_wincc.vbs, here is the observable behavior at the process level for each functional group:

The grace period before a force-terminate is embedded in the script itself and is not user-configurable through command-line parameters. Customizing the timing requires editing the script (not recommended) or modifying the corresponding catalog entry in CCCleaner.xml (also not recommended).

Why a Reboot Does Not Clear the Lock

The incident report states that a full server reboot did not release the lock. The mechanism is well-understood in PCS 7 V6.x and applies to V7.x / V8.x with the same root cause:

1. During shutdown, the Windows Service Control Manager sends SERVICE_STOP to the SIMATIC WinCC service group.
2. The WinCC service group depends on SQL Server (WINCC instance), and the SQL dependency is correctly honored: SQL stops last.
3. However, the catalog entry for the SQL Server process in CCCleaner.xml can race with the service stop: if the SQL stop is delayed, the script (or the SCM) may force-terminate sqlservr.exe mid-shutdown, leaving a half-attached database.
4. On the next boot, the SQL service starts in recovery mode, and during recovery, the WinCC project database is opened in exclusive mode. This exclusive open is what blocks the OS download even though the user-mode WinCC processes are not running.

The recovery action in this case is to allow SQL Server to complete its recovery cycle (the duration is proportional to the size of the project database and the volume of pending transactions), then re-attempt the OS download. reset_wincc.vbs is effective here because the script's process termination order respects the SQL dependency, avoiding the force-terminate race that the SCM-initiated shutdown may not handle cleanly.

When the Script Does Not Help

There are documented cases where reset_wincc.vbs does not clear the "target system is active" error:

• The lock is on the archive database, not the runtime project. If the archive MDF/LDF files are held by a third-party backup or replication process, the script will not touch that process. Identify the holder with openfiles or Process Monitor and resolve at that level.
• The lock is on the WinCC project file in the ES path, not the OS path. The OS download first stages the change in the ES project directory; if that directory is locked (e.g., by an antivirus scan), the download fails before reaching the OS server. Run the script on the ES, not the OS server, in this case.
• The lock is on the OPC UA / OPC DA gateway. Modern WinCC versions register OPC gateway processes separately; older versions of CCCleaner.xml may not include them.
• The catalog is corrupted. Restore CCCleaner.xml from the WinCC installation media before retrying.

Logging and Post-Event Diagnostics

For each invocation of reset_wincc.vbs, the following log artifacts are produced and should be collected for post-incident review:

• Windows Event Log → Application log. Each terminated process produces a 7034 (service) or 1015 (WinCC) entry.
• WinCC diagnostic files. <OS_Project>_<Computer>_Diagnostic.log in the WinCC project directory records the shutdown sequence.
• SQL Server ERRORLOG. If SQL was force-terminated, the next startup logs a "Recovery completed" entry with the elapsed time; cross-reference this with the event log to confirm clean shutdown.
• Custom reset_wincc.vbs log. The script writes a session log to %TEMP%\reset_wincc_<timestamp>.log; capture this before it is rotated.

FAQ