Troubleshooting WinCC OPC Timeout Errors 1007006 and 1007008

Troubleshooting WinCC OPC Timeout Errors 1007006 and 1007008

WinCC Runtime environments connected to upper-level systems through OPC DA frequently exhibit progressive slowdown, unresponsive mouse input, and full system freezes when variable requests accumulate without being answered. The WinCC diagnostic log captures this exact signature through two paired event IDs: error code 1007006 (variable timeout) followed minutes later by error code 1007008 (EndAct timeout). When this pair repeats across multiple days in the same project, the workstation will eventually stop processing input and require a hard reboot. This article decodes the diagnostic file format, maps the error IDs to their WinCC runtime behavior, isolates the OPC and script execution root causes, and walks through field-proven remediation procedures.

Problem Description

On a WinCC station (project LIETTAMO) the operator reported the following reproducible failure mode:

1. Runtime screens begin responding slowly to mouse clicks and keyboard input.
2. Mouse cursor movement becomes jerky; pop-up windows take several seconds to appear.
3. WinCC gradually becomes unresponsive and the OS itself starts freezing.
4. The only recovery is a hard reboot of the WinCC station.

Inspection of the WinCC diagnostic directory revealed two repeating entries on every failure date:

255,11.03.2008,08:56:05:890,1007006,4,,LIETTAMO,SCRIPT,Variable KOE_1_VESI timeout
255,11.03.2008,08:57:05:968,1007008,4,,LIETTAMO,SCRIPT,EndAct Timeout
255,05.04.2008,11:47:42:359,1007006,4,,LIETTAMO,SCRIPT,Variable KOE_1_VESI timeout
255,05.04.2008,12:01:47:062,1007008,4,,LIETTAMO,SCRIPT,EndAct Timeout

The pattern is identical on both incident days, separated by approximately one minute between the variable timeout (1007006) and the script engine timeout (1007008). This is a classic OPC request back-pressure signature: WinCC issues a request for the external tag KOE_1_VESI, the OPC DA server fails to acknowledge it within the configured timeout, and the script execution context waiting on the read hangs until WinCC's internal action handler watchdog expires. Repeated occurrences exhaust the script thread pool and starve the Win32 message pump, which is why both the HMI and the underlying Windows desktop become unresponsive.

Understanding the WinCC Diagnostic File Format

Every WinCC station writes its runtime status into a comma-separated log file inside the project diagnose directory. Each line is an event record with the following positional fields:

Filter the file by source component SCRIPT and look for repeated error IDs in the 1007xxx range. A non-empty source component on every entry confirms the failure originates inside the WinCC action/script handler rather than from a third-party OPC client or a graphics driver fault.

Error Code Reference

The hexadecimal form 0x80040154 is Microsoft's standard REGDB_E_CLASSNOTREG HRESULT. It surfaces when the OPC client (WinCC) tries to instantiate the WinCC OPC DA Automation Server (OPC.DA.Server) and the COM catalog has no CLSID entry. This often accompanies error 1007006 after a workstation rebuild or a Windows update that breaks DCOM.

Root Cause Analysis

The two failure scenarios below account for the majority of field incidents matching this signature. Diagnose which one applies before changing configuration.

Cause 1 — External OPC Server Not Responding

The tag KOE_1_VESI is mapped through an OPC DA channel from a third-party or higher-level SCADA. The WinCC action issues a synchronous read, the upper-level system does not return a value within the action timeout, and the action hangs. Subsequent actions queued on the same script thread accumulate until WinCC exhausts its dispatcher threads.

Symptoms:

• Variable timeouts correlate with network or controller outages on the upper-level system.
• Only specific tags (here KOE_1_VESI) trigger 1007006 — other OPC tags update normally.
• Errors disappear when the upper-level system is restarted.

Cause 2 — Script Holding a Synchronous Lock

A C-action or VBScript uses a blocking pattern such as:

' Anti-pattern: synchronous read inside a cyclic action
Sub OnTimeTrigger(ByVal Item)
    Dim val
    val = HMIRuntime.Tags("KOE_1_VESI").Read  ' blocks if OPC is slow
    HMIRuntime.Tags("KOE_1_VESI_DISPLAY").Write val
End Sub

If the OPC layer stalls, Read does not return. The action wrapper marks the script as still running, the watchdog emits 1007008, and the runaway action continues to consume a thread. Multiple such actions compound into the observed OS-level freeze.

Cause 3 — WinCC OPC Server Not Registered

When error 1007006 is accompanied by HRESULT 0x80040154, the root cause is a broken COM registration. This is independent of network health and must be fixed by re-registering the WinCC OPC components. Verify this branch first if the workstation has been recently patched, reimaged, or upgraded.

Step-by-Step Remediation

Step 1 — Confirm the Failing Tag in Isolation

Create a single-screen test picture that contains only one I/O field bound to KOE_1_VESI and one status field displaying the Quality Code returned by WinCC.

