Resolving WinCC V7 C-Script Timeout Error 1007007 in Runtime

Problem: WinCC V7 C-Scripts Stop Executing After Weeks of Stable Runtime

A WinCC V7 station (migrated from WinCC V5) running on Windows XP SP3 reports a sudden, silent failure of all C-Script actions in Graphics Runtime. Picture calls, dialog box invocations, and any event driven by a C action stop firing. The PDLRTAPI runtime reports error code 1007007 with sub-code 2 and text PDLRTAPI.DLL : Timeout. The same project continues to function when the Windows logon is elevated from a standard user back to the local administrator account, which strongly indicates a permission- or service-related issue rather than a corrupted script.

This article documents the root cause, the diagnostic procedure using APDIAG.EXE, the corrective actions, and the verification checks required to confirm the fix. It also covers secondary causes (script loop, disabled Global Script Runtime startup parameter, missing DCOM/registry rights) that produce the same observable symptom.

Affected Products and Versions

The error is independent of the WinCC version because the underlying PDLRTAPI.DLL (Picture Dynamic Link Runtime API) has not changed its error semantics across V7 generations. Projects migrated from WinCC V5 commonly inherit C actions that call deprecated DM (Data Manager) API entry points, and these entry points timeout when the calling thread is not granted the required Data Manager rights.

Observed Symptoms

• C-Script actions attached to picture, object, or tag events do not execute.
• Direct picture calls (button → picture name property) still function; only script-driven events fail.
• Runtime does not display a user-facing error dialog. The failure is silent from the operator's perspective.
• Rebooting the WinCC Runtime does not resolve the issue.
• Logging in as a Windows administrator restores C-Script execution. Logging in as a standard user re-introduces the failure.
• System has run for 6 to 8 weeks without incident before the first occurrence.

Diagnostic Procedure with APDIAG

The APDIAG.EXE diagnostic tool is installed in the WinCC installation directory (default C:\Program Files\Siemens\Automation\WinCC\bin or C:\Siemens\WinCC\bin). Run it from an elevated command prompt on the affected station.

1. Close Graphics Runtime and WinCC Explorer.
2. Open cmd.exe as administrator (right-click → Run as administrator).
3. Navigate to %ProgramFiles%\Siemens\Automation\WinCC\bin.
4. Start the runtime with WinCCExplorer.exe "YourProject.MCP" or restart the WinCC service.
5. Launch APDIAG.EXE. The tool attaches to the running PDLRT and the Data Manager.
6. Trigger the picture containing the failing C action. APDIAG captures the OnErrorExecute trace.
7. Open the APDIAG output window and locate the OnErrorExecute block.

Typical captured trace from this failure mode:

OnErrorExecute
SystemTime:        (ThreadId 1728) 2010-02-03 11:14:36.750
dwErrorCode1:      (ThreadId 1728) 1007007
dwErrorCode2:      (ThreadId 1728) 2
szErrorText:       (ThreadId 1728) PDLRTAPI oder DMAPI
szErrorTextInfo:   (ThreadId 1728) Error in DMApi
szApplicationName: (ThreadId 1728) PDLRuntimeSystem
bCycle:            (ThreadId 1728) acycle
szFunctionName:    (ThreadId 1728) @1c46
lpszPictureName:   (ThreadId 1728) SP-PICTURE_1
lpszObjectName:    (ThreadId 1728) Group24
lpszPropertyName:  (ThreadId 1728) (NULL)
dwParamSize:       (ThreadId 1728) 24
szErrortext:       (ThreadId 1728) PDLRTAPI.DLL : Timeout

The dwErrorCode1 = 1007007 value is the public error class identifier for DM/PDL-RT error, sub-class 2 = DM_API timeout. The function @1c46 identifies the C action compiled from the script body. SP-PICTURE_1 and Group24 identify the picture window and group object where the script was attached.

Root Cause Analysis

The reported symptom has three reproducible root causes. They should be ruled out in the order presented because they are listed from most to least frequent in field installations.

Cause 1 — Global Script Runtime Disabled in Computer Properties

The single most common cause is that the Global Script Runtime startup parameter has been cleared, set to 0, or never enabled in the first place. WinCC Explorer → Computer → right-click the local computer name → Properties → Startup tab contains the list of startup parameters. GlobalScriptRuntime (older projects use the literal name GLOBAL SCRIPT RUNTIME) must be enabled (checkbox checked) for any C or VB action to run. If the parameter is missing, scripts are silently skipped by the PDLRT, and the timeout is raised when the runtime attempts to register the action callback.

Cause 2 — Windows User Rights Degradation (Primary Cause in the Reported Case)

The field case shows the project was originally configured and tested in administrator mode. After handover, the Windows account was downgraded to a standard user. The Data Manager (DM) service runs in session 0 with full rights, but the picture window process that hosts PDLRTAPI opens a named-pipe or DCOM channel back to the DM. If the standard user account is not a member of the local SIMATIC HMI / SIMATIC NET group and does not have SeImpersonatePrivilege or the legacy Debug Programs privilege on Windows XP, the cross-process call times out. The C action that started executing is killed after the DM timeout, producing the 1007007 / 2 code.

On Windows XP SP3 the affected Windows privilege is Debug Programs (privilege constant SeDebugPrivilege). On Windows 7 and later the affected capability is Impersonate a client after authentication (SeImpersonatePrivilege). Standard users on a default install do not hold either right.

Cause 3 — C Action Entering an Infinite Loop (script.exe)

