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

How to Diagnose and Fix WinCC Runtime Deactivation Freezes and Hanging Shutdowns in PCS 7

How to Diagnose and Fix WinCC Runtime Deactivation Freezes and Hanging Shutdowns in PCS 7

In SIMATIC PCS 7 OS Servers, WinCC Runtime failing to deactivate—where clicking 'Deactivate' causes the dialog to freeze, stall at 35%, or hang indefinitely—is caused by blocked Global Script threads, corrupted SQL database transaction logs (.ldf), or orphaned DCOM processes. Deactivation proceeds in reverse startup order; if a script engine hangs or an archive service cannot flush buffers, the shutdown sequence blocks. Diagnosing the freeze requires checking apdiag.exe for hung scripts and inspecting PMDeactivate.log. The permanent resolution involves performing a 'Save As... With Reorganization (slow)' in SIMATIC Manager. Note: On systems with SIMATIC Process Historian, specific GUID migration scripts must be executed following reorganization.

Table of Contents

WinCC Runtime Deactivation Sequence Architecture

Deactivating a SIMATIC WinCC / PCS 7 Operator Station is a complex, orchestrated shutdown procedure managed by the WinCC Project Manager (CCProjectMgr.exe).

Deactivation does not terminate processes arbitrarily; it shuts down subsystems in the strict reverse order of their startup configuration:
1. Graphics Runtime (PDLRT.exe): Closes open picture windows and unloads ActiveX/OCX controls.
2. Alarm Logging Runtime (CCAlgRtServer.exe): Flushes incoming/outgoing alarm queues and closes active message journal tables.
3. Tag Logging Runtime (CCTlgServer.exe): Flushes compressed historical trend segments from memory buffers into the active SQL Server database archive segments.
4. Global Script Runtime (pass-cs.exe / ccvbs.exe): Terminates cyclic and tag-triggered C-actions and VBS-actions.
5. Database Manager & Project Server: Detaches project SQL databases (.mdf/.ldf) and releases shared memory mutexes.

If any single subsystem fails to acknowledge termination within its allotted timeout, the entire deactivation sequence freezes.

Root Cause Analysis for Deactivation Freezes and Hangs

When an engineer clicks 'Deactivate Runtime' and the progress popup remains frozen for hours—forcing the engineer to resort to the emergency script RESET_WINCC.VBS—the failure typically traces to one of three mechanisms:

1. Global Script Deadlocks or Infinite Loops

If a custom C-script or VBScript contains an unbounded while loop, calls a blocking Windows API modal dialog (such as MessageBox), or attempts to access a disconnected network resource/database, the script thread hangs. When CCProjectMgr signals Global Script to exit, the script engine waits indefinitely for the active thread to complete.

2. SQL Server Transaction Log Corruption and Buffer Deadlocks

During runtime, Tag Logging and Alarm Logging stage high-frequency process telemetry in RAM buffers. During deactivation, CCTlgServer must commit these transactions to the SQL Server database. If the transaction log (.ldf) has grown excessively large, fragmented, or entered a corrupt state, SQL Server deadlocks during transaction commit, stalling deactivation (frequently observed at exactly 35% progress).

3. Orphaned Background Processes

If background services (such as IMServerX, ASOSHeartbeat, or CCRedSync) encounter memory corruption, they fail to release IPC handles, locking CCProjectMgr in an infinite wait state.

Diagnostic Tools: apdiag and System Deactivate Logs

Before forcing an ungraceful reset, engineers must identify the exact offending subsystem:

Using apdiag.exe for Script Diagnostics

  1. While WinCC Runtime is active, navigate to:
    C:\Program Files (x86)\Siemens\WinCC\utools\apdiag.exe.
  2. Launch apdiag.exe and select menu Output Window.
  3. Select Diagnose -> Trace.
  4. Observe the trace console: any script generating memory access faults, unhandled exceptions, or execution timeouts will be logged with its script name and line number.

Inspecting WinCC Deactivation Logs

Navigate to the diagnostic log directory: C:\Program Files (x86)\Siemens\WinCC\Diagnose:
* PMDeactivate.log: Records the exact second each subsystem was commanded to stop and which subsystem failed to acknowledge.
* PMDiagnose.log: Details internal process manager interlocks.
* WinCC_Sys_01.log: Records database errors, disk space warnings, and license violations.

