Resolving OpenPCS 7 SCS Distribution Service Stopped Error

Overview of the OpenPCS 7 SCS Distribution Service Fault

The SCS Distribution Service (SCSDistService) is a Windows background service that ships with SIMATIC PCS 7 and the related OpenPCS 7 connectivity stack. It hosts the OPC HDA Server runtime (SOPCHDASVRPCS.exe) and forwards archived process values, alarms, and events between PCS 7 OS stations, the Process Historian, and downstream Information Server consumers. When the service terminates unexpectedly, OPC HDA clients lose access to historical process data and alarms/events become invisible to higher-level reporting layers.

The fault signature is one of the following Windows Service Control Manager messages logged after the event:

• "The SCS Distribution Service service terminated unexpectedly. It has done this N time(s)."
• "OpenPCS7(SCS Distribution Service) has stopped"
• Service Control Manager Event ID 7034 (unexpected termination) or 7031 (unexpected termination, action taken)

This article walks through a complete root-cause-and-recovery procedure based on the diagnostic path used by Siemens support engineers: process monitoring, performance logging, Windows event triage, version/hotfix validation, configuration verification, and exclusion hardening.

SCS Distribution Service Architecture and Dependencies

The service is part of the SIMATIC PCS 7 historian connectivity layer. It depends on a stable interaction between several subsystems:

Because SCSDistService interacts with COM/DCOM, OPC, and SQL Server, a fault in any neighbouring layer can manifest as a service stop. Confirm the version of your PCS 7 installation against the Siemens Industry Online Support (SIOS) entry for the exact product release before troubleshooting, since known issues and hotfix roll-ups are indexed per PCS 7 major version (V8.2, V9.0, V9.0 SP2, V9.1, V9.1 SP1, V10.0).

Root Causes of SCSDistService Termination

The most common root causes documented across SIOS service requests fall into seven categories. Each one must be confirmed or eliminated in turn:

1. Resource exhaustion — process memory or CPU saturates, the service throws an unhandled exception, and the Windows Service Control Manager kills it.
2. Memory leak in SCSDistService — Private Working Set grows monotonically until the OS commits the process.
3. Software bug / unhandled exception — known defect fixed in a later hotfix.
4. Corrupted configuration — HDA/HA&E segment definitions, archive paths, or DCOM ACL changes.
5. Disk space exhaustion — archive drive hits 0 bytes; the writer thread fails to flush.
6. Antivirus interference — on-access scanning locks or quarantines SOPCHDASVRPCS.exe, the archive database files, or the temporary swap files used by the historian.
7. Windows operating-system-level fault — DCOM hardening (Windows Server 2019/2022), TLS settings, NTLM/Kerberos changes, time drift, or missing OS patches.

Prerequisites

• Local Administrator rights on the PCS 7 station hosting SCSDistService.
• RDP or console access — DCOM and the service interact with the session of the user who started it.
• Read access to the PCS 7 project directory and the archive paths.
• Siemens Support Customer Number (S-CSC) to retrieve hotfixes through SIOS.
• Permission to modify Windows Defender / antivirus exclusions on the host.
• Free disk headroom of at least 20 % on the archive volume.

Step 1: Capture Process State with Task Manager

Use Task Manager (Ctrl + Shift + Esc) as the first-pass diagnostic tool while the system is running:

1. Open Task Manager and switch to the Details tab.
2. Right-click the column header, choose Select columns, and enable: PID, Working set (memory), Private working set, Virtual size, Handles, Threads, CPU time, Start time.
3. Locate SCSDistService.exe and SOPCHDASVRPCS.exe and capture their current values.
4. Re-check every 30 minutes; if Private Working Set climbs steadily between restarts, a memory leak is the prime suspect.
5. Identify any other Siemens processes consuming abnormal CPU or RAM — CCAlgRtServer.exe, WinCCExplorer.exe, SQLSERVR.exe.

Step 2: Long-Term Resource Profiling with Performance Monitor

