Troubleshooting WinCC SCRIPT.EXE Dump File Analysis

Overview

Siemens WinCC generates user-mode memory dump files (extension .dmp) inside the runtime diagnose directory whenever a process such as SCRIPT.EXE, CCProjectMgr.exe, PDLrt.exe, or HMIRT.exe terminates abnormally. The files are stored under C:\Program Files\Siemens\WinCC\diagnose\Dumps\ (path varies slightly on multi-installation or WinCC V7.x migration setups where the directory can also be located under C:\Program Files (x86)\Siemens\). When SCRIPT.EXE produces a STATUS = TIMEOUT event in the WinCC logging, a matching SCRIPT_<YYYYMMDD>_<HHMMSS>.dump file is created with the same timestamp.

These dump files are valuable for root-cause analysis because they preserve the contents of process memory at the moment of the fault — including the call stack, register state, loaded modules, and exception information. Unlike Windows small memory dump files generated by %SystemRoot%\Minidump, WinCC dump files are full user-mode dumps produced by the runtime through the Windows MiniDumpWriteDump API and they reference private symbol information (PDB files) that ships only with WinCC development toolchains.

The primary obstacle in field troubleshooting is that public Microsoft symbol servers (http://msdl.microsoft.com/download/symbols) do not host symbols for WinCC binaries. This article documents the workflow engineers can use to extract maximum diagnostic value without internal Siemens symbol access, plus the alternative triage techniques that are available out of the box.

Problem Details

The classic failure mode is:

1. A WinCC runtime project is active on the HMI/SCADA station.
2. An automation event — typically a VBScript or ANSI-C action running inside SCRIPT.EXE — exceeds its internal execution budget.
3. WinCC logs: 255,DD.MM.YYYY,HH:MM:SS:mmm,0,4,SYSTEM,<HOSTNAME>,CCProjectMgr,WinCC Project Manager : Deactivate Project - SCRIPT.EXE - Status = TIMEOUT.
4. A new file appears in the diagnose folder: SCRIPT_YYYYMMDD_HHMMSS.dump (or sometimes SCRIPT_YYYYMMDD_HHMMSS.dmp) whose LastWriteTime matches the timeout event.
5. Engineers attempt to read the dump with the Microsoft Debugger Tools dumpchk.exe and receive: *** ERROR: Symbol file could not be found. Defaulted to export symbols.

Without private PDB symbols, only the export table of each loaded DLL is visible. Call stacks therefore resolve only down to the exported function entry point, hiding the precise source line and the failing VBScript context.

Root Cause

WinCC binaries are linked with Microsoft Visual C++ and ship without public symbols. SCRIPT.EXE is the WinCC VBScript/ANSI-C action interpreter wrapper, and it depends on CCAlgRt.dll, CCScriptHost.dll, and the VBScript engine vbscript.dll. When a script loops indefinitely, performs blocking COM calls, or triggers an unhandled exception, the WinCC runtime watchdog terminates the process and emits a full minidump through MiniDumpWriteDump.

Symbol resolution fails because:

• The Microsoft public symbol server at http://msdl.microsoft.com/download/symbols only carries Microsoft-published PDBs (ntdll.pdb, kernel32.pdb, vbscript.pdb, etc.).
• WinCC private PDBs (CCAlgRt.pdb, CCScriptHost.pdb, SCRIPT.pdb) are not redistributed; they are only present on Siemens internal development and support workstations.
• Even with _NT_SYMBOL_PATH configured as SRV*c:\symbols*http://msdl.microsoft.com/download/symbols, dump analysis falls back to export tables — useful, but not precise.

This means engineers are limited to module-level triage using export symbols plus side-by-side comparison against ccalgmsg.dll, ccdebug.dll, and WinCC log files in \diagnose\<HOSTNAME>_<YYYYMMDD>_<HHMMSS>.LOG.

Symbol Path Setup for Dumpchk

Before using dumpchk.exe, configure a local symbol cache to avoid repeated server round-trips:

set _NT_SYMBOL_PATH=SRV*C:\symbols*http://msdl.microsoft.com/download/symbols
mkdir C:\symbols
set _NT_EXECUTABLE_IMAGE_PATH=C:\Windows\System32;C:\Windows\SysWOW64;C:\Program Files\Siemens\WinCC\bin

Reference the Microsoft Learn guidance for reading small memory dump files for symbol path mechanics. The Dell knowledge base also provides a step-by-step procedure for analyzing Windows minidumps with WinDbg which is directly applicable to the WinCC dump file format.

Step-by-Step Dump Analysis Procedure

1. Verify the dump was created by the same process that timed out. Match the LastWriteTime of SCRIPT_*.dump with the STATUS = TIMEOUT line in \diagnose\<HOST>_*.LOG. Tools: Get-ChildItem C:\Program Files\Siemens\WinCC\diagnose\Dumps\ | Sort-Object LastWriteTime -Descending.
2. Capture file size and header. WinCC full minidumps are typically 5–250 MB depending on WinCC version and project state. dir *.dump or PowerShell Get-Item gives the precise value.
3. Run Dumpchk for a structural health check.
   dumpchk -y SRV*C:\symbols*http://msdl.microsoft.com/download/symbols -i C:\Windows\System32 -z "C:\Program Files\Siemens\WinCC\diagnose\Dumps\SCRIPT_20110525_173209.dmp"
   Expected output sections: BugCheck 0 (user-mode), ExceptionCode, ModuleList, ThreadCount. If Dumpchk reports *** ERROR: Symbol file could not be found. Defaulted to export symbols, the file itself is still valid — only symbol resolution is partial.
4. Load the dump in WinDbg. Launch WinDbg as Administrator, File → Open Crash Dump, then run:
   .sympath SRV*C:\symbols*http://msdl.microsoft.com/download/symbols
.reload
!analyze -v
5. Inspect threads. ~*k enumerates call stacks for every thread. Look for threads stuck inside vbscript!VBScriptClass::Call, CCAlgRt!AlgRtExecute, or CCScriptHost!ScriptHost::Run. Even without private symbols, the export names identify the failing subsystem.
6. Inspect loaded modules. lm lists modules with versions. Cross-check CCAlgRt.dll, CCScriptHost.dll, and SCRIPT.EXE versions against the installed WinCC build (e.g. WinCC V7.4 SP1 Update 12 → CCAlgRt.dll 7.4.1.12). Mismatches indicate partial upgrades.
7. Read WinCC logs in parallel. \diagnose\<HOST>_<DATE>.LOG, \diagnose\SCRIPT.LOG, and \Archives\<Project>\<TagArchive> should all be correlated. Look for CCAlgRt error codes (1001, 1002, 1100) preceding the timeout.
8. Save the analysis. .logopen C:\dumps\analysis_<DATE>.txt, run !analyze -v, then .logclose. This produces the artifact to attach to a Siemens support request (Siemens SR).

Alternative Diagnosis Without Symbols

Because private symbols are typically unavailable, build the case from secondary evidence:

When symbols cannot be obtained, the !analyze -v output will still surface the faulting exception code (typically 0xC0000005 ACCESS_VIOLATION or 0xC0000409 STATUS_STACK_BUFFER_OVERRUN for VBScript errors). The faulting module is reported even without PDBs because module names are embedded directly in the PE header.

SCRIPT.EXE Timeout: Engineering Triggers

The SCRIPT.EXE - Status = TIMEOUT event ID 255 is fired when a VBScript or ANSI-C action exceeds the WinCC runtime watchdog. Common causes:

Verification

Confirm the diagnosis landed and the system is healthy by checking all four artifacts together:

1. Dump is healthy: dumpchk -z <file> prints Finished dump check with no errors beyond symbol misses.
2. Event ID 255 stops recurring. In WinCC Alarm Logging, filter EventID = 255 over the next 24 hours.
3. No orphaned SCRIPT.EXE processes. Task Manager shows SCRIPT.EXE only once per project (one instance is normal).
4. Symbol resolution improved. Re-run !analyze -v after applying the WinCC fix; confirm the failing module now resolves to a specific function export rather than a wildcard.

Preventive Measures

• Configure WinCC to retain at least the last 10 dumps: WinCC Explorer → Computer → Properties → Runtime → Dump file retention.
• Schedule a daily copy of \diagnose\Dumps\ to a network share with PowerShell:
  robocopy "C:\Program Files\Siemens\WinCC\diagnose\Dumps" "\\<FILESERVER>\WinCCDumps$\%COMPUTERNAME%" *.dump *.dmp /MAXAGE:7 /MOV /LOG+:C:\Logs\dump_copy.log
• For symbol access on enterprise-supported sites, request a private symbol license through Siemens SR portal referencing the SR number; Siemens Premier Support may release build-specific PDBs.
• Use Process Monitor (procmon.exe) for repro captures when the fault is reproducible — often more decisive than post-mortem dumps.
• Set Windows Error Reporting to Do not send on HMI stations to prevent accidental upload of WinCC dumps to WER servers.

Troubleshooting Matrix

Key WinCC Diagnosis Paths

FAQ