Resolving WinCC WebNavigator Crashes from C-Script Buffer

Problem Summary

Siemens WinCC V7.3 SP1 Update 1 servers running the WebNavigator option can develop a specific failure mode in which the Web client renders a persistent grey screen, the session hangs at "Connecting to server", or the Windows Error Reporting dialog reports "Control Surrogate has stopped working". The fault is typically triggered by a user navigation sequence in the project graphics, then it persists across client restarts until the WebNavigator service is recycled. The root cause is almost never the WebNavigator server itself, the Internet Explorer engine, or the virtual host; it is a heap buffer overflow inside a WinCC C-script that executes correctly in the native Graphics Runtime but corrupts memory under the WebNavigator's C-to-JavaScript translation layer.

Affected Environment

Versions outside this matrix may also be affected; the C-script interpreter and the WebNavigator C-to-JavaScript converter share the same buffer-handling rules in WinCC V7.0 through V7.4. See the Siemens WinCC V7.3 Release Notes and Compatibility Overview for the supported runtime combinations.

Symptoms Observed

1. After server boot, the first navigation from the start page to Gate Out succeeds without fault.
2. Subsequent navigation from Gate Out to Lane 1, Lane 2, Lane 3, or Lane 4 leaves the Web client displaying a permanent grey rectangle where the process picture should appear.
3. Closing and re-opening Internet Explorer produces one of two outcomes: a second grey screen, or a freeze on the splash text "Connecting to server".
4. On the server console, Windows logs Application Error 1000 for CCViewerRt.exe with module CCWebCtrl.dll, and the user sees the Control Surrogate has stopped working dialog when a remote desktop session triggers the same picture change.
5. The fault becomes permanent until the WinCC WebNavigator service is restarted, then it repeats with the same navigation path.
6. Re-running the Web Configurator and the Web Publisher does not resolve the issue; replacing the published project folder with a backup that was known to be good reproduces the fault, because the C-script lives in the graphics designer project, not in the published files.

Root Cause: Heap Buffer Overflow in a WinCC C-Script

The offending action on the Gate Out picture was the following WinCC C-script:

char *str;
str = SysMalloc(16);
sprintf(str, "Fault Code: %02x", GetTagWord("WB4_TRCV_Status"));
return str;

The function returns a pointer to a 16-byte heap allocation. The format string is fixed at 12 printable characters, but the substituted argument is a 16-bit unsigned WORD whose hex representation can grow from two characters to four characters. The null terminator written by sprintf pushes the total write beyond the 16-byte boundary whenever the value is large enough.

Buffer Length Analysis

The literal "Fault Code: " is exactly 12 bytes: F a u l t C o d e : . The dynamic part contributes 2, 3, or 4 hex characters. The C standard guarantees a terminating \0 after the formatted text, so the maximum legal write is 12 + 4 + 1 = 17 bytes. The script allocates only 16 bytes, which means a value of WB4_TRCV_Status ≥ 0x1000 overwrites one byte of the adjacent heap chunk header.

Why the Script Worked in the Past

A common confusion is that the script ran for months without fault and then "began to fail" without any code, project, or Windows change. The C code is the same; what changed is the runtime value of WB4_TRCV_Status. As long as the tag value stayed below 0x1000, the formatted string fit in 16 bytes. When the underlying drive or barrier reported a new fault code ≥ 4096, the same line of code produced an out-of-bounds write. This is a class of latent bug that hides during commissioning because the FAT values are typically small (< 256) and only grow once the system enters a real fault state.

Why the Crash Only Manifests Under WebNavigator

WinCC's native Graphics Runtime tolerates a small one-byte heap overwrite because the runtime's C-script engine and picture cache are reloaded on picture change. The WebNavigator uses a C-to-JavaScript conversion engine (documented in the WinCC WebNavigator V7.3 documentation); the same heap is shared with the picture object's compiled output, and a corrupted chunk header in the WebNavigator process is fatal to the picture render path. The same script is therefore benign in the WinCC Explorer runtime on the server console but lethal when the picture is published and opened in a browser or WinCCViewerRT.

Diagnostic Procedure

1. Open Graphics Designer on the WinCC server and load the project.
2. Open the picture that is the source of the navigation (in this case, Gate Out).
3. Select each object that fires a C-action on the navigation event (mouse click, picture change, or dynamic dialog re-evaluation).
4. Open the C-editor for the action and search for any combination of SysMalloc, malloc, calloc, or static char buf[N] declarations followed by sprintf, snprintf, or memcpy.
5. For each match, compute the maximum output size and compare it to the allocation. Use the formula: required_bytes = strlen(literal_text) + max_dynamic_chars + 1.
6. Tag the offending script in a spreadsheet with picture name, object name, event, allocation size, and the tag whose value can grow the string.
7. Cross-check by enabling WinCC's APDiag / GDiagnose Plus trace: Start → Programs → Siemens Automation → GDiagnose Plus → Tag Logging → Trigger Trace. The trace will record the moment a tag's value crosses the overflow threshold.
8. If you cannot find any suspicious C-action, repeat the search on the destination pictures (the Lane 1..4 pictures) because WebNavigator also evaluates destination picture init code.

