Resolving WinCC v7 SP3 Graphics Runtime Crash from Firewall

Problem Overview

On a Siemens SIMATIC IPC running Windows XP SP3 with WinCC V7 SP3 (TIA predecessor generation), the Graphics Runtime can hang intermittently. The picture does not redraw, input events stop responding, and the WinCC explorer process appears frozen in Task Manager. The Windows Application event log shows consecutive Application Error records against svchost.exe rather than against the WinCC process itself, which leads most technicians down the wrong path looking for an HMI project fault.

The actual root cause in this class of fault is a Windows service dependency failure: the Windows Firewall/Internet Connection Services (ICS) host process (svchost.exe) crashes and takes the dependent WinCC runtime services down with it. The faulting module reported in the event is always unknown, version 0.0.0.0 with fault address 0x00000000, which is a signature of a service-host failure rather than a WinCC application fault.

Affected Environment

Symptoms

• Graphics Runtime process appears to "hang" — picture freezes, no redraw, no mouse focus changes.
• Periodic spontaneous exits of svchost.exe in Task Manager (multiple svchost.exe rows, one keeps disappearing).
• Windows generates a popup: "Windows cannot start the Windows Firewall/Internet Connection Services (ICS) service."
• After the popup, the runtime freezes within 30–120 seconds.
• Restarting only WinCC Runtime does NOT resolve the issue; it returns within minutes.
• Event Viewer → Windows Logs → Application shows two recurring entries (Event ID 1004 and 1000) from source Application Error.

Event Log Decode

The two records produced by a single crash cycle look like this on a WinCC V7 SP3 / WinXP SP3 IPC. Pay close attention to the faulting module unknown, version 0.0.0.0 and fault address 0x00000000 pair — they are diagnostic of a service-host failure, not a process DLL fault.

The fault data (ASCII-decoded from the binary 78-byte record) reads "Application Failure 0.0.0.0 in unknown 0.0.0.0 at offset 00000000 000000d4". The trailing 0xd4 is the Windows error code 0xC0000005 (ACCESS_VIOLATION) in the lower bits of the 32-bit word; the high 16 bits are 0, so the read is sometimes logged as 0xC0000005 truncated. This is the Windows XP service control manager signal that one of the services hosted by svchost.exe -k netsvcs failed to register.

Root Cause

WinCC V7 RT on Windows XP ships with a WinCC-specific firewall configuration that opens TCP/UDP ports for Alarm Logging, Tag Logging, Server/Client, and Redundancy. When the Windows Firewall/Internet Connection Sharing (ICS) service cannot start — typically because:

1. TCP/IP stack corruption (e.g., after an unclean shutdown on the IPC),
2. Conflicting third-party firewall/security suite (Symantec, McAfee, Trend, G Data) installed on the same machine,
3. Missing or corrupted ipnathlp.dll / iphlpapi.dll / winsrv.dll system files,
4. Group Policy or registry override disabling the service (SharedAccess key set to 4 = disabled),
5. WinCC project importing an old WinCCFirewallConfig.xml referencing obsolete port rules,

…the service control manager terminates the entire svchost.exe -k netsvcs process group. WinCC runtime services that were registered in the same service group are killed by the cascade, even though they are not the cause of the original fault. The Graphics Runtime client process is left in a half-dormant state that presents as a "hang" rather than a clean exit, because the underlying channel DLL has not completed its termination handshake with the WinCC Server.

Solution

Step 1 — Re-establish the Windows Firewall/ICS Service

1. Open Control Panel → Administrative Tools → Services.
2. Locate Windows Firewall/Internet Connection Sharing (ICS).
3. Set Startup type to Automatic. If it is set to Disabled in the registry (HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess → Start = 4), change to 2 (Automatic) and reboot.
4. Start the service. If it refuses to start with error 1075 (dependency does not exist), check the DependOnService multi-string value — it must contain Netman, RpcSs, and WinMgmt.

Step 2 — Reapply the WinCC Firewall Rules

WinCC V7 SP3 ships a configuration tool that writes the port exceptions into the Windows Firewall policy. The correct path and command for silent re-apply is:

C:\Program Files\Siemens\Automation\WinCC\bin\WinCCFirewallConfig.exe /apply
C:\Program Files\Siemens\Automation\WinCC\bin\WinCCFirewallConfig.exe /verify

If the executable is missing, the rules can be re-imported from the WinCC installation media at WinCC_V7_SP3\InstData\Firewall\WinCCFirewallConfig.xml. Required ports for a single-station WinCC V7 RT:

Step 3 — Clean the WinCC Diagnostic Folder

Stale diagnostic files can mask the real cause and slow the next analysis. The Siemens diagnostic system writes to:

C:\Program Files\Siemens\Automation\WinCC\diagnose\
C:\Program Files\Siemens\Automation\WinCC\WinCCProject\diagnose\  (project-relative)
%TEMP%\PMDiagnose\*.log

1. Stop the WinCC Runtime and the WinCC Configuration Studio.
2. Copy any PMDiagnose.log, CCError.log, and RTTrace.log to a separate folder (do not delete the original until verification is complete).
3. Delete the contents of the three folders above.
4. Start WinCC Explorer, activate the project (RT Start), and let it run.
5. Wait for the error to reoccur (or for the issue to not reoccur after 24 hours of operation).
6. Collect the freshly generated log files for review.