A C action that calls a blocking DM API or a recursive picture change without a yield can saturate the script host. script.exe (the Global Script Runtime executable) enters a tight loop, and from that point onward every subsequent C action is starved of CPU. The runtime reports a timeout for each subsequent action. Killing script.exe from Task Manager or restarting the WinCC Runtime Service restores execution, but the script body must be re-examined and corrected.

Solution A — Re-enable Global Script Runtime

1. Open WinCC Explorer on the affected station.
2. Right-click the computer icon in the navigation tree and select Properties.
3. Switch to the Startup tab.
4. Locate Global Script Runtime in the list of startup parameters.
5. Enable the checkbox.
6. Click OK to write the modified computer properties back to the project database.
7. Restart Graphics Runtime (close and reopen the project, or use WinCC → Exit Runtime).

The setting is stored in the project file <ProjectName>.MCP and is propagated to the runtime registry key HKLM\SOFTWARE\Siemens\WinCC\<ProjectName>\Runtime\GlobalScriptRuntime. A value of 1 enables the host, 0 disables it.

Solution B — Restore the Required Windows Privileges for the Operator Account

For the reported case, the corrective action is to grant the WinCC operator account the privileges required by the Data Manager cross-process call. There are two recommended procedures; use the one that matches your Windows version.

Procedure for Windows XP SP3 (matches reported environment)

1. Log in as administrator.
2. Open Control Panel → Administrative Tools → Local Security Policy.
3. Navigate to Local Policies → User Rights Assignment.
4. Double-click Debug Programs.
5. Add the operator user account or the local SIMATIC HMI group.
6. Click OK and close the Local Security Policy editor.
7. Reboot the station for the privilege assignment to take effect.
8. Log in as the operator and verify C-Script execution in Graphics Runtime.

Procedure for Windows 7 / Server 2008 R2 and later

1. Log in as administrator.
2. Open secpol.msc.
3. Navigate to Local Policies → User Rights Assignment.
4. Add the operator account or the SIMATIC HMI group to Impersonate a client after authentication.
5. Reboot and verify.

Verify the Account Has the Group Membership

Run the following command from an elevated command prompt to confirm the operator account is a member of the SIMATIC HMI group:

The output should list the operator user account under Members. If the group does not exist, recreate it with:

Solution C — Recover from a script.exe Loop

1. Open Task Manager on the WinCC server.
2. Locate script.exe in the Details tab.
3. Note the CPU column. A value at or near 100 % for a sustained period indicates the loop condition.
4. End the script.exe process. The Global Script Runtime will be restarted automatically by the WinCC Runtime Service.
5. Open the affected picture and identify the C action that triggered the loop. Typical offenders: synchronous DM_API calls that wait on a tag that is never updated, recursive picture changes, missing cycle guards in a 250 ms cyclic action.
6. Correct the action. Add cycle guards (if (GetTagBitWait(...) == FALSE) return;), and replace blocking DM calls with non-blocking variants (GetTagDWord instead of GetTagDWordWait).
7. Re-deploy the corrected project and restart Runtime.

Verification Checklist

Hardening and Prevention

To prevent recurrence of this failure after handover, apply the following hardening steps during commissioning.

• Always commission the WinCC station logged in as the operator account that will be used in production, not as administrator. This surfaces permission-related issues before the system is accepted.
• Add the operator account to the local SIMATIC HMI group during installation. The WinCC setup does this automatically when the account is a member of Administrators; verify after downgrading.
• Document the Startup tab settings as part of the project handover package. The Global Script Runtime flag is one of seven critical flags; the others are Graphics Runtime, Tag Logging Runtime, Alarm Logging Runtime, Report Runtime, Redundancy, and Web Navigator Runtime.
• Audit C actions for blocking DM calls. Replace every GetTag*Wait with the non-blocking equivalent. The non-blocking variants raise 0x8004FFFF (DM_E_NOT_READY) when the tag is not currently valid, which the action can handle explicitly.
• Add a watchdog in the project startup. A 1 Hz internal tag can be set from a 250 ms cyclic action; the action aborts the picture change if the tag is not changing, catching infinite-loop conditions early.
• Schedule a periodic review of the APDIAG log (every 4 to 6 weeks). Persist the log to %ProgramData%\Siemens\WinCC\Diagnostics so the history is retained between reboots.

Common Pitfalls

Engineers frequently misdiagnose this issue. The following pitfalls are documented to help field service personnel avoid wasted troubleshooting time.

• Pitfall 1 — assuming the script is syntactically wrong. A syntax error in a C action raises a different error code (typically 1007001, script compile error) and surfaces in the GSC Diagnostics window. The 1007007 / 2 timeout is a runtime symptom, not a compile-time one.
• Pitfall 2 — assuming administrator mode will be used in production. The original configuration environment (administrator) almost never matches the production environment (operator). Always validate the project in the target account.
• Pitfall 3 — granting full administrator rights as a workaround. Adding the operator account to the local Administrators group makes the symptom disappear, but it bypasses the WinCC security model. The correct fix is to add the account to the SIMATIC HMI group with the documented privileges.
• Pitfall 4 — disabling UAC as a workaround. User Account Control is not the cause on Windows XP SP3 and is rarely the cause on Windows 7. The cause is the Data Manager cross-process call. Disabling UAC does not restore the required privilege.
• Pitfall 5 — running APDIAG without elevating. APDIAG must be run as administrator to attach to the WinCC Runtime process. If it times out immediately, the elevation is missing. Re-launch from an elevated prompt.

FAQ