Resolving TIA Portal V18 WinCC Project Download Failures

Problem Overview

Engineers running TIA Portal V18 Update 5 with WinCC Professional V18 — either a single WinCC RT server or a redundant pair — report a fault mode in which incremental and full downloads to the runtime servers appear to succeed instantly yet transfer nothing. The TIA Portal download dialog closes with the message Loading completed (errors: 0; warnings: 0) in roughly 10 seconds, while the runtime project files on the server share retain their previous modification timestamps and WinCC RT continues running the original (pre-change) image.

The fault blocks normal commissioning loops because every subsequent Compile → Software (changes) or Download to device → Software (changes) invalidates the runtime; only a full compile followed by a full download produces a working state. The pattern reproduces with a single WinCC server and with redundancy disabled in the project tree, so WinCC redundancy is not the cause.

Affected Environment

The trigger configuration, taken from the field report and the Siemens V18 documentation set:

Symptoms

1. The first complete download to the WinCC RT servers succeeds and the project runs correctly.
2. As soon as Compile → Software (rebuild all) or Download to device → Software (changes) runs, every subsequent download attempt breaks.
3. Clicking Load in the download dialog (with reset, autostart, and overwrite options set as in the original successful download) causes TIA Portal to display Loading completed (errors: 0; warnings: 0) in approximately 10 seconds.
4. No project data is written to either WinCC server; project file timestamps on the runtime share remain at the values from the first successful download.
5. The Windows Event Viewer on both the engineering station and the runtime servers shows no Application, System, or Security errors related to the download.
6. The fault persists across full reboots of the engineering station and both runtime servers.
7. The fault is observed with WinCC redundancy enabled and disabled in the project tree.

Root Cause Analysis

Packet capture between the engineering station and one of the runtime servers using Wireshark isolates the underlying failure. During the download sequence TIA Portal issues an SMB2 LOCK request (SMB2 command code 0x0010) against a project file on the runtime share, and the SMB server replies with STATUS_LOCK_NOT_GRANTED — NTSTATUS 0xC0000054, decimal -1073741748. TIA Portal uses the LOCK as part of its change-detection workflow: the engineering station locks the runtime project files to enumerate what has changed locally and only re-pushes the diff. When the LOCK is denied, the download worker aborts the operation, the dialog closes, and the result string is built with an empty error list — hence the misleading errors: 0; warnings: 0.

The most common causes of STATUS_LOCK_NOT_GRANTED on the runtime share in this context are:

• Stale file handles held by the WinCC Runtime Service, the WinCC RT IO Server, the WinCC RT Database Server, or the WinCC RT Redundancy process. These services open *.rt, *.lck, *.mo, and the project SQLite database with shared locks that can survive a project close if the service did not cleanly release them.
• Antivirus or backup agents scanning the runtime project folder and holding transient byte-range locks.
• Windows Search Indexer or Volume Shadow Copy (VSS) snapshot operations on the runtime volume.
• DFS-R or Distributed File System Replication staging operations on the project path (relevant if the runtime folder sits on a DFS namespace).
• SMB3 lease conflicts when the engineering workstation requests a write lease while the SMB server already has an outstanding read lease for the same handle.
• SMB session re-authentication latency across an L3 boundary, which can cause the lock request to time out before the SMB server releases a conflicting handle.
• Credential mismatch or token expiry between the engineering user account (used to write the runtime share) and the runtime service account (used to open the project files).

Step-by-Step Diagnosis

Before applying any workaround, confirm the SMB lock hypothesis with the following procedure:

1. Capture the download attempt. Start Wireshark on the engineering station with a capture filter targeting the runtime server's IP and the SMB port:

   ip.addr == <runtime_ip> and tcp.port == 445

   Trigger the download from TIA Portal. Look for an SMB2 packet with command code 0x0010 (LOCK) followed by a SMB2 LOCK Response with Status: STATUS_LOCK_NOT_GRANTED (0xC0000054). You can also filter directly:

   smb2.cmd == 10 and smb2.tree

2. Enumerate open handles on the runtime share. On the engineering station, run:

   Get-SmbSession | Where-Object { $_.ClientComputerName -like "*<engineering_host>*" }
   Get-SmbOpenFile | Where-Object { $_.Path -like "*<projectname>*" }

   Note any files with non-zero GrantedAccess values that overlap the project files.
