C135 PCS 7 (PCS7)
6C
6 Cielo Ciencia y Tecnología
·Publicada en C135 PCS 7 (PCS7)

How to Diagnose and Resolve 'Restart of the System is Requested by WinCC' Alarms

How to Diagnose and Resolve 'Restart of the System is Requested by WinCC' Alarms

To diagnose and resolve the recurring prompt 'A restart of the system is requested by WinCC' when deactivating OS Runtime, engineers must investigate WinCC redundancy synchronization timeouts and unreleased database handles. In redundant OS server environments, this prompt indicates that a critical WinCC background process (such as CCRedSync.exe, CCAlgRtServer.exe, or CCProjectMgr.exe) encountered a fatal state or failed to complete a graceful handshake with the partner server during runtime termination, forcing a system reboot request to prevent split-brain database corruption. The resolution involves checking WinCC_Sys_01.log and CCRedSync.log, verifying network adapter metric priorities, ensuring the redundancy serial/Ethernet heartbeat cable is functional, and executing CCCleaner.exe to terminate locked background processes cleanly.

Table of Contents

Mechanism of the WinCC Restart Request Safeguard

During runtime operation or deactivation, SIMATIC WinCC coordinates numerous interconnected background processes, database engines (Microsoft SQL Server), and inter-process communication (IPC) channels.

If an unexpected condition arises where:
* Shared memory becomes corrupted,
* A critical process aborts without cleanly releasing its database transaction locks, or
* The redundancy synchronization engine (CCRedSync.exe) detects that local runtime cannot guarantee data consistency with the partner server,

WinCC issues the system-modal message: 'A restart of the system is requested by WinCC'. This safeguard is deliberately designed to prevent an OS server from operating in a compromised state where archive data, alarm sequences, or operator actions could deviate from the partner server, leading to severe plant visualization discrepancy.

Root Causes in Redundant Server Configurations

In the vast majority of field cases, restart requests occur during runtime deactivation on redundant OS servers due to one of three conditions:

1. Redundancy Synchronization Handshake Deadlock

When deactivating Runtime on Server A, CCRedSync.exe must notify Server B that Server A is entering maintenance mode. If Server B is unreachable, slow to respond, or experiencing network packet drops on the terminal bus or redundancy link, the deactivation sequence exceeds internal timeout thresholds, triggering a forced restart.

2. Network Adapter Binding and Multi-Homing Misconfiguration

If the redundant servers have multiple network interface cards (Terminal Bus, Plant Bus, Redundancy Link) but the Windows network adapter binding order or metric settings are incorrect, WinCC IPC calls may attempt to route internal redundancy traffic across the wrong subnet.

3. File and Database Locks by Lingering Services

If external software (such as third-party backup agents, antivirus file scanners, or OPC clients) locks the WinCC project directory (<Project>\ArchiveManager), background services like CCAlgRtServer.exe cannot detach cleanly, causing a shutdown timeout.

Diagnostic Inspection: WinCC Logs and Windows Event Viewer

To pinpoint the exact component triggering the restart request:

  1. Navigate to the WinCC diagnostic directory:
    C:\Program Files (x86)\Siemens\WinCC\Diagnose
  2. Open WinCC_Sys_01.log:
    * Search for timestamped entries immediately preceding the restart dialog.
    * Look for entries containing ERROR, FATAL, or ExitProcess requested.
  3. Open CCRedSync.log:
    * Inspect the synchronization state machine log. Look for messages such as Connection to partner server broken or Sync timeout exceeded.
  4. Open Windows Event Viewer (eventvwr.msc):
    * Under Application, inspect error logs from sources WinCC, SIMATIC HMI, or MSSQL$WINCC.
    * Under System, check for network link drops or driver faults on Intel/Siemens NICs.

Step-by-Step Remediation and Redundancy Verification

Follow this structured remediation workflow to eliminate recurring restart requests:

