Resolving WinCC RT Project Locked and Server Not Found Errors

1. Problem Summary

WinCC RT Professional runtime clients in distributed server/client configurations occasionally fail to open downloaded projects after project modifications are pushed from TIA Portal. The failures present as one or more of three distinct error messages reported by the WinCC RT runtime:

• "Project is locked" – Runtime detects a residual lock file indicating another process owns the project.
• "Server not found" / "Server not available" – Runtime cannot resolve the configured WinCC server endpoint.
• "Project not opened as project could not be opened" – Generic failure during project activation, typically wrapping the underlying lock, server, or path-resolution fault.

In mixed-fleet deployments (four or more clients connected to one server), the failure pattern often presents as a partial outage: some clients activate successfully while two or more remain stuck in error loops. The pattern is repeatable across site deployments running TIA Portal V15 Update 3 (V15.3) and WinCC RT Professional V15.3, particularly across routed subnets where DNS or NetBIOS resolution cannot guarantee computer-name lookup.

2. Affected Versions and Environment

3. Root Cause Analysis

Six interacting causes are responsible for the overwhelming majority of these errors. Each must be ruled out independently before commissioning the multi-client fleet.

3.1 Residual ProjectOpened.lck Lock File

When WinCC RT activates a project, it writes ProjectOpened.lck into the WinCC project folder to claim exclusive access. A previous abnormal termination (ES crash, RT service kill, host reboot during activation) leaves the lock file behind. Subsequent activations fail with Project is locked even though no WinCC process actually holds the file.

3.2 Computer Name vs IP Address Resolution

WinCC RT clients configured with the WinCC server's computer name rely on NetBIOS/WINS broadcast or DNS for resolution. Across routed subnets, broadcasts do not propagate. The RT attempts connection, the resolution fails, and the runtime surfaces Server not found or Server not available. Replacing the computer name with the server's IPv4 address in the project configuration eliminates the dependency on name-resolution services.

3.3 Engineering Station (ES) State During Download

If the ES disconnects from the target device mid-download, the project on the RT is left in a partial state. A second download from the ES is normally required to complete the transfer. This applies to both direct TIA Portal downloads and to compilation-then-archive transfers.

3.4 Service-Mode vs Interactive Login

Running the WinCC RT as a service with no interactive Windows user session disables the shell namespace entries (including Simatic Shell) and certain Win32 file-system notifications. Errors that the runtime masks in interactive sessions (such as activation race conditions) become hard failures in service mode. Configuring WinCC RT to start only after a local interactive logon has been shown to substantially reduce activation errors.

3.5 Multi-Subnet Network Path

The WinCC server/client TCP/IP session depends on the following default ports:

If a router ACL or Windows Firewall rule on the server blocks any of these inbound ports from the client subnet, the RT cannot complete handshake and reports Server not found.

3.6 Multiple TIA Portal Instances and Open HMI Editors

The ES must not hold an exclusive write-lock on the project file at the moment of download. If a TIA Portal instance on a different engineering PG retains the project open, the compile step on the source PG can complete but the download target rejects the transfer. Field practice: close all HMI editor windows, including the WinCC Explorer, before initiating any download.

4. Diagnostic Procedures

Execute the diagnostics in the order below. Each step rules out one root cause before progressing to the next.

1. Confirm TIA Portal and WinCC RT versions: TIA Portal > Help > Installed software. Confirm V15.3 is present, not V15 SP3 (which does not exist).
2. Check Windows Event Viewer on each failing client: Applications and Services Logs > Siemens Automation > WinCC RT Professional.
3. Inspect the WinCC project folder for the lock file. From the failing client: explorer <ProjectPath>. Look for ProjectOpened.lck.
4. Verify name resolution from each failing client. Open cmd: ping <WinCCServerName>. If ping fails or returns the wrong IP, name resolution is the cause.
5. Verify IP-level reachability: ping <ServerIP> and telnet <ServerIP> 2308.
6. Confirm the Windows user session state on each failing RT host: query query session in cmd. Service-only hosts return no active console session.
7. Capture network trace on server while a client attempts activation: netsh trace start capture=yes ipv4.address=<ClientIP>.

5. Resolution A — Delete the ProjectOpened.lck Lock File

Perform on every failing client. The runtime does not hold the lock if WinCC Explorer is closed.

1. Close the WinCC Runtime on the client.
2. Close the WinCC Explorer if open.
3. Open Windows Explorer and navigate to the WinCC project folder, typically: C:\Program Files\Siemens\Automation\WinCC RT Professional\<ProjectName>\.
4. Locate the file ProjectOpened.lck.
5. Right-click > Delete.
6. Confirm the file is removed.
7. Restart the WinCC RT service: sc stop "S7TraceService" && sc start "S7TraceService", or use the WinCC RT start tray icon.
8. Attempt activation.

6. Resolution B — Activate the Project via Simatic Shell

Simatic Shell is the official remote-activation entry point on WinCC RT Professional. It bypasses the TIA Portal download dialog and is the supported path when the ES is unavailable. Per the official Siemens documentation, the procedure is:

1. On the client, open Windows Explorer.
2. Navigate to Network > Simatic Shell. If the entry is not visible, enable Network Discovery on the client.
3. Expand the Simatic Shell node to list detected WinCC stations.
4. Right-click the target server entry.
5. Select Activate project (remote) / Activate remote.
6. Confirm the project name and click Activate.
7. Monitor the runtime status indicator until it reads Running.

Reference: Activating a project (RT Professional) – TIA Portal V21 docs.

7. Resolution C — Replace Computer Name with IPv4 Address

Perform on the engineering station (ES) and re-download to all clients.

1. Open the WinCC RT Professional project in TIA Portal V15.3 on the ES.
2. Open the device configuration for the RT client.
3. Navigate to Runtime settings > Connection.
4. In the server address field, replace \<ServerName> or <ServerName> with the server's static IPv4 address, for example 192.168.10.20.
5. Compile the project (Project tree > right-click device > Compile > Software [only]).
6. Download to each client (right-click device > Download to device > Software and hardware).
7. Repeat on each failing client.

Cross-subnet deployments should assign the WinCC server a static DHCP reservation or static IPv4 address; do not rely on DHCP lease renewal.

8. Resolution D — Verify ES Connectivity and Re-Download

1. On the ES, confirm the PG/PC interface is set to the correct network adapter and reachable subnet: Start > Control Panel > Set PG/PC Interface.
2. In TIA Portal, open the project tree and confirm Online > Accessible nodes lists the failing clients.
3. Right-click the failing RT device > Download to device > Software and hardware.
4. If the download hangs at the closing-project stage, abort and retry after closing any open HMI editor on the ES.
5. Repeat the download a second time if the first terminates mid-transfer (this is the documented field behavior to recover from a partial state).

9. Resolution E — Switch From Service-Mode to Interactive Login

1. On each failing RT client, open services.msc.
2. Locate the WinCC RT service (e.g., CCAdminSrvc or the project-specific service created at compile time).
3. Stop the service.
4. Change the service Log On tab from a service account to the local interactive user, or configure the RT to start only after the user signs in.
5. Sign out and sign back in on the RT client to establish a fresh interactive session.
6. Restart the RT and attempt activation.

If the RT must run unattended, install the WinCC RT as a console session reservation under a domain user with the Allow log on locally and Log on as a service rights; never leave the service running with no interactive session and no reserved console.

10. Resolution F — Firewall and Routing Configuration

1. On the WinCC server, open Windows Defender Firewall with Advanced Security.
2. Add inbound rules for the WinCC RT ports listed in §3.5, scoped to the client subnet only (do not open to Any).
3. On each router between subnets, confirm ACLs allow the same ports from the client subnet to the server subnet.
4. Disable Windows Firewall briefly as a test, then re-enable and lock down the rule set.
5. Verify with Test-NetConnection -ComputerName <ServerIP> -Port 2308 from each client.

11. Verification Steps

After applying the resolutions, validate the full fleet with the following sequence:

1. Confirm no ProjectOpened.lck files exist on any client project folder.
2. From each client, run ping -t <ServerIP> for 60 seconds to confirm stable reachability.
3. From each client, run Test-NetConnection -ComputerName <ServerIP> -Port 2308; expect TcpTestSucceeded: True.
4. On the server, confirm the WinCC RT is in Running state and the project is Activated.
5. Trigger a remote activation from Simatic Shell on the previously failing client.
6. Monitor Diagnostics > Runtime in WinCC Explorer on each client; confirm zero Project is locked, Server not found, or Project could not be opened events over a 30-minute burn-in.
7. From the ES, force a re-download of the project to all clients and confirm all four activate successfully without a second download attempt.

12. Preventive Configuration

To prevent recurrence during project modifications and fleet growth:

• Standardize all WinCC server and client addressing on IPv4 addresses, not computer names. Reserve the server IPv4 in DHCP.
• Document the lock-file cleanup procedure in the commissioning runbook and execute it after every TIA Portal crash or forced reboot.
• Maintain a single source of truth (SOT) PG for project compiles. Avoid concurrent downloads from multiple engineering stations.
• Configure Windows Firewall rules on the WinCC server with explicit subnet scopes before commissioning.
• Require an interactive user session on each RT client host; do not run RT unattended in pure service mode.
• Establish a fleet-wide reboot and lock-file audit script using Get-ChildItem -Path "C:\Program Files\Siemens\Automation\WinCC RT Professional" -Recurse -Filter "ProjectOpened.lck".
• Subscribe to Siemens ProductCERT and Firmware Update Service advisories for WinCC RT Professional V15.x; some intermittent activation defects are addressed only in cumulative updates.

13. Troubleshooting Matrix

14. Reference Architecture

The reference topology for a four-client WinCC RT Professional deployment across two subnets:

• Server subnet 192.168.10.0/24: WinCC RT server (192.168.10.20), SQL Server (WINCCPLUS), engineering PG (192.168.10.5).
• Client subnet 192.168.20.0/24: RT client A (192.168.20.21), RT client B (192.168.20.22), RT client C (192.168.20.23), RT client D (192.168.20.24).
• Router: L3 device between subnets, ACL permits TCP 80, 443, 2308, 1433, 49152-65535 from 192.168.20.0/24 to 192.168.10.20.
• DNS: Static A-record for wincsrv to 192.168.10.20, but clients use the IP literal to avoid DNS-dependent failures.

15. FAQ