Step-by-Step Resolution via Slow Project Reorganization

To permanently eliminate deactivation hangs caused by database fragmentation and project corruption:

Step 1: Execute Project Slow Reorganization in SIMATIC Manager

  1. Gracefully close all applications and ensure WinCC is stopped (use RESET_WINCC.VBS if currently frozen).
  2. Open SIMATIC Manager.
  3. Select menu File -> 'Save As...'.
  4. In the dialog, select the checkbox: 'With Reorganization (slow)'.
  5. Choose a new destination folder and click OK.
  6. SIMATIC Manager reads every database table, purges deleted record fragments, rebuilds internal indexes, and writes a pristine, contiguous project database.

Step 2: Critical Precaution for Systems with SIMATIC Process Historian

  • Warning: Executing a slow reorganization generates a new project identification GUID for the WinCC OS project.
  • If the plant utilizes SIMATIC Process Historian (PH):
  • Process Historian binds to the OS Server via its original project GUID.
  • Creating a duplicate project via reorganization causes Process Historian to reject subsequent delta downloads.
  • You must execute the Siemens Process Historian project realignment script (available from Siemens Customer Support) or contact Siemens Technical Support before downloading a reorganized project to a system connected to an active Process Historian.

Deactivation Component Sequence and Diagnostic Matrix

The following table outlines the deactivation stages, typical freeze points, and corrective procedures:

Deactivation PhaseProgress %Typical Faulting SubsystemDiagnostic IndicatorCorrective ProcedureStep 1: Graphics Shutdown0% - 15%PDLRT.exe / Custom OCXProcess picture fails to closeRemove non-certified ActiveX controlsStep 2: Alarm Logging15% - 30%CCAlgRtServer.exeStalls while closing alarmsRun OS compile with memory resetStep 3: Tag Logging30% - 50%CCTlgServer.exe / SQLHangs at 35%; high disk I/OExecute Slow ReorganizationStep 4: Global Script50% - 80%pass-cs.exe / ccvbs.exePMDeactivate.log shows script waitDiagnose hanging loops via apdiag.exeStep 5: Database Detach80% - 100%CCProjectMgr.exeSQL handles lockedPurge <Project>.dcf file

Addressing the specific faulting subsystem restores predictable, rapid deactivations.

Verification

To verify that WinCC Runtime deactivates cleanly:
1. Activate WinCC Runtime on the OS Server.
2. Allow runtime to run for at least 15 minutes to generate active trend and alarm journals.
3. Initiate deactivation via WinCC Explorer or the runtime exit button.
4. Observe the deactivation progress bar: verify that it advances steadily through all stages and closes completely within 30 to 60 seconds.
5. In Windows Task Manager, verify that all WinCC processes (PDLRT.exe, CCAlgRtServer.exe, CCTlgServer.exe) terminate cleanly without residual orphaned processes.

Limitations and Operational Precautions

  • Avoid using RESET_WINCC.VBS as a standard operational shutdown method; killing processes forcefully risks corrupting open SQL database segments.
  • Always archive the multiproject (File -> Archive) before executing 'Save As... With Reorganization (slow)'.
  • Never run disk defragmentation software on an active WinCC runtime machine while projects are running.
  • Verify that antivirus exclusions are strictly configured so security software does not lock database files during deactivation.

Engineer FAQ

Why does WinCC deactivation frequently hang at exactly 35%?

Deactivation at 35% corresponds to the Tag Logging shutdown phase. If historical archive segments in SQL Server are fragmented, corrupted, or locked, the transaction flush blocks indefinitely.

What does RESET_WINCC.VBS actually do?

RESET_WINCC.VBS is an emergency utility that forcibly terminates all running Siemens HMI processes and releases shared memory mutexes. It should only be used when normal deactivation completely fails.

Why does slow reorganization create issues with Process Historian?

Slow reorganization rebuilds the project database with a new unique internal identifier (GUID). Process Historian relies on the original GUID to catalog incoming archives, requiring a database update script to re-link.

Technical References

Related Articles

Related Tags

  • WinCC_Deactivation
  • RESET_WINCC
  • apdiag
  • Slow_Reorganization
  • Process_Historian
6 respuestas