Task Manager is real-time only. For 24-72 hour trending, use perfmon.msc:

1. Launch Performance Monitor (Start → perfmon.msc).
2. Create a new Data Collector Set (User Defined → New → Manual).
3. Add the following performance counters:

4. Set the sample interval to 60 s and the duration to 72 hours.
5. Save the collector set under C:\PerfLogs\SCSDistService so it does not fill the system drive.
6. Start the collector and let it run until the next service stop occurs.
7. After the next stop, export the .blg file from Reports and correlate the time of stoppage with the resource counters.

Reference documentation: Performance Monitor on Microsoft Learn.

Step 3: Windows Event Viewer Triage

Event Viewer is the highest-value tool for root-causing this fault. Concentrate the search on the time window around each service termination:

1. Open Event Viewer (eventvwr.msc).
2. Inspect Windows Logs → System:

3. Inspect Windows Logs → Application:
4. Filter by Source = SCSDistService, SOPCHDASVRPCS, OPC HDA Server for PCS 7, or .NET Runtime.
5. Capture the Faulting module name and Exception code from every 1000/1025/1026 entry — these directly identify which DLL or .NET assembly raised the unhandled exception.
6. Export the filtered logs to .evtx and forward them to Siemens support when raising a service request.

Reference: Windows Event Logging on Microsoft Learn.

Step 4: Memory Leak Verification (PrivateMemory of SCSDistService)

Siemens support has acknowledged a memory-leak footprint in the SCSDistService process on specific PCS 7 versions. Verify and quantify it as follows:

1. Open PowerShell as Administrator on the affected station.
2. Run the one-liner below to dump the relevant process counters every 5 minutes for 24 hours:

$log = "C:\PerfLogs\SCSDistService_$(Get-Date -Format yyyyMMdd_HHmm).csv"
"TimeStamp,Process,PrivateBytesMB,VirtualBytesMB,Handles,Threads,CPU_Percent" | Out-File $log
while ($true) {
    Get-Process -Name SCSDistService -ErrorAction SilentlyContinue |
        Select-Object @{n='TimeStamp';e={(Get-Date).ToString('s')}},
                      ProcessName,@{n='PrivateBytesMB';e={[math]::Round($_.PrivateMemorySize64/1MB,2)}},
                      @{n='VirtualBytesMB';e={[math]::Round($_.VirtualMemorySize64/1MB,2)}},
                      Handles,Threads,@{n='CPU_Percent';e={(Get-Counter "\Process(SCSDistService*)\% Processor Time").CounterSamples.CookedValue}} |
        Export-Csv -Path $log -Append -NoTypeInformation
    Start-Sleep 300
}

3. After 24 hours, import the CSV into Excel and plot PrivateBytesMB against time.
4. A linear or super-linear growth pattern with no plateau is the canonical signature of the SCSDistService leak.
5. If a leak is confirmed, capture the exact PCS 7 build and pass it to Siemens support — most leaks are gated to a specific version range and resolved by a targeted hotfix.

Step 5: Apply Siemens Hotfixes and Patches via SIOS

Known SCSDistService defects are addressed in PCS 7 hotfix packages. Resolve them as follows:

1. Determine the installed PCS 7 version: open SIMATIC Manager → Help → About or check HKLM\Software\Siemens\Automation\PCS7\Version.
2. Open Siemens Industry Online Support and search for the entry ID of the installed version (for example 6ES7658-… or PCS 7 V9.1 SP1).
3. Filter by Product = SIMATIC PCS 7 and Type = Hotfix / Update; review every entry that mentions SCS Distribution Service, SOPCHDASVRPCS, OPC HDA, or memory leak.
4. Download the relevant .exe / .msp, copy it to the affected station, and run it elevated.
5. Reboot if the hotfix requires it (most OPC/DCOM hotfixes do).
6. Verify by re-running the leak monitoring script for another 24 hours.

Reference: SIMATIC PCS 7 product page on SIOS.

