Fixing TIA Portal V13 SP1 Project Crashes in V13 SP2 on Windows 10

Engineers who have legacy STEP 7 / WinCC projects created in TIA Portal V13 SP1 often find that opening those archives in V13 SP2 on a Windows 10 workstation silently corrupts the project state. The TIA Portal tree, device configuration, and program blocks render correctly, the project can be edited, but the moment the engineer triggers a Compile or attempts to Go online, the IDE terminates with an "Unexpected error" dialog (no S7-1200/S7-1500 hex code, no WinCC error number – the process simply exits). Multiple users on the same project tree, working in parallel on different Win10 machines, all report the same behavior, which rules out a single user profile or local security policy issue.

This reference documents every practical recovery path, the actual TIA Portal V13 SP1 → SP2 mechanics, the locations of the diagnostic log files, the registry keys that influence the upgrade dialog, and the supported end-of-life paths for the V13 line. It is written for automation engineers who cannot move to V14/V15/V15.1 and cannot maintain a Windows 8 VM for the lifetime of a still-running plant.

1. Problem Statement and Symptom Matrix

The reported failure pattern is reproducible across multiple installations and looks like this:

The fact that the original V13 SP1 / Windows 8 combination still works, while the same archive fails on V13 SP2 / Windows 10, points to either a TIA Portal V13 SP2 engine regression or a project-cache incompatibility that V13 SP1 was masking.

2. Affected Environment and Compatibility Matrix

TIA Portal V13 was released with explicit OS support that changed between Service Packs. The matrix below is the working reference for the V13 line.

Two facts matter for this fault:

