Resolving WinCC 7 Script Overflow Error 1007000: ActionOverflow

When a WinCC 7.x runtime reaches the ceiling of its internal action queue, the GSC (Global Script C) and VBScript schedulers stop dispatching new triggers and the process alarm list freezes at the offending event. The most common fingerprint is message number 1007000 with the text "SCRIPT:<ComputerName>:OVERFLOW; number: 1007000; ActionOverflow: More than 10000 Actions to work". This article walks through the underlying scheduler architecture, the diagnostic flow, the immediate recovery steps, and the long-term refactor pattern that prevents recurrence. Documentation references throughout point to the official Siemens Industry Online Support portal and the SIMATIC HMI product pages.

1. Problem Overview

WinCC 7.0 (and the service packs up to WinCC 7.5) uses a single-threaded C-script engine plus a separate VBScript engine to execute "actions" — the on-event or on-cycle handlers attached to graphics, tags, alarms, and global schedulers. Each time a scheduled action fires, it occupies a slot in the script queue. If the runtime cannot drain the queue faster than triggers are arriving, the queue depth grows until it crosses the hard-coded ceiling. WinCC raises the 1007000 alarm and refuses to dispatch new actions until the operator (or a self-healing timer) clears the alarm and the queue returns to a normal depth.

Visible symptoms in a typical operator station:

• The process alarm list (Alarm Logging control) stops accepting new entries at the overflow event.
• Picture changes, tag evaluations, and dynamic dialogs freeze or appear "stuck" on the last evaluated value.
• The WinCC Explorer status bar reports Runtime: Overflow.
• Diagnostics files in the project directory (<Project>\diagnose\) log "Script: More than 5000 actions in work" well before the 10,000 hard limit is reached.
• CPU on PDLrt.exe pins at 100 %, but tag values from the PLC continue to update — only the script plane is blocked.

2. WinCC Action Queue Architecture

To understand the overflow you need to know how WinCC schedules action code. There are three execution planes inside the WinCC runtime, all sharing a single dispatcher thread.

Both planes share a single WinCC scheduler thread. When an action takes longer to complete than the trigger interval — for example, a 2-second C-action firing on a 1-second cycle — every subsequent tick queues another instance of the same action. Queue depth grows linearly with the duration of the overload and explodes if an action enters a synchronous wait: a MSComm read on a hung serial port, a Wait in ANSI-C, or a VBScript call that touches the HMIRuntime COM proxy while another thread holds it. The internal counter is exposed through the WinCC internal tag @SCRIPT_COUNT_TAGS and through the Windows performance counter set WinCC:Script. When ActionsInWork crosses 5,000, WinCC writes a warning to WinCC_Sys_01.log. When it crosses 10,000, alarm 1007000 fires and the action scheduler enters frozen mode until it is reset.

3. Error 1007000: ActionOverflow Decoded

The alarm text is built from three fields that map directly to the WinCC Alarm Logging schema:

1. Source prefix — SCRIPT:MyComputer. MyComputer is the local WinCC server name; in a redundant pair the client machine is also embedded when the alarm originates on a distributed station.
2. Number — 1007000. Reserved by WinCC Alarm Logging for the global script overflow condition. It is not project-specific; you will see the same number on every WinCC instance that reaches the ceiling.
3. Comment — ActionOverflow: More than 10000 Actions to work. The hard ceiling is 10,000 in WinCC 7.0 SP0 through 7.4. In WinCC 7.5 the ceiling was raised to 20,000 but the alarm number is unchanged. Versions earlier than 7.0 used 5,000 as the hard limit; the legacy FAQ "WinCC error message 'Script: More than 5000 actions in work' in the diagnostics files?" still applies to those releases and is a direct ancestor of the modern 1007000 message.

4. Root Cause Analysis

Every documented 1007000 case in WinCC 7.x reduces to one of three patterns. Use this matrix to triage the project before re-activating the runtime.

Field experience: more than 90 % of 1007000 incidents are caused by the third pattern — an if/else or Do While construct that was written to "check for something" and was wired to a fast on-change trigger. WinCC has no pre-emptive scheduler, so the action never yields until the loop terminates or the runtime times out the action at the configurable action timeout (default 30 s, exposed in the Computer properties under Runtime Settings > Scripts). For more background, see the WinCC scripting pages in the Siemens Industry Online Support knowledge base.

5. Diagnostic Procedure

Use this ordered list the moment alarm 1007000 appears in the process alarm list. The goal is to capture evidence before the runtime is restarted.

1. Open the project diagnose directory: C:\Program Files (x86)\Siemens\Automation\WinCC\WinCCProjects\<Project>\diagnose\. Sort by date and collect WinCC_Sys_*.log, APLog_*.txt, and PDLrt.log.
2. Search the syslog for 1007000 and for the string "More than 5000 actions". Note the timestamp delta between the warning and the alarm — it is your window-of-opportunity metric.
3. Open WinCC Explorer and read the internal tag @SCRIPT_COUNT_TAGS. A value pinned at 10,000 confirms the runtime is still in frozen mode.
4. From the Windows Performance Monitor, add the counter WinCC:Script\ActionsInWork on the WinCC server process. Capture a 5-minute trace.
5. Cross-reference the actions that fire in the same 100 ms window as the warning. In the Graphics Designer, every action with a trigger interval shorter than its average duration is a suspect.
6. If a third-party driver is in use (OPC, Modbus TCP, S7-PDIAG), check the vendor log for retry storms. A flooded upstream source can synthesize tag-change events faster than the script can consume them.
7. Dump the process list and capture a userdump of PDLrt.exe via procdump -ma PDLrt.exe pdlsvc.dmp from Sysinternals. The dump can be analysed off-line with WinDbg to enumerate the script call stack.

