Troubleshooting WinCC V13 KTP700 Simulator Crash on TIA Portal

Problem Description: WinCC V13 Basic Simulator Crash on KTP700 / KTP900

The WinCC V13 SP1 Update 4 Basic Simulator for the Basic Panel line (KTP700, KTP900, KTP700F Mobile, KP300 Basic mono PN) terminates abruptly the moment the runtime is launched from the TIA Portal HMI editor. The failure occurs in three reproducible ways, depending on the underlying cause:

1. Immediate exit (silent) — the RT loader flashes for <500 ms and the WinCC RT process disappears. No Siemens popup appears; only the standard Windows "RT has stopped working" dialog is shown.
2. Crash with WerFault.exe event — Windows Error Reporting logs Application Error 1000, faulting module HMIRTM.exe, exception code 0xc0000005 (access violation) or 0xc0000409 (STATUS_STACK_BUFFER_OVERRUN).
3. Crash after one week of work — the project compiled correctly for several days; the simulator only fails once the project passes approximately 6–8 days or 40–60 screen edits. This is the classic "file-share lock" symptom.

The crash is not observed on a real KTP700 panel — only the on-screen RT simulator fails. This is a key diagnostic indicator: the offline ES data is valid, but the simulator host process cannot initialize its graphics heap or cannot resolve a path to the runtime resources.

Affected Software and Hardware Matrix

Root Cause Analysis

The V13 SP1 Update 4 simulator has four layered failure modes. They often combine in the same machine, so a single fix rarely closes every case.

Cause 1 — Remote File-Share Locking

WinCC V13 SP1 Update 4 uses an incremental "LDB" lock file (*.lock_ldb) inside the project directory to coordinate the ES, RT and translator processes. On a SMB share (Windows Server 2008 R2 / 2012 R2 without SMB3 continuous availability) the lock release is delayed when the RT process is closed and reopened. After 40–60 open/close cycles the lock is leaked and the next simulator start deadlocks on file open, then exits with access violation 0xC0000005. This is the "works for a week, then fails" pattern.

Cause 2 — Display Driver / D3D Stack Mismatch

HMIRTM.exe initializes a DirectX 9.0c / D3D9Ex surface using the DWM. If the host system falls back to the Microsoft Basic Render Driver (visible in dxdiag > Display > Driver Model: WDDM 1.0), the simulator fails immediately on the IDirect3D9Ex::CreateDevice call.

Cause 3 — Corrupted Project Internal Cache

TIA Portal stores HMI binary artifacts (compiled screens, alarm logs, recipe DB) in .<project>.hmi13 subfolders. A power-loss, AV scan or OneDrive sync can leave the file \IM\HmiEs\gen\resources.bin with a partial write. The simulator rejects it silently.

Cause 4 — Stale Local User Cache

The runtime keeps per-user state under %LOCALAPPDATA%\Siemens\AutomationPortal\V13\CacheRT. When a major project tree restructure happens, the cache references GUIDs that no longer exist; HMIRTM dereferences a null handle and crashes.

Pre-Rebuild Diagnostic Checklist

Before running any repair procedure, capture the following baseline data so you can verify the fix and so that, if Siemens support is needed, the case data is complete.

1. Open Event Viewer > Windows Logs > Application and filter for Source = Application Error, Event ID = 1000 for the last 24 h. Note the faulting module name and offset.
2. Run %PROGRAMFILES(X86)%\Siemens\Automation\S7Trace\S7TraceTool.exe and enable trace category HMIRTM with level Verbose. Restart the simulator and collect the last 200 lines.
3. Open TIA Portal > Project tree > right-click on the HMI station > Properties > Protection & Security and note the project version (you will compare it after rebuild).
4. From a CMD prompt run net use and verify whether the project path is on a UNC share. Note ping <server> -n 20 average latency.
5. Run dxdiag > Display tab; confirm Driver Model is WDDM 1.1 or higher and Direct3D Acceleration is Enabled.
6. Open Programs and Features and confirm .NET 4.6.x is installed and that the latest Windows cumulative update for the OS branch is present (KB dated within 90 days).

Solution 1 — Rebuild All from the Project Tree

This is the highest-yield fix and resolves Cause 3 (corrupted internal cache) in roughly 70 % of cases. The complete procedure:

1. Close TIA Portal completely; confirm S7TraceTool.exe, S7DOS.exe, HMIRTM.exe are absent in Task Manager.
2. Open the project from a local path (see Solution 2 if you currently use a UNC share). Recommended root: D:\Projects\<customer>\<project>\. Avoid the OneDrive and Desktop folders.
3. In the TIA Portal project tree, right-click the top-level project node and select Rebuild all > Rebuild all (recompile). Expect 30–180 s for a typical 50-screen KTP700 project.
4. Wait for the bottom status bar to read No errors. Click Compile > Software (rebuild all) on the PLC station as well so the tag interface matches the new HMI build.
5. Right-click the HMI station > Start simulation. The WinCC RT loader should appear within 3 s and stay open.

Solution 2 — Move the Project Off the Network Share

If your team's workflow stores TIA projects on a file server, configure one of the following before opening the project in V13 SP1 Update 4:

• Local edit, manual sync — copy the entire project folder (including .hmi13, .ap13, *.s7p) to C:\TiaWork\ before opening. Re-sync to the server at end-of-shift using robocopy /MIR /R:3 /W:5.
• Multi-user engineering (server project) — TIA Portal V13 does not support live multi-user editing of the same project. The "multi-user server project" feature only landed in V15.1.
• Offline checkout — open the server copy with File > Open > Project from Server if you must, then immediately Save as local copy on first save.