3. Inspect Windows open files. On the runtime server, run:

   openfiles /query /fo table
   openfiles /disconnect /id <id>

   Or, in PowerShell:

   Get-SmbOpenFile -FileId <FileId> | Close-SmbOpenFile -Force

4. Check WinCC RT services. On the runtime server, verify the state of:

   sc query "WinCC RT"
   sc query "WinCC_RT_IO"
   sc query "WinCC_RT_DB"
   sc query "WinCC_Redundancy"

   If any service is START_PENDING or STOP_PENDING, file handles are likely still held.
5. Inspect Event Viewer for SMB. On the runtime server, open Applications and Services Logs → Microsoft → Windows → SMBServer. Enable the Audit and Lock channels first (they are off by default), then retest the download and look for Event ID 1020 or 1022.
6. Disable third-party filters temporarily. Add real-time AV exclusions for the runtime project folder on each server and for the engineering project folder (<project>\IM) on the engineering station. Reboot both sides and retest.

Resolution and Workarounds

Apply the following remediation steps in order. Stop after each step and retest the download before proceeding.

Workaround 1 — Full Compile + Full Download

This is the only procedure confirmed in the field report to restore the download path:

1. In the TIA Portal project tree, right-click the WinCC RT device and select Compile → Software (rebuild all). Verify the compile completes with no errors.
2. Right-click the WinCC RT device and choose Download to device → Software (full download).
3. In the dialog, select Replace the existing project data, enable Reset runtime, and confirm the autostart options. Press Load.
4. Wait for the actual transfer to complete (typically 60 s – 300 s for a 7-PLC / 2-server project). Do not assume success on the Loading completed string alone.

Workaround 2 — Delete the IM Folder

The TIA Portal IM (Internal Management) folder contains cached compile artifacts that can desynchronise with the runtime share. Deleting it forces a clean rebuild:

1. Close TIA Portal completely on the engineering station.
2. Navigate to <project_root>\<project_name>\IM\.
3. Delete the entire IM folder.
4. Reopen the project. The next compile rebuilds all artifacts from source. Reference: Siemens KB 109778709 — Delete IM folder for a 100% complete fresh compile.

Workaround 3 — Restart WinCC Runtime Services

Restarting the runtime services releases every file handle the lock request was conflicting with. Execute from an elevated command prompt on each runtime server:

net stop "WinCC RT" /y
net stop "WinCC_RT_IO" /y
net stop "WinCC_RT_DB" /y
net stop "WinCC_Redundancy" /y
timeout /t 5
net start "WinCC RT"
net start "WinCC_RT_IO"
net start "WinCC_RT_DB"
net start "WinCC_Redundancy"

After the services are restarted, retry the incremental download.

Workaround 4 — Flush SMB Sessions

Force the SMB server to drop stale sessions between the engineering station and the runtime:

# On the runtime server (PowerShell)
Get-SmbSession | Where-Object { $_.ClientUserName -like "*<eng_user>*" } | Close-SmbSession -Force

# On the runtime server (cmd)
net session | findstr "<eng_hostname>"
net session \\<eng_hostname> /delete

Workaround 5 — Disable SMB OpLocks on the Runtime Folder

If the runtime folder is hosted on a Windows file server share, OpLocks (opportunistic locks) can conflict with TIA's locking model. Disable them via registry:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" /v DisableOpLocks /t REG_DWORD /d 1 /f
net stop LanmanServer /y
net start LanmanServer

Network and Firewall Hardening

The Siemens best-practice topology keeps the engineering station on the same subnet as the WinCC RT servers. When subnet separation is mandatory (for example, a plant policy that forbids placing an engineering workstation on the production VLAN), the following configuration is required:

• Simatic Shell multicast proxy: Configure the multicast proxy on the L3 router so that Simatic Shell discovery packets reach the engineering station. Simatic Shell uses UDP 23272 and 23456, plus the standard WS-Discovery multicast group on UDP 3702. Without the proxy, devices list as empty in TIA Portal even though the IP is reachable.
• Windows Firewall rules: Add inbound and outbound rules for all SIMATIC-related executables per Siemens KB 88780011. Typical paths:

  %ProgramFiles%\Siemens\Automation\SimaticOpcUa\bin\SimaticOpcUaServer.exe
  %ProgramFiles%\Siemens\Automation\WinCC\bin\CCWriteMessage.exe
  %ProgramFiles%\Siemens\Automation\Portal V18\Bin\S7Portal.exe
  %ProgramFiles%\Siemens\Automation\WinCC\bin\CCProjectMgr.exe

  Allow the corresponding inbound ports: TCP 102 (S7 communication), TCP 443 (HTTPS PLC communication), TCP 8888 (Simatic Shell), TCP 445 (SMB).