Step 4 — Review the WinCC Release Notes for Operating Notes

The official WinCC V7 SP3 release notes — accessible inside the WinCC Information System under Release Notes → Notes on Operation → Microsoft Windows Security Settings — contain a dedicated section on firewall configuration. Always cross-check against the latest edition of the documentation that ships with your installed Update / Hotfix level (e.g., V7 SP3 Update 5 added rules for the new WebNavigator V7 SP3 HTTPS listener on 443). See the live Siemens support pages for the current revision:

• WinCC V7 SP3 — Operating Instructions (Siemens Support entry 109750609)
• WinCC V7 SP3 Release Notes / Readme (entry 109739186)

Verification

1. Service persistence: After reboot, sc query SharedAccess must return STATE: 4 RUNNING with START_TYPE: 2 AUTO_START.
2. Event log clean: No new Event ID 1000 / 1004 Application Error records after 24 hours of normal operator traffic.
3. Runtime uptime: Run WinCC RT for at least 8 hours with full picture-change load. The runtime must not freeze.
4. Firewall rules applied: Run netsh firewall show config (XP-style) or netsh advfirewall firewall show rule name=all and confirm the WinCC entries are present and Enabled = Yes.
5. Connectivity check: From a WinCC Client, use telnet <server> 2308 — the connection must open. Repeat for 4897, 5555, 5566.
6. Diagnostic sweep: Confirm PMDiagnose.log is recreated and shows no FATAL or EXCEPTION entries related to CCRtV7.exe.

Troubleshooting Matrix

Winsock / TCP-IP Reset (Use Sparingly)

If the Firewall/ICS service refuses to start after dependency repair, the TCP/IP stack on Windows XP may need to be reset. Run from an elevated command prompt:

netsh int ip reset resetlog.txt
netsh winsock reset catalog
netsh firewall reset
shutdown /r /t 0

Re-apply the WinCC firewall configuration from Step 2 after the reboot. This sequence is destructive: any third-party VPN adapters, custom Winsock LSPs, and non-Microsoft firewall hooks will be removed. Re-install them only after WinCC runtime is verified stable for 24 hours.

Why This Misleads Engineers

The symptoms strongly mimic a WinCC project fault: the runtime is the visible artifact that stops working. The Application Error log names svchost.exe, which most operators do not associate with WinCC. The combination of an "empty" faulting application name and a service-host fault is unique to service-group cascades, and the dependency chain (Firewall → ICS → Netman → WinCC) is documented only in the WinCC V7 release notes — not in the main operator manual. Always read the Notes on Operation section before assuming a project fault.

Related Configuration Checks

• DCOM: WinCC V7 RT uses DCOM for server/client. Confirm dcomcnfg → Default Properties → Enable Distributed COM on this computer is checked, and the Default Impersonation Level is Identify.
• SQL Server: Confirm the WinCC SQL instance named WINCC is started and the SQL Server (WINCC) service is Automatic with the service account having Perform volume maintenance tasks privilege.
• User Rights: The runtime user must be a member of SIMATIC HMI, SQLServer2005MSSQLUser$<machine>$WINCC (or the equivalent for the installed SQL version), and Performance Log Users.
• Antivirus exclusions: Exclude C:\Program Files\Siemens\Automation and the project path from real-time scanning. See entry 109750609, appendix "Antivirus software compatibility list".
• Windows Update: KB967715 and KB2510581 (XP) address the original svchost.exe crash class. Confirm both are installed.

Field-Proven Caveats

• Do not disable the WinCC diagnostic folder cleanup. The PMDiagnose logs are the only way Siemens Technical Support can triage a fault remotely — they require PMDiagnose.log and CCTraceRt.log in addition to the OS event log.
• The netsh firewall command set is deprecated in Windows Vista and later, but on Windows XP SP3 it is the canonical way to verify that WinCC rules are loaded. On Windows 7 / Server 2008 R2 and later, use netsh advfirewall.
• On Siemens IPCs with pre-installed SIMATIC images, the Firewall service is sometimes set to Disabled by the manufacturer image to speed up boot. Restore it to Automatic before commissioning the WinCC runtime.
• If the machine is on a plant network behind a managed switch, a spanning-tree reconvergence can momentarily drop the NIC link and crash the ICS service. Enable PortFast on the IPC switch port and disable Energy Efficient Ethernet on the IPC NIC.
• Do not use the Windows XP built-in Internet Connection Firewall (ICF) and a third-party host firewall simultaneously — they will tear down svchost.exe -k netsvcs within minutes of activation.

When the Issue Persists After All Above

1. Capture a full PMDiagnose.log from a clean diagnostic directory (Step 3 above).
2. Capture the full CCError.log from <Project>\diagnose\.
3. Export the Windows Application event log as .evtx covering the 30 minutes before and after the crash.
4. Run msinfo32 /report c:\diag\msinfo.nfo and systeminfo > c:\diag\sysinfo.txt.
5. Open a support request at Siemens Industry Online Support with the WinCC project version (e.g., V7.3.3.4) and the IPC type (e.g., 6AG4114-3...), and attach the four artefacts above.

FAQ