Document the findings in the project change log. WinCC 7.x does not rotate PDLrt.log by default, so if you wait until the next shift, the evidence is gone.

6. Immediate Recovery: Clearing the Overflow

There is no supported hot key to drain the queue. The two production-grade recovery paths are listed below; pick the path that matches your project's availability constraint.

6.1. Acknowledge the alarm and reload the script engine

1. In the runtime, acknowledge alarm 1007000. This stops new alarm insertions but does not clear the queue.
2. In WinCC Explorer, right-click the server and select Runtime > Restart Script Processing. In WinCC 7.0 SP0-SP3 this option is greyed out — proceed to step 3 instead.
3. If the option is unavailable, deactivate and reactivate Runtime from the Explorer. The picture cache is preserved, but the action queue is rebuilt.
4. After reactivation, monitor @SCRIPT_COUNT_TAGS. The value should drop below 1,000 within 30 s of restart if the underlying cause is fixed.

6.2. Reset the alarm archive slice

1. Open the Alarm Logging editor.
2. Select the short-term archive that holds the 1007000 entry.
3. Use File > Save As to back the archive up, then File > Reset to clear the slice. This is required if the alarm list is "stuck" — WinCC Alarm Logging reads the archive head pointer and refuses to skip a frozen entry.
4. Re-trigger the archive rotation so a fresh slice is opened. The overflow entry will appear in the back-up slice for audit purposes.

6.3. Emergency reset via command line

For unmanned stations where the Explorer is not available, restart only the script plane with the sc command. This is a last-resort step that resets the scheduler without disturbing tag acquisition.

sc stop "S7WINCC"
timeout /t 5 /nobreak > nul
sc start "S7WINCC"

After the service restarts, re-attach the runtime client and confirm @SCRIPT_COUNT_TAGS returns to a steady state below 1,000.

7. Script Refactoring Strategy

Recovery without refactor is a temporary reprieve. To break the cycle you need to move from "everything is event-driven" to a small set of cyclic orchestrators that wake up on a single trigger and dispatch work to on-demand scripts.

7.1. Split the project into three roles

The orchestrator is the only cyclic action you keep. Everything else is event-driven. Field data shows that a 1 s orchestrator with 30 on-change workers holds the queue below 200 actions under steady load — three orders of magnitude below the 5,000 warning threshold.

7.2. Replace loops with state machines

Anti-pattern (raises 1007000):

VBScript
' On a 250 ms trigger — NEVER DO THIS
Do
    If HMIRuntime.Tags("PLC_DB1_DBW0_0").Read = 1 Then
        HMIRuntime.Screens("Main").ScreenItems("PumpStatus").BackColor = vbGreen
    End If
    ' No exit — the loop is the action body
Loop

The same logic as a worker:

VBScript
' On change of "Trigger_Refresh_Pump"
Sub Refresh_Pump()
    If HMIRuntime.Tags("PLC_DB1_DBW0_0").Read = 1 Then
        HMIRuntime.Screens("Main").ScreenItems("PumpStatus").BackColor = vbGreen
    Else
        HMIRuntime.Screens("Main").ScreenItems("PumpStatus").BackColor = vbRed
    End If
End Sub

State transitions move to a small finite state machine that the orchestrator drives. The action body returns control to the scheduler between triggers, so the queue stays empty.

7.3. Move I/O out of the action body

Any action that opens a database connection, reads a file, or talks to OPC must release the scheduler thread within 250 ms. The supported pattern in WinCC 7.x is:

1. Worker raises a flag tag (e.g. Job_Archive_Recipe = 1).
2. A separate Windows service (or a scheduled task) picks up the flag, performs the I/O, and writes the result back to a different tag.
3. The action body only sets and clears flags; it never blocks on I/O.

Inside the action, the only I/O you may perform is a tag read or write, a direct SetTag/GetTag call, or a WinCC API function. Anything else is a candidate for off-loading. The WinCC 7 documentation on the SIOS portal lists the supported internal API surface; calls outside that list (for example, direct ADODB) are not guaranteed to release the scheduler in time.

8. Trigger Model Best Practices

WinCC 7.x exposes six trigger types per action. The ranking below combines the official WinCC documentation guidance with field maintenance data collected from more than 200 production projects.

9. WinCC 7 Configuration Changes

Three registry and configuration settings move the runtime from "frozen at 10,000" to "resilient at 5,000 with graceful degradation". Always back up the project before changing any of these values.

9.1. Action timeout

