Troubleshooting APDiag General Protection Fault in WinCC C

1. APDiag Diagnostic Tool Overview

The APDiag (Application Diagnostic) tool is the primary runtime telemetry sink for WinCC V6/V7 (and WinCC Professional / TIA Portal HMI) projects that contain ANSI-C or VB script logic. APDiag writes a continuous stream of events to a dedicated output window: scheduled actions, function calls, internal lifecycle events (OpenPicture, ClosePicture, OnTime, Mouse events), warnings, and—most importantly—access violations raised by the WinCC C runtime.

Per the Siemens KB article "How do you use the diagnostic tool APDiag to debug C scripts?" (entry ID 22196775), developers should treat APDiag as the first stop whenever an HMI panel throws a red General Protection Fault banner, the runtime disappears from the task list, or a picture appears to "freeze" on partial load. Activate APDiag from WinCC Explorer > Tools > APDiag (or start APDiag.exe from the WinCC installation directory), and leave the window docked while reproducing the fault.

2. Anatomy of the General Protection Fault

A general protection fault (GPF) is the WinCC C runtime's translation of a Windows access violation. The fault means the script dereferenced a pointer that did not contain a valid, allocated memory address. In a WinCC runtime, this almost always means one of the following happened inside a C function or project function:

1. A pointer to a string (LPCSTR, char*) was passed uninitialized to a WinCC API such as GetPropChar, SetPropChar, GetLink, SetLink, or any property I/O helper.
2. A buffer obtained from SysMalloc, malloc, or stack-allocated char arr[N] was read or written past its end.
3. A picture or object handle that had already been closed/freed was re-used.
4. A printf/DebugTrace call used a %s specifier with a NULL argument.

APDiag prints a structured record for the GPF. The record typically includes the faulting module (ccalg.dll, cclib.dll, pdllrt.dll, or the user DLL), the exception code (0xC0000005 STATUS_ACCESS_VIOLATION on x86), and two identifiers that are decisive for narrowing the cause:

• lpszObjectName — the WinCC object (picture, control, tag, screen window) the script tried to address.
• lpszPropertyName — the property/attribute of that object.

When both fields show the literal text NULL, the fault did not occur inside a property helper at all. It occurred in the C runtime while resolving the call, and the dispatcher simply has no context. The fault is therefore in the script's own code path, not in a WinCC API misuse.

3. Reading the APDiag Output Window Trace

A typical trace block for this class of fault looks like the following (representative; field labels and order may vary slightly by WinCC version):

@100,2025-03-14 08:42:11.034,GPF,    PROJECT\BASE,    NULL,    NULL,    Access violation (0xC0000005) reading 0x00000000
@100,2025-03-14 08:42:11.034,TRACE,   PROJECT\BASE,    Event:    OpenPicture
@100,2025-03-14 08:42:11.034,TRACE,   PROJECT\BASE,    Caller:   @1d
@100,2025-03-14 08:42:11.035,TRACE,   PROJECT\BASE,    Stack:    PdlRt!OpenPicture+0x47
@100,2025-03-14 08:42:11.035,TRACE,   PROJECT\BASE,                  ccalg!ExecuteProjectFunction+0x12c
@100,2025-03-14 08:42:11.035,TRACE,   PROJECT\BASE,                  user32!DispatchMessage+0xa

Key field meanings:

4. Locating the Triggering Picture and Event

When lpszObjectName and lpszPropertyName are both NULL and the address is PROJECT\BASE, the fault is on an event of the picture itself, not on a child object. Open Graphics Designer, select the picture whose name is reported after PROJECT\ (e.g. PROJECT\BASE.pdl = the base/start picture), right-click the canvas, and choose Properties > Events.

Inspect, in this order:

1. OpenPicture — fires once when the picture is loaded. Most common source of intermittent GPFs because the runtime is still wiring internal handles.
2. Open / OpenPictureOnce — variants of the same event in older projects.
3. ClosePicture — common when memory is freed twice or when a project function still holds a reference.
4. Hotkeys / Mouse events — if the fault correlates with operator input, check the mouse/keyboard events bound to the picture.