1. V13 SP2 is the last TIA Portal release where SP1 archives are still accepted as input. The V13 SP2 engine still contains the ProjectUpgrader path for SP1 → SP2; V14 drops that path and forces a one-way upgrade.
2. V13 SP2 was the first release of TIA Portal that was certified for Windows 10, but only for build 1507 (TH1) and 1511 (TH2). Build 1607 (RS1, Anniversary Update) and later added security mitigations (e.g. ASLR hardening, controlled folder access) that interfere with the way V13 SP2 was built (mixed C++/C# with CEF/WPF, signed with SHA-1 certificates that Win10 1709+ blocks in some configurations).

Refer to the official release notes portal at TIA Portal V13 SP2 release notes (entry ID 109311041) and the compatibility tool for SIMATIC software before assuming any combination works.

3. Root Cause Analysis

From the symptom pattern and the underlying V13 SP2 architecture, four root causes account for almost every reported "open OK / compile crash" or "open OK / go online crash" instance on Windows 10:

3.1 The SP1 → SP2 upgrade dialog is suppressed

V13 SP2 checks a project-cache marker (ProjectConfiguration.xml inside the System\<guid>\ folder) to decide whether the archive needs upgrading. When V13 SP2 sees a marker it does not recognise, it tries to migrate silently and stores an intermediate hash that is then rejected by the compile engine. The "no upgrade prompt" symptom is the visible side of that silent migration.

3.2 Windows 10 build > 1511 + V13 SP2 SHA-1 driver signing

The S7-1200 / S7-1500 online stack in V13 SP2 uses a kernel-mode component (s7onlinx.dll + Siemens.Automation.Portal.Connectivity). On Windows 10 builds 1607 and later, the SCEP/SmartScreen filter rejects the embedded SHA-1 signature on certain ISO images of V13 SP2. The compile crash and the go-online crash are different code paths that both touch this signing layer, which is why the same fix repairs both.

3.3 .NET Framework 4.6/4.7 collision

V13 SP2 was validated against .NET 4.5.2. Windows 10 1607 ships .NET 4.6.2, and 1703+ ships .NET 4.7. WPF binding redirects inside the TIA Portal shell fall back to a manifest that does not exist on Win10, throwing FileNotFoundException inside Siemens.Simatic.Hmi.WpfFramework.dll. The "unexpected error" dialog is the unhandled-exception catcher for that exception.

3.4 User profile redirection and roaming cache

Large plants often deploy V13 SP2 from a network share with redirected %APPDATA%\Siemens\Automation folders. The first compile builds an index in the user cache; the second compile, on a different machine, tries to re-use the index. The hash mismatch produces a crash in S7Comp.

4. Pre-Repair Diagnostics

Run the checks below in order. Stop at the first one that fails – it is almost certainly the actual root cause for the instance you are looking at.

4.1 Confirm the Windows 10 build and the .NET version

1. Press Win + R, enter winver. Record the build (e.g. 15063 = 1703, 16299 = 1709, 17134 = 1803, 17763 = 1809, 18363 = 1909, 19041 = 2004).
2. Open regedit and navigate to HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full. Record Release:
   • 394802 = .NET 4.6.2
   • 460798 = .NET 4.7
   • 461308 = .NET 4.7.1
   • 461814 = .NET 4.7.2
   • 528040 = .NET 4.8

V13 SP2 is rated for .NET 4.5.2 through 4.6.2 only. Builds higher than 394802 are the most common cause of compile crashes; the IDE itself launches because of API forward compatibility, but the WPF resource loader in TIA_Portal.exe is not.

4.2 Locate the actual TIA Portal installation

Record the install path (typically C:\Program Files\Siemens\Automation\Portal V13 SP2\). The version reported in the Help → About box is the portal build, not the SP2 update level. The SP2 Update level is reported by Siemens.TIA.Portal.Solution.exe in Common\TIA_Version_Info.txt.

4.3 Capture the crash window

On a clean test bench, install Sysinternals ProcDump and create a service rule:

The resulting TIA_Portal_<date>_<pid>.dmp file is a full user-mode dump that the Siemens support team can read. Keep at least the most recent three dumps from three different crash types (open + compile, open + go online, open + download).

5. Step-by-Step Solution A: Patch V13 SP2 to Update 4

Many V13 SP2 installations were never patched past Update 1. The compile crash and the go-online crash were both fixed in V13 SP2 Update 4 (released 2018-05). The patches are cumulative, so installing Update 4 is sufficient.

1. Download the latest V13 SP2 Update from the SIMATIC software compatibility & download portal. Look for entry ID 109751499 → "SIMATIC TIA Portal V13 SP2 Update 4". The archive is roughly 4.5 GB and is delivered as multiple .zip parts.
2. Stop every TIA Portal-related service:

   net stop "Siemens.Automation.Portal.Solution.13.0" 
   net stop "Siemens.Simatic.S7WebService.13.0" 
   net stop "Siemens.Automation.PortalWeb.13.0"

3. Disable antivirus real-time scanning on the install path. TIA Portal's setup writes to Program Files, and Windows Defender's controlled-folder access can block it silently.
4. Right-click TIA_Portal_V13_SP2_Update_4.exe → Run as administrator. The installer is offline; it does not require a live Siemens license server during the patch.
5. When prompted, choose Repair (not Modify) so that the SHA-1 driver signature is replaced with the SHA-256 one shipped in Update 4.
6. Reboot. Verify the new build by reading %ProgramFiles%\Siemens\Automation\Portal V13 SP2\Common\TIA_Version_Info.txt. The line should read V13.0 SP2 Upd 4 (build 13.0.1.4 internally).
7. Open the project. The upgrade prompt will now appear. Accept it and let V13 SP2 write a fresh ProjectConfiguration.xml.

6. Step-by-Step Solution B: Project Cache Reset

If the IDE still crashes after Solution A, the user-side cache is stale. The cache lives in three locations; all three must be cleared.

1. Close TIA Portal completely (check Task Manager → Details for TIA_Portal.exe and Siemens.Simatic.S7WebService.exe – both must be gone).
2. Stop the Siemens Automation License Manager service and the Siemens SIMATIC Communication service.
3. Delete the three directories above. Do not simply rename them – leave a sibling empty folder for the IDE to recreate.
4. Re-launch TIA Portal V13 SP2 Update 4. The first launch will take noticeably longer (it re-hashes the catalog).
5. Open the project with File → Open → Project from TIA Portal V13 SP1 archive and confirm the upgrade dialog.

7. Step-by-Step Solution C: Forced Project Re-target

For projects where the upgrade dialog never appears even after Solutions A and B, the archive itself has a corrupted internal marker. The forced re-target procedure rebuilds the marker without modifying the program code.

1. Make a working copy of the original .ap13 archive.
2. Extract the archive: every .ap13 is a standard ZIP. Use 7-Zip with password unknown – Siemens does not encrypt the project container by default. 7z x project.ap13 -o"D:\work\project"
3. Open the System\<guid>\ProjectConfiguration.xml in Notepad++. Look for the <PortalVersion>V13.0 SP1</PortalVersion> tag. Change it to V13.0 SP2 and save.
4. Re-zip the folder tree with the same internal structure (do not put a top-level folder inside the ZIP): 7z a -tzip project_sp2.ap13 "D:\work\project\*"
5. Open project_sp2.ap13 in V13 SP2 Update 4. The upgrade dialog will appear once and write a clean marker.

8. Library and Hardware Catalog Re-synchronisation

Even with the upgrade dialog now appearing, the compile step can still crash if a used library or a hardware module was added to the project after the original SP1 export. The catalog of devices and the catalog of libraries are independent caches inside V13 SP2.

8.1 Re-install the HW catalog

1. Open Options → Support Packages. The list shows every HW package currently installed (e.g. S7-1500 CPU 1515-2 PN V2.6).
2. Click Add from file and select the same .spk files originally supplied with the project. Siemens ships them under SupportPackages\HW in the project archive.
3. If a package version is missing, download it from the HSP (Hardware Support Package) download portal. For V13 SP2 the catalog ID range is 0001–0418.
4. Re-open the project, then run Project → Compile → Software (rebuild all).

8.2 Re-install user libraries

Open Libraries → Global libraries. For each library reference that shows a yellow triangle, right-click → Update library and point at the .al13 originally exported with the project. This rebuilds the type table that S7Comp needs at compile time.

9. Log File and Crash Dump Analysis

Every V13 SP2 instance writes structured logs that pinpoint the exact subsystem that crashed. Knowing the path of each log is the difference between a 5-minute fix and a two-day ticket with Siemens support.

For a compile crash, look in S7Comp.log for lines containing Fehler 0x or Internal compiler error. For a go-online crash, look in LogFile_Connectivity.log for TLS handshake failed – that is the SHA-1 signature symptom described in §3.2.

9.1 Quick correlation via PowerShell

Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='Application Error'} -MaxEvents 20 |
  Select-Object TimeCreated, Id, @{N='FaultMod';E={$_.Message | Select-String -Pattern 'Faulting module name: (\S+)' | %{$_.matches[0].groups[1].value}}},
                        @{N='Offset';E={$_.Message | Select-String -Pattern 'Fault offset: (\S+)' | %{$_.matches[0].groups[1].value}}} |
  Format-Table -AutoSize