Step 1: Terminate Hanging Processes Safely

  1. When the restart prompt appears, do not simply execute an immediate hard reboot.
  2. If WinCC Explorer is unresponsive, launch an administrative Command Prompt:
    cmd "C:\Program Files (x86)\Siemens\WinCCin\CCCleaner.exe"
  3. Allow CCCleaner to cleanly terminate and dismount database engines.

Step 2: Validate Network Adapter Priority and Metrics

  1. Open Control Panel -> Network and Sharing Center -> Change adapter settings.
  2. Press Alt -> Advanced -> Advanced Settings (or configure interface metrics via PowerShell):
    * Terminal Bus NIC must have the highest priority.
    * Redundancy Link NIC must have dedicated point-to-point addressing (e.g., 192.168.222.1 and 192.168.222.2) with gateway left blank.
  3. Verify that the physical redundancy cable (cross-over Ethernet cable or RS-232 serial cable) is firmly connected and exhibits zero packet loss.

Step 3: Test Redundancy Deactivation Gracefully

  1. Open WinCC Explorer on the redundant server.
  2. In the Redundancy editor, verify that 'Activate Redundancy' is checked and the partner computer name is correct.
  3. Test deactivating Runtime: WinCC will now execute the partner handshake cleanly and return to engineering mode without requesting a system restart.

Diagnostic File and Failure Mechanism Reference Matrix

The following table outlines the diagnostic files, triggering components, and resolution procedures for WinCC restart requests:

Diagnostic FileResponsible ProcessTypical Error SignatureCorrective MeasureWinCC_Sys_01.logCCProjectMgr.exeEmergency exit called by componentCheck preceding error lines for culprit DLLCCRedSync.logCCRedSync.exePartner server not responding to shutdownInspect redundancy cable, NIC binding orderWinCC_Sys_02.logCCAlgRtServer.exeArchive database dismount timeoutExclude ArchiveManager from antivirus scansWindows Event LogMSSQL$WINCCSQL Server I/O error or lock conflictVerify disk health, increase disk I/O throughputSIMATIC_S7_Protocol_Suite.logCommunication DriverChannel disconnect during shutdownEnsure clean AS communication termination

Resolving communication bottlenecks ensures graceful server deactivation without operational interruptions.

Verification

To verify that the restart request issue is resolved:
1. With both redundant OS servers running in full Runtime, initiate Runtime deactivation on the standby server via WinCC Explorer.
2. Confirm that Runtime deactivates completely within 30 to 60 seconds without prompting for a system restart.
3. Check WinCC_Sys_01.log to confirm that all WinCC subsystems reported Shutdown completed successfully.
4. Reactivate Runtime and verify that redundancy synchronization completes automatically (Redundancy State: Synchronized).

Limitations and Operational Precautions

  • Never disable WinCC Redundancy in the editor as a permanent workaround; running redundant servers without active redundancy leads to divergence in historical data.
  • Avoid force-killing sqlservr.exe via Windows Task Manager, as hard termination can corrupt the runtime SQL database (.mdf/.ldf).
  • Ensure that third-party antivirus software is configured with Siemens-mandated folder and process exclusions.
  • Always schedule server maintenance during low-activity operating windows to prevent operator disruption during server role switchovers.

Engineer FAQ

Why does WinCC request a reboot instead of just closing the application?

When a critical subsystem experiences an unrecoverable IPC deadlock or database inconsistency, an operating system restart is requested to ensure that all shared memory handles and services are reset to a clean state.

Can a faulty serial or Ethernet redundancy cable trigger this error?

Yes. If the dedicated redundancy connection fails, the servers rely solely on the terminal bus. If terminal bus traffic is congested, synchronization handshakes time out during deactivation, triggering a reboot request.

What does CCCleaner actually do?

CCCleaner systematically closes lingering WinCC processes (CCProjectMgr.exe, CCDataServer.exe, etc.) and unhooks shared memory segments without requiring a full Windows restart.

Technical References

Related Articles

Related Tags

  • WinCC Restart Request
  • CCRedSync
  • WinCC Redundancy
  • CCCleaner
  • OS Runtime Deactivation
6 respuestas