For every event handler, expand the C action and verify the function it calls. Note the function name; you will need it to fix the string handling issue described in Section 10.

5. NULL lpszObjectName and lpszPropertyName: What They Mean

The dispatcher in pdllrt.dll populates lpszObjectName/lpszPropertyName from the function arguments at the moment the C interpreter invokes an internal helper. When the dispatcher prints NULL for both fields, two scenarios are possible:

In all four scenarios the dispatcher still records the target of the call (the picture on which the event fired), but it cannot record the argument because the argument was never valid. That is why both fields read NULL.

6. C-Script String Handling as the Root Cause

The Siemens FAQ "How do you efficiently and reliably program the processing of character strings (pointer to char, "String") in WinCC C scripts?" (entry ID 7929092) is the canonical reference for this class of fault. The root cause pattern in nearly every case is one of the following:

• Mixing WinCC String (Pascal-style, length-prefixed) with C char* (NUL-terminated) without conversion. Functions such as strlen, strcpy, and sprintf read until they find '\0'; WinCC String values embed a length prefix and do not necessarily contain a NUL byte in the data area.
• Aliasing a literal constant. Writing into a string literal pointer is undefined behavior. WinCC stores some names in read-only memory.
• Off-by-one on the buffer size. char buf[32]; strcpy(buf, src); crashes when strlen(src) >= 32. The fault may be intermittent because the read past the end either returns garbage (no crash) or crosses a page boundary (crash).
• Using GetPropChar/SetPropChar with a NULL object or property argument. The dispatcher then cannot populate lpszObjectName/lpszPropertyName and reports NULL for both.

This explains the symptom in the field report: a project function bound to the picture's OpenPicture event triggered a GPF; the dispatcher printed lpszObjectName: NULL, lpszPropertyName: NULL; and after a reboot the fault did not recur for a while. The reboot is irrelevant—the script is still wrong, it just happened not to land on an unmapped page this time.

7. Identifying the Action via @xxx Codes

APDiag references the offending action by its encrypted short ID, e.g. @1d. The mapping from @1d back to the C function that the developer wrote is not stored in a public file, but per Siemens FAQ "How can I determine the name of an action via the error message 'Execute Error in Action @xxx'?" (entry ID 8385493) you can recover it through the project database:

1. Close the WinCC Runtime.
2. Open the project database with an editor that supports the WinCC project structure (or use the WinCC Project migrator / CCProjectMgr.exe in export mode).
3. Search the file <ProjectName>.pck (the packed project file) for the action ID. The actual function name appears in the metadata table next to the @xxx slot.
4. Alternatively, open the Graphics Designer, select the picture, and look at every event handler. The C function invoked in the handler is the one whose compiled form has the matching @xxx ID; you can identify it by clicking each action and noting its function call.

8. GSC Runtime: Scheduled vs. Running Events

The GSC Runtime (Global Script C Runtime) tab in the WinCC Explorer shows the actions that have a schedule (a time trigger, a variable trigger, or an event trigger). It does not show actions that are currently executing on a picture event, because picture events are dispatched by the Graphics Designer runtime, not the scheduler.

To observe picture events as they fire, use the APDiag window with the Trace Events filter enabled. The trace will print a line for every event that the Graphics Designer dispatches, including OpenPicture, ClosePicture, MouseLButtonDown, Hotkey, and any custom-named event. This is the only reliable way to confirm whether the OpenPicture handler is actually being entered when the picture loads.

9. Memory Reservation Failures and Intermittent Faults

A random GPF (occurs on some starts, not others) is almost always one of the following:

1. Heap layout. The same offending read can land on a valid or invalid page depending on what the runtime has allocated. After a reboot, the heap is empty and the read often succeeds; after the runtime has allocated many handles, the read crosses a guard page.
2. Uninitialized local char buffer. Stack contents are non-deterministic. A char buf[256]; declared but never memset to zero will contain a random pointer-sized value at buf[0..7]; reading the buffer as a string gives random data and may eventually dereference a non-pointer.
3. Re-entrancy. OpenPicture can fire twice in a single load (e.g. when the start picture is the same as the configured picture for a screen window, or when a screen window is configured to re-open on tag change). A handler that frees memory in the first call crashes on the second.
4. Race with the project function library. If a C function from a project DLL is called from OpenPicture while the DLL is still being initialized, the function pointer is valid but the internal state is not.

This is why a reboot "fixes" the fault for a while: the heap state is reset, but the script bug is unchanged.

10. Correct String Handling per Siemens FAQ 7929092

Apply the following rules, summarized from FAQ 7929092, to the failing function:

1. Never call strcpy/strcat/sprintf on a WinCC String directly. Convert with GetCharArray or SetCharArray, or use SysString operations.
2. Initialize every local buffer. Use char buf[64] = {0}; or memset(buf, 0, sizeof(buf));.
3. Always check pointer return values. char* p = SysMalloc(64); if (!p) { /* error path */ return; }
4. Use snprintf with explicit length. Replace every sprintf(buf, "%s", src) with snprintf(buf, sizeof(buf), "%s", src).
5. Use strncpy and explicitly NUL-terminate. strncpy(buf, src, sizeof(buf)-1); buf[sizeof(buf)-1] = '\0';
6. Match allocation to deallocation. Memory from SysMalloc must be released with SysFree; memory from malloc with free; never mix.
7. Do not pass NULL to property helpers. Validate object and property name arguments before calling GetPropChar, SetPropChar, GetLink, SetLink.

Example fix for a typical OpenPicture handler that reads a picture name from a tag and applies it to a property:

// BAD: passes tag value straight into the dispatcher, may be NULL or too long
char* p = GetTagChar("PicName");
SetPropChar(lpszPictureName, "BackPicture", p);

// GOOD: validate, copy with bound, NUL-terminate
char* p = GetTagChar("PicName");
if (p == NULL) {
    printf("[OpenPicture] Tag 'PicName' returned NULL, aborting property set\n");
    return;
}
char buf[260] = {0};
snprintf(buf, sizeof(buf), "%s", p);
if (strlen(buf) == 0) {
    printf("[OpenPicture] Tag 'PicName' is empty, aborting property set\n");
    return;
}
SetPropChar(lpszPictureName, "BackPicture", buf);

11. Step-by-Step Diagnostic Procedure

Use this ordered procedure every time you see a GPF in the APDiag output window:

1. Open APDiag from Start > Siemens Automation > WinCC > APDiag (or from the WinCC Explorer). Confirm the output window shows a live timestamp.
2. Reproduce the fault by triggering the action (e.g. switch to the picture that has the OpenPicture handler).
3. Capture the trace block that contains GPF and the subsequent Stack lines. Note the address (PROJECT\BASE in the typical case) and the Caller: @xxx line.
4. Resolve the picture from the address. If the address is PROJECT\<Name>, open <Name>.pdl in the Graphics Designer. If it is PROJECT\BASE, open the start picture configured in the project properties.
5. Resolve the event from the Event: line. Open the picture's Properties > Events and find that event's C action.
6. Resolve the function by mapping @xxx to a function name using the procedure in FAQ 8385493, or by cross-referencing the action's function call.
7. Inspect the function for the patterns listed in Section 5 and Section 6. Use a static analyzer (WinCC's C editor marks uninitialized variables and bad pointer use) and add printf/DebugTrace calls at every API entry point.
8. Fix the function following the rules in Section 10. Re-test.
9. Rebuild and re-deploy the project. Restart the runtime and reproduce the original trigger. Confirm no further GPF appears in APDiag.

12. Verification and Prevention Checklist

Run the verification procedure on every project that contains C scripts. The cost of the checklist is small compared with the cost of a runtime crash on an operator HMI panel.

13. Frequently Asked Questions