Step 6: Verify HDA and HA&E Collection Configuration

A misconfigured tag or archive segment can crash the OPC HDA Server thread and tear down the service. Verify the configuration:

1. Open WinCC Explorer on the OS or the Process Historian station.
2. Right-click Tag Logging → Properties; confirm that the archive paths point to existing, writable folders.
3. Right-click Alarm Logging → Properties; verify the archive segments are not larger than the partition can hold.
4. Open the SCS Distribution Service configuration tool (start menu entry under Siemens Automation → SCS Distribution Service):

5. If any field was recently changed, revert to the last known good configuration (export .xml) and restart the service.

Step 7: Disk Space and Archive Volume Health Check

A full archive drive stalls the writer thread, which often propagates up as a service crash:

1. Open diskmgmt.msc and confirm free space on every volume that hosts archive files, the PCS 7 project directory, and the SQL Server database files.
2. Run fsutil volume diskfree C: (and for each archive volume) to confirm there is at least 20 % free.
3. Inspect the SQL Server log for 9002 (transaction log full) and 1105 (could not allocate space).
4. Move or archive old segments, then shrink the SQL transaction log with DBCC SHRINKFILE (after a full backup).
5. Re-run the WinCC Archive Configurator to ensure segments cycle correctly.

Step 8: Antivirus and Security Software Exclusions

Real-time on-access scanning of database files and OPC executables is a frequent, silent cause of SCSDistService crashes. Add the following paths to the antivirus exclusion list on the host and any scanning agent that touches the archive share:

Configure exclusions through Microsoft Defender Antivirus exclusion documentation or your third-party antivirus console. After adding exclusions, perform a one-shot SIGVERIFY-free restart of the service so the new rules apply from process init.

Step 9: Controlled Service Restart Procedure

After the diagnostic pass, restart the service in a controlled fashion:

sc query SCSDistService
sc stop SCSDistService
timeout /t 15 /nobreak
sc start SCSDistService
sc query SCSDistService

If the service fails to start, capture the Windows Installer / Service Control Manager errors immediately; they appear in Event Viewer within seconds. Do not loop-restart the service — three rapid failed start attempts will mark the service as disabled by recovery policy.

Configure the recovery tab of the service so that the first failure restarts, the second failure restarts after 60 s, and the subsequent failure runs a recovery command (for example a script that collects the dump and emails it to engineering).

Step 10: Capture a Process Dump for Siemens Support

When the fault recurs after hotfixes, exclusions, and configuration, capture a full user-mode dump and send it to Siemens:

1. Download Sysinternals ProcDump.
2. From an elevated command prompt:

procdump -ma -t -e 1 -f "" -s 30 -n 3 SCSDistService.exe C:\Dumps\SCSDistService.dmp

3. The -t switch triggers a dump on unhandled exception; -e 1 requests a mini-plus dump; -n 3 collects three dumps before stopping.
4. Compress the .dmp files and attach them to a Siemens service request that includes the PCS 7 version, the Event Viewer .evtx, and the perfmon .blg from Step 2.

Verification and Ongoing Monitoring

After applying the corrective actions, verify the fix:

1. Service uptime — confirm SCSDistService has been running for at least 72 hours without unexpected stops.
2. Memory trend — replay the PowerShell leak script and verify PrivateBytes plateaus instead of climbing.
3. Event Viewer — confirm zero new Event ID 7034 / 7031 entries from SCSDistService in the past 72 hours.
4. OPC client test — connect an OPC HDA / HA&E client (for example the OPC Scout V10) and read a few archived tags and alarms to confirm round-trip functionality.
5. Information Server — open a published report that consumes archived data and confirm it returns current values.

For ongoing visibility, keep the perfmon Data Collector Set scheduled to run on a recurring basis and forward a daily summary by email. Combined with a Watchdog that alerts on Event ID 7034, this gives engineering lead time to act before operators notice a reporting gap.

Troubleshooting Matrix

Frequently Asked Questions