The two columns FaultMod and Offset can be searched in the Siemens Knowledge Base by entering them in the search bar – Siemens publishes an internal error code map per DLL.

10. Registry Keys that Influence the Upgrade Dialog

The "no upgrade prompt" behaviour is partly driven by registry markers that survive a TIA Portal uninstall. Cleaning them forces a full project re-validation.

To force a clean re-validation without losing your hardware interface selection:

1. Export HKCU\Software\Siemens and HKLM\SOFTWARE\Siemens as .reg files for backup.
2. Delete the Portal V13 SP2\ProjectCache sub-tree.
3. Set SkipMigrationPrompt to 0 (or delete the value).
4. Verify that PGPCInterface is a valid Set PG/PC Interface entry by opening the Siemens control panel applet. If it is blank, re-select the TCP/IP adapter bound to the Profinet/Profibus network.
5. Re-launch TIA Portal.

11. Connectivity and Online Crash Isolation

The "open OK / go online crash" failure mode has its own narrower diagnostic tree. Walk through it before assuming the project is corrupt.

1. PG/PC interface validation. Open Start → Siemens Automation → Set PG/PC Interface. Confirm the interface selected matches the adapter used for the CPU. Mis-matching the S7-1200 interface (TCP/IP auto) with an S7-1500 project that expects ISO-on-TCP causes the handshake to time out and the IDE to crash during cleanup.
2. TSAP / Rack / Slot match. The first go-online after an upgrade negotiates a new TSAP. If the CPU was re-assigned a different IP via the display or via SIMATIC Automation Tool, the project is stale. Right-click the device → Online & Diagnostics → Go online → Show accessible nodes first, then select the actual node.
3. Disable Windows Firewall temporarily. Win10 1709+ adds a default-deny rule for inbound TCP/102 that is reset on every major update. The S7Comm handshake uses TCP/102; a silent drop shows up in LogFile_Connectivity.log as connection reset after SYN_SENT.
4. Check protected-mode settings. Open Control Panel → Internet Options → Security → Trusted sites and add the URL pattern that V13 SP2 uses for its built-in help. Some Win10 builds flip the protected-mode flag for intranet zones, which the TIA help frame interprets as an XSS exception and exits the process.
5. Disable controlled folder access. Windows Security → Virus & threat protection → Ransomware protection → Controlled folder access. If C:\Program Files\Siemens is in the protected folder list, the S7-1200/S7-1500 driver write fails and the IDE exits cleanly (with status 0xC0000409) instead of recovering.

