Resolving WinCC OnErrorExecute 1007006 and 1007001 in C-Actions

Problem Statement

A WinCC 6.2 SP2 runtime picture is configured with a Button object named Button9 on screen @SCREEN.@WIN13:@BUTTONS11. The mouse-click event invokes a global C-Action that calls startSimulation() to launch S7-PLCSIM via ProgramExecute("s7wsvapx.exe"). The moment the operator clicks the button, the runtime does not execute the action. Instead, the PDLRuntimeSystem raises two consecutive OnErrorExecute() diagnostic frames inside the GSC Runtime window. The frames reference an internal pseudo-name @a85, an attribute named inButton9, and two distinct error identifiers (1007006 and 1007001). The intended action of starting PLCSim never occurs.

This article reconstructs the two failure paths, maps them to documented WinCC runtime error categories per the official Siemens configuration error interpretation guide, and provides the exact remediation steps required to clear the fault and recover normal C-Action execution on a WinCC 6.x / 7.x picture window.

Reproduction Environment

Symptom: OnErrorExecute Diagnostic Frames

Two frames are emitted in the order shown. WinCC runtime always dumps both the configuration fault and the runtime exception so engineers can correlate a bad tag with the downstream crash that it produced.

Frame 1 — dwErrorCode1 1007006

====================================OnErrorExecute====================================
SystemTime:           (ThreadId 5364) 2009-07-17 10:26:04.453
dwErrorCode1:         (ThreadId 5364) 1007006
dwErrorCode2:         (ThreadId 5364) 0
szErrorText:          (ThreadId 5364) Tag unknown, timeout or conversion failed
szApplicationName:    (ThreadId 5364) PDLRuntimeSystem
bCycle:               (ThreadId 5364) acycle
szFunctionName:       (ThreadId 5364) @a85
szTagName:            (ThreadId 5364) "inButton9"
dwCycle:              (ThreadId 5364) 0
szErrorTextTagName:   (ThreadId 5364) Tag not exist
lpszPictureName:      (ThreadId 5364) @SCREEN.@WIN13:@BUTTONS11
lpszObjectName:       (ThreadId 5364) Button9
lpszPropertyName:     (ThreadId 5364) (NULL)
dwParamSize:          (ThreadId 5364) 24
====================================OnErrorExecute====================================

Frame 2 — dwErrorCode1 1007001, dwErrorCode2 4100

====================================OnErrorExecute====================================
SystemTime:           (ThreadId 5364) 2009-07-17 10:26:04.484
dwErrorCode1:         (ThreadId 5364) 1007001
dwErrorCode2:         (ThreadId 5364) 4100
szErrorText:          (ThreadId 5364) Exception in Action
szErrorTextException: (ThreadId 5364) access violation
szApplicationName:    (ThreadId 5364) PDLRuntimeSystem
bCycle:               (ThreadId 5364) acycle
szFunctionName:       (ThreadId 5364) @a85
lpszPictureName:      (ThreadId 5364) @SCREEN.@WIN13:@BUTTONS11
lpszObjectName:       (ThreadId 5364) Button9
lpszPropertyName:     (ThreadId 5364) (NULL)
dwParamSize:          (ThreadId 5364) 24
====================================OnErrorExecute====================================

The two frames fire 31 ms apart (10:26:04.453 → 10:26:04.484). The first one is a pure tag-resolution rejection; the second is the unhandled exception generated when the C runtime tries to consume the rejected tag value and continues into external code.

Root Cause Analysis

Two independent faults combine to abort the click handler. They must be fixed in the order shown because the second fault is triggered by the first.

Fault A — Tag "inButton9" Does Not Exist in WinCC Tag Management

The action contains the call:

wVal = GetTagWord("inButton9");

Inside the WinCC tag manager (the Tag Management editor of the WinCC Explorer project, which must be opened to declare internal tags such as inButton9), no variable with that name exists. szErrorTextTagName: Tag not exist is the unambiguous confirmation. WinCC therefore fires dwErrorCode1 = 1007006 ("Tag unknown, timeout or conversion failed"), the action returns without populating wVal, and the runtime continues executing the next statement. The relevance for code interpretation is:

• 1007006 covers three semantics in a single code — tag missing in the configuration database, tag not reachable on its configured channel / connection (timeout, common for S7 protocol tags when the PLC is offline), or a type conversion mismatch between the requested API (GetTagWord) and the configured tag data type.
• dwErrorCode2 = 0 in this trace indicates the failure is configuration-side (tag not exist) rather than transport-side (timeout / CP down). A timeout would push dwErrorCode2 to a non-zero value or the timeout sub-error string.
• The error is raised on the acycle event branch, which confirms the trigger is the mouse-click event and not a scheduled refresh.

Fault B — Access Violation in Function @a85

After the tag read returned an unknown status, the runtime continues into startSimulation(bsystemRunning, EndTime). The second OnErrorExecute frame reports:

• dwErrorCode1 = 1007001 → "Exception in Action"
• dwErrorCode2 = 4100 (decimal), i.e. 0x1004
• szErrorTextException = access violation