Acceptable latency threshold: the simulator reliably survives <5 ms round-trip to the project path. SMB shares backed by NAS with 7200 RPM SATA drives typically measure 8–25 ms and reproduce the crash.

Solution 3 — Clear the TIA Local Cache and Reinitialize the Runtime

This addresses Cause 4 (stale per-user cache). The procedure is non-destructive to your project:

1. Close all TIA Portal and simulator windows.
2. Open %LOCALAPPDATA%\Siemens\AutomationPortal in Explorer.
3. Delete the entire V13 subfolder (typical size 80–400 MB). It will be rebuilt on next start.
4. Delete %APPDATA%\Siemens\AutomationPortal\V13\log to force a fresh log session.
5. Delete any orphaned *.lock_ldb files inside the project directory (these can hide inside the .hmi13 archive — check with 7-Zip if necessary).
6. Reopen TIA Portal and rebuild all (Solution 1).

Solution 4 — Verify .NET Framework, Windows Compatibility and Display Driver

Run the following checks before re-trying the simulator:

1. Confirm .NET 4.6.2 (or higher in the 4.x branch) is installed. Validate via reg query "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full" /v Release. The Release key must be ≥ 394802 for 4.6.2.
2. If the host OS is Windows 7 SP1 x64 and .NET is older than 4.5.2, install the .NET Framework 4.6.2 offline installer. Reboot.
3. Install the latest Windows cumulative update for the OS branch. For Windows 7 SP1 this is the April 2018 servicing stack update (KB4132216) plus the monthly rollup. Windows 10 builds newer than 1607 are not supported by V13.
4. Open Device Manager > Display Adapters. If the listed adapter is Microsoft Basic Display Adapter, install the vendor driver (Intel, NVIDIA, AMD). A WDDM 1.1 minimum is mandatory.
5. For VMs, enable 3D graphics acceleration in the hypervisor settings and assign ≥128 MB of VRAM. RDP sessions on Windows Server must enable Use WDDM graphics display driver via Group Policy.

Solution 5 — Repair a Corrupted HMI Project Database

When the simulator crashes on a specific screen or only after certain tag events, the HMI compilation database is the suspect. TIA Portal V13 does not expose a "repair project" command, so the manual procedure is:

1. Close TIA Portal.
2. Make a full backup of the project directory before any change.
3. Inside the .hmi13 archive, extract the IM\HmiEs\gen folder and inspect resources.bin. A valid file is a multiple of 4096 bytes; a corrupted file ends mid-block.
4. Open the project in TIA Portal. Right-click the HMI station > Compile > Software (rebuild all). This forces regeneration of the resources.bin.
5. If the rebuild fails with error "Compilation terminated. Cause: file access error", the project directory is read-only or AV-locked. Temporarily disable real-time AV scanning on the project folder.

Verification Procedure After Repair

1. Start the simulator and leave it running for at least 30 minutes while cycling screen changes every 30 s. This reproduces the original "week-long" failure pattern in compressed form.
2. Force a screen change that loads every screen in the project (use the built-in Area pointer > Screen number with a script that increments 1..N).
3. Open S7TraceTool with HMIRTM at Verbose. Confirm there are no entries with severity ERROR for at least 15 minutes.
4. Close and reopen the simulator 10 times consecutively. If a leaked *.lock_ldb file exists, the 10th reopen will fail. The fix is confirmed if all 10 starts succeed.
5. Download the project to a real KTP700 panel via Ethernet and verify the runtime behavior matches the simulator. This step is essential because the simulator and the physical panel share the compiled resources but use different graphics stacks.

Escalation Path: When to Send the Project to Siemens Support

If Solutions 1 through 5 fail and the simulator still crashes on a clean Windows 7 SP1 x64 + .NET 4.6.2 + native vendor GPU installation, the project file itself is corrupted beyond in-place recovery. In that case:

1. Run Project > Archive > Archive to produce a single .zap13 file. This compresses the entire project including the .hmi13 internals.
2. Open a support request at Siemens Industry Online Support, category Automation > TIA Portal > HMI. Provide the .zap13, the S7Trace log and the Event Viewer Application Error entry.
3. Reference the Siemens entry ID 109311706 (TIA Portal V13 SP1 release notes) and ask for confirmation that the build hash of your installation is in the "known-bug" list. Updates to TIA Portal V13 SP1 Update 5 / Update 6 / Update 7 patch the simulator lock-file leak; an update often resolves the issue without manual project repair.

Prevention and Field-Engineering Best Practices

For engineering teams that must remain on V13 SP1 Update 4 (because of plant-standardized upgrade procedures), the following practices prevent recurrence:

• Establish a project root policy: D:\TiaProjects\<customer>\<project>\<station>\. Never edit directly on a UNC share.
• Schedule a weekly "rebuild all" step on a designated build workstation; commit the resulting archive to version control. Even if the local workstation does not crash, the rebuild regenerates the .hmi13 internals and prevents long-term drift.
• Lock the OS image. Windows 10 1703 / 1709 / 1803 break V13 in unpredictable ways. If a Windows 10 host is mandated, lock to 1607 (LTSB 2016) with the V13 compatibility shim.
• Disable Windows Search Indexer and OneDrive on the project root folder. Both can hold transient handles that the simulator interprets as leaked locks.
• Document the GPU model in the workstation spec. Reject any workstation issued with the Microsoft Basic Render Driver.

Decision Flowchart

Related WinCC V13 Issues Cross-Reference