Solution

Apply all three of the following; none of them alone is a permanent fix.

1. Remove or rewrite the unsafe C-script. Either delete the C-action entirely, or replace it with the safe pattern shown below. Never return a pointer to a SysMalloc buffer from an event-driven C-script without first freeing the previous frame's allocation; the WebNavigator GC does not call SysFree for you.
2. Use snprintf and a size large enough for the worst case. The Siemens C-script interpreter supports snprintf from the C runtime; it caps the write at the supplied size and always terminates.
3. Build and re-publish the project. Open the Web Configurator, select Generate & Publish, then restart the WinCC WebNavigator service so the picture cache is dropped.

Safe C-Script Patterns

Pattern A — bounded buffer, safe format:

// Safe: 32 bytes is enough for "Fault Code: FFFF\0"
char *str = SysMalloc(32);
snprintf(str, 32, "Fault Code: %04X", GetTagWord("WB4_TRCV_Status"));
return str;

Pattern B — static internal buffer, no allocator calls:

static char str[32];
snprintf(str, sizeof(str), "Fault Code: %04X", GetTagWord("WB4_TRCV_Status"));
SetText(lpszPictureName, "StatusField", str);
return 0;

Pattern C — avoid return char* entirely; set the output via WinCC API and return an integer status code:

char buf[32];
int n = snprintf(buf, sizeof(buf), "Fault Code: %04X", GetTagWord("WB4_TRCV_Status"));
if (n < 0 || n >= (int)sizeof(buf)) {
    // log the truncation
    return -1;
}
SetText(lpszPictureName, "StatusField", buf);
return 0;

The %04X format specifier always produces exactly four hex digits, so the required buffer length is fully deterministic: 12 (literal) + 4 (hex) + 1 (terminator) = 17 bytes, comfortably inside a 32-byte allocation.

WebNavigator Hardening

Virtual Machine Considerations (ESXi)

The reported host (Xeon E5530, 8 GB RAM, ESXi 5.x or 6.x) is sufficient for a 5-client WebNavigator deployment as long as the following are observed:

• Reserve 100 % of the assigned RAM for the WinCC VM. Ballooning or swapping will manifest as the same grey screen because the WebNavigator server cannot flush picture data to the browser fast enough.
• Disable VMotion during commissioning; live migration can interrupt WebNavigator's long-lived TCP sessions to the client browsers.
• Enable VMware's large receive offload and TCP segmentation offload only if the vSwitch is dedicated; on shared uplinks they introduce latency spikes that can be misdiagnosed as WebNavigator crashes.
• Set the VM's hardware clock to "Synchronize guest time with host"; time drift on a virtualized Windows guest causes WinCC license tokens to invalidate, which produces an identical grey-screen symptom with a different root cause.

Locale and Language Interaction

WinCC V7.3 WebNavigator has a documented restriction that the project language set in the WinCC Explorer and the system locale of the WebNavigator server must match. Common combinations that produce grey screens include a Turkish system locale with an English WinCC project, and an English server locale with a project that contains both English and Chinese string tables that have not been re-imported through the Text Library. Verify the following two settings before deep-diving into C-scripts:

1. Control Panel → Region → Format: must match the WinCC project's Project Language.
2. Control Panel → Region → Administrative → Language for non-Unicode programs: must be set to a language whose codepage contains every character used in the project text library.

The current case is English system locale with Greek project text, which is a known supported combination; the language interaction was ruled out as a cause by re-running the same navigation sequence on a server with a clean English-only project.

Tag Value — Root Tag of the Overflow

The overflowing tag WB4_TRCV_Status is a status WORD from a barcode reader interface (TRCV = TRaCeiver). On a healthy reader, the value stays in the 0x0000 – 0x00FF range (no-fault codes). When the reader loses the optical link it reports 0x0C20 (3104, decimal). When the scan head detects a damaged barcode it reports 0x1A05 (6661, decimal). Both values exceed 0x1000, both trigger the buffer overflow. The fix is to mask the value to the lower 12 bits before formatting, or to widen the buffer to 32 bytes as shown in the safe pattern above.

Verification

1. Edit the offending C-action; replace the unsafe SysMalloc(16) with one of the safe patterns.
2. Save the picture, then in the Graphics Designer run Compile → Check All to confirm no syntactic errors.
3. Activate the project in Runtime and trigger the same navigation sequence (“Gate Out” → “Lane 1”).
4. Force the offending tag to 0xFFFF via the WinCC tag simulator (Start → Programs → Siemens Automation → WinCC → Tools → Tag Simulator) and confirm no grey screen and no Control Surrogate error.
5. Open the Web Configurator and click Generate & Publish; restart the WebNavigator service.
6. Connect five concurrent clients (the licensed maximum) and repeat the navigation sequence. Verify no grey screen, no “Connecting to server” freeze, and no entry in %ProgramData%\Siemens\WinCC\WebNavigator\Diagnostics\WebLog.log.
7. Leave the system running for 24 hours under the original production tag values; review Windows Application event log for any new Application Error 1000 for CCWebCtrl.dll. The log must remain clean.

Related Failure Modes to Rule Out

FAQ