The C runtime (PDLRuntimeSystem is the GSC = Graphics Subsystem C-runtime) raises WinCC error 1007001 when an action triggers an unhandled structured exception. Sub-code 0x1004 signals an EXCEPTION_ACCESS_VIOLATION (Windows SEH code 0xC0000005, status 4) — the runtime attempted to dereference memory that the process is not permitted to access. Most common causes inside WinCC C-Actions are:

1. An uninitialized WORD return value that is later passed by reference into a runtime API expecting a BYTE*/DWORD*/char* pointer.
2. A function pointer (startSimulation) called through a prototype whose return type is not __stdcall, causing stack-frame corruption visible as a deferred access violation inside the called function.
3. A DLL containing the function is loaded with mismatched calling convention (C vs. stdcall) so the address pushed into startSimulation lands on invalid memory after the first prologue instruction.
4. Calling code inside a trigger (acycle event) that the C runtime considers unsafe, which sometimes results in a non-deterministic memory fault reported as access violation.

Why szFunctionName Shows @a85 and Not the Real Function

WinCC synthesizes a pseudo-name of the form @a<nn> for actions whose source header does not name a function entry point that the runtime can match. Several documented conditions produce this name:

• The apdefap.h file referenced by the picture does not contain the expected prototype of the action handler, or the picture is reloaded after a header edit that did not propagate.
• The project was recompiled by deleting / rebuilding *.pas and *.a66 files without regenerating the function table.
• The script's function name (defined in project functions or in a header) collides with another action so the runtime cannot reconcile symbol ownership.
• The script's source code was edited directly outside the Graphics Designer and the new binary was not registered.

For standard event handlers (mouse click, value change, etc.) the runtime normally logs the entry name (OnClick, OnLButtonDown, etc.). The presence of @a85 instead of the expected function indicates that the click action body has lost its function identification through one of the four causes above. The poster observes that @a85 does not appear against any GSC Runtime action ID — that is the symptom of the same compilation-bind failure.

WinCC Error Code Reference

The mapping in the table below is the interpretation set published for WinCC configuration errors. See the official Siemens Support document "How do you evaluate and remedy 'OnErrorExecute'-type configuration errors?" for the full interpretation matrix.

Resolution Procedure

Apply the four steps below in order. They collectively repair the missing tag, restore the correct function binding, and harden startSimulation() so the runtime can safely launch PLCSim.

Step 1 — Declare and Synchronize the Tag

1. Open the WinCC Explorer and select Tag Management on the project.
2. Right-click Internal Tags and choose New Tag….
3. Name the tag exactly inButton9 (case-sensitive — WinCC tag names follow SIMATIC identifier rules: 32-char max, start with letter or underscore, no spaces, no special characters other than _).
4. Set the data type to Unsigned 16-bit (Word). This matches GetTagWord so no implicit conversion error is generated.
5. Click Apply, close the editor.
6. In the Graphics Designer, open the picture @BUTTONS11, select Button9, right-click and choose Properties → Events → Mouse → Click.
7. Re-attach the C-Action by re-opening the script in the editor and clicking Compile / OK. This registers the function with the regenerated header table.

Step 2 — Verify Tag Type Matching

For the API family used in the script, the data types must align as follows:

If inButton9 were created as a Binary Tag, WinCC would still reject the request with 1007006 ("conversion failed").

Step 3 — Repair the @a85 Function Identification

1. Close the Graphics Designer on the engineering station.
2. Open Windows Explorer and navigate to the project folder (e.g. \<Server>\WinCCProj\<Project>\GraCS\).
3. Delete the generated files for the affected picture: @BUTTONS11.pdl, the matching .a66, and any @BUTTONS11.@@apdefap.* or compiled .fct artefacts.
4. Re-open the project in the Graphics Designer. The picture regeneration will rebuild the header tables and re-attach the C-Action with its named handler (OnClick) instead of the synthetic @a85.
5. Recompile the entire project from the menu Project → Compiler → Graphics.
6. Re-test the click event from runtime. szFunctionName must now report the correct function (or your project function name) and not @a85.

Step 4 — Implement PLCSim Launch via ProgramExecute

The recommended way to launch the S7-PLCSIM executable from a WinCC C-Action is ProgramExecute(). The path string must use double-backslashes because Windows C runtime interprets a single \ as the start of an escape sequence.

#include "apdefap.h"
void OnClick(char* lpszPictureName, char* lpszObjectName, char* lpszPropertyName)
{
    WORD wVal = 0;
    DWORD dwRet = 0;

    /* --- read the diagnostic tag first to clear the 1007006 fault --- */
    wVal = GetTagWord("inButton9");
    printf("PLCSim launch initiated from picture %s, button %s\\n",
           lpszPictureName, lpszObjectName);

    /* --- launch PLCSim non-blocking so the runtime is not stalled --- */
    dwRet = ProgramExecute("C:\\Program Files\\Siemens\\Automation\\PLCSIM\\s7wsi\\s7wsvapx.exe");
    if (dwRet == 0)
    {
        printf("ProgramExecute failed, code %u\\n", GetLastError());
    }
}

Implementation notes:

