Resolving TIA Portal Multiuser Check-in Crash on Project Server

Multiuser engineering in TIA Portal (V15.1 through V19) relies on a centrally hosted project server that all editors commit changes into. When the TIA Portal client crashes during the Check-in action—most often with large HMI delta sets—the local session becomes locked, the carry-over objects pile up, and follow-up commits fail until the project is rebuilt. This reference documents the root causes, the official Siemens fix path (109971630 - TIA Portal crashes when compiling the PLC), and a field-proven archive/restore recovery that resolves the lock without losing committed work.

1. Problem Description

The failing installation in this case was TIA Portal V17 Update 5 on Windows 10 Pro 22H2, hosted against a SIMATIC Project Server running inside a Windows Server 2019 virtual machine. The engineering workstation connected to the server over a corporate VPN tunnel. The project contained:

• 1 master HMI (Comfort Panel TP1500, WinCC Comfort/Advanced V17)
• 5 secondary HMIs (TP700/TP1200, WinCC Comfort/Advanced V17)
• 6 SIMATIC S7-1500 PLCs (CPU 1515-2 PN, firmware V2.9)
• ~3,200 HMI tags, ~280 screens, shared text lists and graphics lists

Small check-ins (one or two HMI screens, a single tag rename) completed without issue. The crash was reproducible when the editor attempted to commit a delta set covering five or more screens, a text list regeneration, or any cross-HMI tag rename that propagated through the master HMI into the secondary panels. The exception was raised inside the WinCC compile service (S7WCComp.exe) and the TIA Portal shell (S7TGTOPX.exe) exited with code 0xC0000005 (access violation) followed by Windows Error Reporting entry Application Error 1000.

2. Why the Crash Happens: Root Cause Analysis

Siemens' official knowledge base entry 109971630 identifies the root cause as a defect in the TIA Portal compile pipeline when an implicit compile is triggered as part of a higher-level action. The defect is independent of the network path; it is observable on a local server, but VPN latency, MTU fragmentation, and RPC retransmits amplify the symptoms because the multiuser backend (MS-SQL based project server) hands a stale handle back to the client when the implicit compile aborts.

Three contributing factors stack on top of the compile defect:

3. Confirming the Fault: Diagnostic Procedure

Run the following checks in order before applying a fix. Each step isolates one contributing factor.

1. Capture the Windows application event: Open eventvwr.msc and read Windows Logs → Application. The crash produces Application Error event ID 1000 with faulting module S7WCComp.dll or TDKeyNote.dll, exception code 0xC0000005. Note the offset address and TIA Portal build number (Help → About).
2. Reproduce on a local server: Copy the server project to a local directory, open it as a server project on the same subnet, and attempt the same Check-in. If the local copy crashes, the issue is the compile defect (109971630) and not the VPN.
3. Measure implicit compile duration: In TIA Portal, open the local session and force a compile of the master HMI (right-click → Compile → Software (rebuild all)). A successful compile under 60 s is normal. A compile that exceeds 120 s before the crash indicates carry-over object bloat.
4. Inspect the local session folder: Navigate to %LOCALAPPDATA%\Siemens\Automation\ProjectServer\<ProjectName>\<SessionID>. A folder larger than 2 GB or with more than 60 000 files points to carry-over object accumulation from repeated cross-HMI overlays.
5. Validate the VPN path: From the engineering workstation, run Test-NetConnection -ComputerName <server-VM> -Port 4410 (the default SIMATIC Project Server TCP port). Also test UDP 49152–65535 for PROFINET DCP if device discovery is required during compile. Dropped packets or latency above 80 ms RTT increase crash probability.

4. Primary Fix: Apply the Siemens Hotfix from 109971630

The supported resolution from Siemens is documented in entry 109971630:

1. Open the Siemens Industry Online Support entry and identify the affected TIA Portal version and update level.
2. Download the matching hotfix package (for example, TIA Portal V17 Update 6 HF01 or V18 Update 2 depending on your installed base).
3. Close all TIA Portal instances and the TIA Portal Help System.
4. Run the hotfix installer with administrator rights. The installer patches S7WCComp.dll, TDKeyNote.dll, and S7TGTOPX.exe in the TIA Portal installation directory.
5. Reboot the workstation and re-open the multiuser project. Verify the build number in Help → About reflects the hotfix.
6. Perform a single Check-in on a 1-screen delta to confirm the crash no longer reproduces before resuming production work.

5. Secondary Recovery: Archive and Restore the Locked Local Session