12. Long-Term Workarounds when V13 Cannot Be Patched

Some plants cannot install any V13 SP2 update because the original engineering team left and the floating licenses are tracked against the SP2 base. In that case the supported workarounds are:

1. Install V13 SP2 Update 4 in a Windows 10 Pro 1809 (LTSC) image. The LTSC branch disables Microsoft Store auto-updates and never crosses the .NET 4.8 boundary. This is the closest in-place approximation of a Win8 + V13 SP1 environment that still uses Win10 drivers.
2. Run V13 SP2 in Windows 7 compatibility mode. Right-click TIA_Portal.exe → Properties → Compatibility → Run this program in compatibility mode for Windows 7. Disable full-screen optimisations and run as administrator. This fixes the WPF resource loader, but does not fix the SHA-1 driver signature issue on Win10 1709+.
3. Migrate the project to V14 SP1. The 14 SP1 line is the first release that fully supports Windows 10 1809+ and removes the SP1/SP2 dual code path. The migration is mostly automatic – the V14 upgrade wizard reads SP1 and SP2 archives directly. See entry ID 109746678 for the migration matrix. The only manual step is replacing any SFB calls deprecated in V14 (mainly SFB 3 / SFB 4 in older S7-300 integration blocks).
4. Maintain a Windows 8.1 VM only for the SP1 archive. Use the V13 SP1 image for compilation and download, use V13 SP2 / Win10 only for editing and trace review. Keep the VM on a static internal disk; the network license server will serve both instances simultaneously as long as both machines are on the same licence subnet.

13. Escalating to Siemens Technical Support

When none of the procedures above resolves the crash, open a Support Request through the Siemens Industry Online Support portal. The request must include the following artefacts – support will bounce a request that does not include them:

1. Three crash dumps from three different sessions (ProcDump, as described in §4.3).
2. The full %LOCALAPPDATA%\Siemens\Automation\Logfiles folder of the day of the crash.
3. The output of winver and the .NET release value from §4.1.
4. The exact text of the "Unexpected error" dialog (the dialog title bar is usually Siemens TIA Portal has stopped working; the body contains a correlation ID that Siemens tracks internally).
5. The ProjectConfiguration.xml of the failing project (sanitised – replace plant names but keep the PortalVersion and the device counts).
6. The MD5 of the .ap13 archive. Siemens cross-references the hash against the field defect database and may already have a published fix for that exact build.

Reference the underlying Siemens entry IDs 109311041 (TIA Portal V13 SP2 general) and 109482382 (Windows 10 compatibility) when filing – the support engineer can pull them up immediately.

14. Best-Practices Checklist to Prevent Recurrence

15. FAQ