• ProgramExecute returns 0 on failure or a non-zero code on success; always check the return value.
• WinCC 6.2 paired with S7-PLCSIM V5.4 → install path SIEMENS\PLCSIM. WinCC 7.x with newer PLCSIM versions typically installs to Siemens\Automation\PLCSIM.
• Prefer ProgramExecute over WinExec, ShellExecute, or CreateProcess; only WinCC's own API knows the project context and logs the launch through the runtime diagnostics.
• Use ShellExecute only if you need to wait for the PLCSim window before continuing (pass nShowCmd = SW_SHOWNORMAL); synchronous waits in C-Actions will block the GSC thread and may stall pictures.

Step 5 — Validate startSimulation() Body

When an access violation persists after Steps 1–4, the external startSimulation() itself is at fault. Validate the prototype declaration in the header included by apdefap.h:

/* In the project header (e.g. simulation.h) */
#ifdef __cplusplus
extern "C" {
#endif
__declspec(dllexport) long __stdcall startSimulation(int bSystemRunning, double EndTime);
#ifdef __cplusplus
}
#endif

Key invariants:

• The DLL must export with __declspec(dllexport) and __stdcall on Windows; WinCC resolves symbols with __stdcall convention on the standard WinCC build target. Mismatched calling conventions are the single most frequent root cause of deferred access violations in @a85-style faults.
• All out-parameters must be supplied by the caller; never pass NULL as the buffer for a return-by-pointer argument.
• If the function ultimately calls a third-party API that allocates on the heap (e.g. CoCreateInstance, malloc, new), initialize COM with CoInitializeEx(NULL, COINIT_APARTMENTTHREADED) per thread — failure to do so produces an access violation deep inside Ole32.dll rather than in your code.
• Bound the lifetime of stack-resident char* buffers inside startSimulation if your call may run during a Stop Runtime / Restart sequence.

Verification

Confirm the fix with all four checks below. Each maps directly to one of the failure modes described above.

1. GSC Runtime window: No new OnErrorExecute entries for Button9 appear after the click. Log is clean in WinCC Explorer → Tools → GSC Runtime.
2. Diagnostic output: The text PLCSim launch initiated from picture @SCREEN.@WIN13:@BUTTONS11, button Button9 is printed exactly once per click, confirming OnClick (not @a85) executed.
3. PLCSim window: The S7-PLCSIM UI appears within ~1 s of click and the target AS can be brought online.
4. Tag state: GetTagWord("inButton9") returns a WORD; setting the tag in Tag Management before the click changes the read value as expected.

Access Violation Diagnostics in PDLRuntimeSystem

When 1007001 persists after the obvious tag and function fixes, instrument the C-Action to localize the fault:

#include "apdefap.h"
#include <stdio.h>
void OnClick(char* lpszPictureName, char* lpszObjectName, char* lpszPropertyName)
{
    printf("[OnClick] entry\\n");
    fflush(stdout);

    WORD wVal = GetTagWord("inButton9");
    printf("[OnClick] tag read: %u\\n", (unsigned)wVal);
    fflush(stdout);

    /* --- defensive test of startSimulation via function pointer --- */
    HMODULE hMod = LoadLibrary("MySimDLL.dll");
    if (!hMod) {
        printf("[OnClick] LoadLibrary failed: %lu\\n", GetLastError());
        return;
    }
    typedef long (__stdcall *START_SIM_PTR)(int, double);
    START_SIM_PTR fnStart = (START_SIM_PTR)GetProcAddress(hMod, "startSimulation");
    if (!fnStart) {
        printf("[OnClick] startSimulation not exported\\n");
        FreeLibrary(hMod);
        return;
    }
    long rc = fnStart(1, 100000.0);
    printf("[OnClick] startSimulation returned %ld\\n", rc);
    FreeLibrary(hMod);
}

The printf / fflush(stdout) pair is mandatory inside WinCC C-Actions because the GSC redirects stdout only when the buffer is flushed. Without an explicit flush the trace will not appear in the GSC Runtime window. The next printf that prints is the line just before the offending statement.

Action Identification Convention (@<letter><nn>)

Any @a or @b pattern is a defect indicator: the picture's C/VBS header table is out of sync with the picture file. Cycling the picture through Steps 3 above clears it.

PLCSim Launch Paths by WinCC / PLCSIM Version

Troubleshooting Matrix

Prevention Checklist

• Declare every tag in Tag Management before referencing it from any C/VBS action; never invent tags inside the action editor for testing without also creating them.
• Match each GetTag* call to the registered data type using the table above; mismatch always produces 1007006.
• Keep all function prototypes in dedicated headers included by apdefap.h; declare DLL exports with __stdcall for WinCC compatibility.
• Avoid re-pasting scripts outside the Graphics Designer; any text-edited file loses the binary header table and the @a<nn> pseudo-name appears.
• Always check the return code of ProgramExecute() and log it through printf + fflush.
• Run a project-wide Rebuild all after upgrading the C compiler or replacing a referenced DLL.
• For PLCSIM Advanced targets, branch the launch path (as shown in the table above) and use ShellExecute instead of ProgramExecute.

FAQ