Even after the hotfix is applied, an already-locked local session cannot be salvaged. Use the archive/restore path to recover the committed work and clear the carry-over objects.

1. Identify the last good server revision: In TIA Portal, switch to the Server Project View, right-click the project, and select Manage Versions. Note the version number that existed before the crashing Check-in.
2. Open a clean local session on the previous good version: Open → Open project from server, choose that revision, and create a new local working session. This local session is guaranteed not to contain the corrupt carry-over objects.
3. Archive the project locally: With the clean local session open, choose Project → Archive. Select User-defined path and target a folder with at least 5 GB free. The archive operation strips the local session metadata, leaving only the canonical project content. .zap17 (V17), .zap18 (V18), or .zap19 (V19) is produced.
4. Restore the archive on the server: On the server VM (or via RDP/console, not over the VPN), start TIA Portal and choose Project → Retrieve. Point at the archive. This rebuilds the multiuser server project from scratch with no carry-over residue.
5. Re-create a new local session: From the engineering workstation, open the server project, create a fresh local session, and re-apply any in-flight edits that were not yet committed. Check in small deltas (one screen, one tag) until confidence in the hotfix is established.

6. Eliminate the VPN as a Variable

The VPN is rarely the root cause but is a frequent amplifier. If the crash persists after the hotfix and the archive/restore cycle, validate the network path:

• TCP 4410 (SIMATIC Project Server) must be open bidirectionally.
• TCP 102 (S7 communication) is required for online operations during compile.
• UDP 49152–65535 may be required for PROFINET DCP device discovery if the implicit compile needs to resolve the PLC online.
• RDP port 3389 is recommended for a console session into the server VM during heavy Check-in operations to bypass the VPN for the SQL transaction path.

Set the VPN MTU to 1380 bytes or lower to avoid fragmentation of the multiuser RPC packets. Enable TCP keepalives at 30 s with a 60 s interval on the VPN client. A common field finding is a stateful firewall silently dropping the RPC retransmits after 120 s; check the VPN appliance logs for asymmetric flows.

7. Long-Term Fix: Refactor to HMI Common Connection and PLC Proxy

For projects with one master HMI and several secondary HMIs that share most screens, the sustainable fix is to remove the screen-overlay workflow. The master/secondary overlay mechanism is what creates the carry-over objects that bloat the local session.

7.1 HMI Common Connection (WinCC Comfort/Advanced and WinCC Unified)

The HMI Common Connection feature lets multiple HMI devices share a single PLC connection defined once at the project level. Open the project in TIA Portal, select Options → HMI Common Connection, add the participating HMIs, and define the connection once. Each HMI then references the common connection by name instead of carrying its own copy. This reduces the compile surface because tag consistency checks run once per connection rather than once per HMI.

7.2 PLC Proxy (HMI ↔ PLC proxy via WinCC Unified or S7-1500 OPC UA server)

For projects where the HMIs only need read access to a subset of PLC tags, expose the PLC data through an OPC UA server on the S7-1500 CPU (firmware V2.5 and above) and have the HMIs subscribe to the OPC UA tags. The OPC UA path is stateless from the HMI compile perspective, which removes the implicit compile dependency between HMI and PLC targets. This is the most robust long-term architecture for large multiuser projects because the HMI and PLC can be compiled and Checked-in independently.

7.3 Move secondary HMIs to a separate single-user project

If only one engineer maintains the secondary HMIs, split the master HMI and the secondary HMIs into separate single-user projects, linked by a PLC proxy device in the secondary project. The single-user project has no SQL server backend, no carry-over objects, and no Check-in collision. This is the architecture adopted in the field case that produced this article.

8. Multiuser Server Project Best Practices

9. Verification After the Fix

After applying the hotfix and rebuilding the server project from the archive, verify the fix in the following sequence:

1. Open the restored server project and create a new local session.
2. Modify one screen on the master HMI. Compile. Check in. Confirm successful commit and no crash.
3. Modify one tag on a secondary HMI. Compile. Check in. Confirm success.
4. Perform a cross-HMI edit: rename a tag, propagate to master and one secondary, compile both, check in. This is the original failing scenario. Confirm success.
5. Force an implicit compile by initiating a Download to device. Confirm the compile completes without terminating TIA Portal.
6. Inspect Windows Logs → Application for new Application Error 1000 events. None should be present.
7. Check the local session folder size after the cycle. It should remain under 1 GB.

10. Troubleshooting Matrix

11. Frequently Asked Questions