1. Open WinCC Explorer and create a new picture Diagnose_KOE_1_VESI.PDL.
2. Insert an I/O field with tag KOE_1_VESI.
3. Insert a second output field configured as "Output" with the dynamic property Quality Code.
4. Activate Runtime and observe whether the I/O field shows --- (bad quality) and the Quality Code shows 0xC0 (Bad - Comm Failure) or 0x00 (Good).

If Quality Code stays at 0xC0 while the upper-level system reports the tag as healthy, the OPC DA channel is the bottleneck — proceed to Step 2. If Quality Code is good but the action still hangs, the script is the bottleneck — proceed to Step 3.

Step 2 — Repair the OPC DA Channel

1. Open WinCC Explorer > Tag Management > OPC > OPC Groups.
2. Right-click the channel serving KOE_1_VESI and select Properties.
3. Increase the Update interval for the affected group from the default 1 s to a value that matches the upper-level system's guaranteed response time (typically 2-5 s).
4. Switch the group from "On Change" to "On Demand" if the tag is only read by scripts, not displayed on graphics. This prevents WinCC from polling when no consumer is active.
5. On the OPC server side, verify that the tag KOE_1_VESI is exposed with a valid Item ID, not stripped by a namespace prefix mismatch.
6. Run OPC Scout (part of the SIMATIC NET / OPC Foundation test suite) and try to subscribe to KOE_1_VESI directly. If OPC Scout also fails, the fault is in the upper-level server.

Step 3 — Refactor Blocking Scripts

Replace every synchronous read inside a cyclic action with an asynchronous or buffered pattern:

' Recommended: event-driven trigger via tag change
Sub KOE_1_VESI_Change(ByVal Item)
    Dim val
    val = Item.Value            ' cached snapshot, no network call
    If Item.Quality = 0 Then
        HMIRuntime.Tags("KOE_1_VESI_DISPLAY").Write val
    Else
        HMIRuntime.Tags("KOE_1_VESI_DISPLAY").Write 0
        HMIRuntime.Trace "KOE_1_VESI bad quality: 0x" & Hex(Item.Quality) & vbCrLf
    End If
End Sub

For actions that must poll, wrap the read in a bounded retry loop that never exceeds the watchdog window (default EndAct timeout is 10 s, configurable under Computer > Properties > Graphics Runtime > Actions):

Dim t0, waited
t0 = Timer
Do
    If HMIRuntime.Tags("KOE_1_VESI").Quality = 0 Then
        Exit Do
    End If
    waited = Timer - t0
    If waited > 2 Then Exit Do     ' never wait longer than 2 s inside action
Loop

Step 4 — Re-Register WinCC COM Components

If the diagnostic log shows HRESULT 0x80040154, the WinCC OPC Automation Server is unregistered.

1. Close WinCC Runtime and stop the CCAlgRtHmi, CCArchiveConn, and CCOPCServer services.
2. Open an elevated command prompt.
3. Re-register the OPC server binaries:

   cd %ProgramFiles%\Siemens\Automation\WinCC\opc\binsrv
   regsvr32 /s OpcEnum.dll
   regsvr32 /s OPCDAAuto.dll
   regsvr32 /s SiemensOPCDAClient.dll

4. Restart the WinCC services and verify with dcomcnfg.exe that the OPC DA Server CLSID is present under Component Services > Computers > My Computer > DCOM Config.
5. Confirm DCOM launch and access permissions allow the WinCC user (typically CCUser or the logged-on operator) to start the server.

Step 5 — Tune WinCC Dispatcher and Runtime Watchdogs

Open Computer > Properties > Runtime and adjust:

Verification Procedure

After applying the steps above, prove the fix is durable before returning the station to production:

1. Activate Runtime with the test picture from Step 1 open.
2. Force the OPC DA server to stop responding (disconnect the network cable to the upper-level system).
3. Confirm within the test picture that the Quality Code drops to 0xC0 within 3 s and no new 1007006 line is appended to the diagnostic log for at least 10 minutes.
4. Restore network and confirm Quality Code returns to 0x00 and the display value updates.
5. Repeat the fault injection three times in succession. If WinCC stays responsive through all three cycles, the dispatcher is no longer being saturated.
6. Run the system for 72 hours under normal load. Compare the diagnostic log size and the count of 1007006 / 1007008 lines to the baseline. A healthy station should produce zero such lines.

Performance Monitoring Recommendations

• Add an alarm logging message inside every script that catches a bad-quality read using HMIRuntime.Trace. Tracing writes to WinCC_RT_<computername>.log under <project>\diagnose and gives you a per-tag history that the binary OPC channel log lacks.
• Configure Windows Performance Monitor with the counters \Process(CCAlgRtHmi)\% Processor Time, \Process(CCExplorer)\Thread Count, and \System\Context Switches/sec. A sustained thread count above 250 on CCAlgRtHmi indicates a leaking script thread.
• Schedule a weekly task that rotates and zips the diagnose directory. Rotated logs make it trivial to compare incident timestamps to operator shift reports.

Troubleshooting Matrix

FAQ