• SMB signing alignment: If RequireSecuritySignature is enabled on one side but not the other, the SMB LOCK is rejected as a security violation. Align both sides:

  Set-SmbServerConfiguration -RequireSecuritySignature $true
  Set-SmbClientConfiguration -RequireSecuritySignature $true

• SMB multichannel: Disable on the engineering station if it triggers redundant connections through the gateway and back, which can desynchronise file lock state:

  Set-SmbClientConfiguration -EnableMultiChannel $false

• Credential alignment: Use a single domain account with identical credentials on the engineering station and both runtime servers. Mixing local accounts across machines is the leading cause of STATUS_ACCESS_DENIED (0xC0000022) chained behind the lock failure.

Troubleshooting Matrix

Best Practices from Siemens

The following practices are documented in the SIMATIC WinCC V18 configuration manual and the TIA Portal installation guide. They minimise the chance of triggering this failure mode:

Verification Checklist

After applying any workaround, verify success with the following:

1. Download wall-clock time: A successful incremental download for a 7-PLC / 2-server WinCC project typically takes 30 s to 3 min. If TIA Portal reports Loading completed in under 15 s, the operation did not actually run.
2. Runtime project timestamps: Check the project folder on each runtime server. The folder <projectname>\ should show modification timestamps within the last few minutes. Stale timestamps indicate the transfer did not happen.
3. WinCC RT version stamp: In the WinCC RT Explorer on the runtime, open Project → Properties. The compiled timestamp should match the time of the download on the engineering station.
4. Wireshark re-capture: Repeat the packet capture. The SMB2 LOCK request should now complete with STATUS_SUCCESS (0x00000000), followed by SMB2 WRITE requests carrying the project deltas.
5. Event Viewer: Both Application and System logs on the runtime server should show a WinCC RT service stop and start around the time of the download.
6. Project consistency: In TIA Portal on the engineering station, right-click the WinCC RT device and select Compile → Software (check consistency). No errors should be reported.
7. Runtime alarm check: On the runtime, open WinCC RT Control Center and confirm the alarm log shows the expected tags and limits after the download, not the pre-change values.

Field-Proven Caveats

Several edge cases observed alongside this fault are worth recording:

• Build version drift: A field report shows TIA Portal V18 Update 5 (engineering) paired with WinCC RT V18 Update 4 (runtime) continues to allow the first download but silently fails every subsequent change. Aligning both sides to Update 5 resolved the fault without further action.
• SMB 1.0 fallback: Windows can fall back to SMB 1.0 on a per-share basis when SMB signing negotiation fails. Disable the SMB 1.0 client on the engineering station to force SMB 2/3 only:

  Disable-WindowsOptionalFeature -Online -FeatureName smb1protocol-client -NoRestart
  sc.exe config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi
  sc.exe config mrxsmb10 start= disabled

• DNS suffix mismatch: When the engineering station and the runtime are on different subnets, the SMB session may authenticate against a NetBIOS alias rather than the FQDN, producing intermittent STATUS_LOGON_FAILURE (0xC000006D) layered behind the lock denial. Force FQDN use in the runtime UNC path: \\server01.corp.local\WinCC\<project>\ instead of \\server01\WinCC\<project>\.
• AlwaysOn VPN splits: On workstations connected through split-tunnel VPNs, the SMB session may route over the WAN interface while the Simatic Shell multicast stays on the LAN, producing the exact symptom. Connect via LAN or disable the VPN tunnel during commissioning.

Reference Documentation

• Siemens KB 88780011 — TIA Portal / WinCC V18 FAQ on firewall, services, and download prerequisites
• Siemens KB 109778709 — Delete IM folder for a 100% complete fresh compile (TIA Portal V18)
• Siemens KB 109807109 — SIMATIC STEP 7 incl. Safety, S7-PLCSIM, and WinCC V18 trial download

Frequently Asked Questions