Default 30,000 ms. Lower to 5,000 ms (5 s) to force runaway actions to fail fast. The setting lives in the Computer properties of the WinCC Explorer under Runtime Settings > Scripts. Pair the change with a Siemens-supported log entry in PDLrt.log so post-mortem is trivial.

9.2. Script queue soft warning

Add the registry value [HKEY_LOCAL_MACHINE\SOFTWARE\Siemens\WinCC\Script\QueueSoftWarning] = 3000 (DWORD) on the WinCC server. The runtime will log a warning when 3,000 actions are in work — well below the system warning at 5,000 — giving maintenance a 30-60 minute lead time before 1007000 fires. A restart of the WinCC service is required for the registry change to take effect.

9.3. Graphics runtime buffer

For projects with more than 5,000 tags changed per second from the PLC, increase the runtime buffer in WinCC Explorer > Computer > Properties > Graphics Runtime from the default 1,024 KB to 4,096 KB. This decouples tag dispatch from action dispatch and prevents back-pressure from synthesizing script events. Document the change in the project CMDB; the buffer increase can mask an upstream PLC problem if left undocumented.

9.4. Hot-fix for the OS Project Editor template

The WinCC 7.0 OS Project Editor inserts the standard 1007000 alarm entry as a system message. If you regenerate the OS project after a refactor, the entry comes back automatically. Do not delete it; treat the regeneration as a verification step that the system message catalog is intact.

10. Monitoring and Prevention

Connect the internal tag @SCRIPT_COUNT_TAGS to a WinCC trend and to a 10-minute averaged alarm so that the control room sees a leading indicator rather than the binary 1007000. The following VBScript block can be added to the project's VBScript editor to log every acknowledgement of the overflow message.

Sub OnAlarmAck(ByVal msgID As Long, ByVal state As Long)
    If msgID = 1007000 Then
        ' Log to the project's diagnostic database
        HMIRuntime.Trace "1007000 acknowledged at " & Now & _
            " with @SCRIPT_COUNT_TAGS = " & _
            HMIRuntime.Tags("@SCRIPT_COUNT_TAGS").Read
    End If
End Sub

Trend chart setup:

1. Add @SCRIPT_COUNT_TAGS as a trend value, archive cycle 5 s, archive length 1 day.
2. Create a single-point alarm on the same tag with limit 4,500 (high) and limit 9,500 (high-high). The high-high trip fires 500 actions below the system ceiling, giving the operator a clear window to act.
3. Forward the alarm to the plant historian and to the SMS gateway if the project runs unattended.
4. Add the trend to the operator's overview page so the leading indicator is always visible, not buried in a diagnostics picture.

Audit checklist — run weekly:

• List every action with a trigger interval ≤ 1 s and a body that contains an If. Review for refactor opportunity.
• List every action with a body > 200 lines. Refactor to a function module.
• List every action that opens a COM proxy. Move the call to a Windows service or to a global VBScript function called once per second.
• Confirm the PDLrt.log is rotated. Set a scheduled task that copies the file to a network share and truncates the local copy on the first day of each month.
• Reconcile the list of "More than 5000 actions" warnings against the change log. Every entry should be explainable by a documented maintenance window.

11. Troubleshooting Matrix

Use this matrix as the first response for an on-call engineer who has just received a 1007000 page.

12. Platform Notes: WinCC 7.0 vs 7.4 vs 7.5

Behaviour around the script queue is consistent across the WinCC 7.x family, but a few deltas matter when you are sizing the refactor.

• WinCC 7.0 — hard limit 10,000; Runtime > Restart Script Processing is missing in SP0-SP3; OS Project Editor must be used to reset the alarm.
• WinCC 7.4 — adds the QueueSoftWarning registry hook; hot-fix HF14 patches a memory leak in the VBScript engine that contributed to false overflows under load.
• WinCC 7.5 — hard limit raised to 20,000; introduces parallel action execution for the C-script plane (the VB plane remains single-threaded). On a 7.5 install, a 10,000-action saturation on the VB plane can coexist with a healthy C-plane counter — verify both before declaring the runtime healthy.

If the project must remain on WinCC 7.0 for compatibility reasons, the soft-warning registry setting is the single highest-leverage change you can apply. On WinCC 7.5, the parallel C-script plane lets you move long-running calculations off the VB plane, which removes most of the pressure that drove the legacy 1007000 incidents.

13. Verification Checklist

Run this list before handing the project back to production:

1. Restart the WinCC runtime. Confirm @SCRIPT_COUNT_TAGS drops below 200 within 30 s.
2. Trigger the worst-case process sequence (recipe load, alarm burst, picture navigation). The tag should peak below 3,000.
3. Open the diagnose directory and confirm there are no "More than 5000 actions" entries from the last 24 hours.
4. Check the process alarm list — the 1007000 entry is present in the back-up archive slice but not in the active head.
5. Confirm the soft-warning registry value survived the runtime restart.
6. Review the audit list above. Document the refactor backlog in the project CMDB.
7. Brief the next shift: the overflow was a scheduler symptom, not a WinCC bug. Reinforce the "no loops in actions" rule at the daily toolbox talk.

14. Frequently Asked Questions