Resolving PCS 7 OS Download s7omwinx OS Already in Use Error

Resolving PCS 7 OS Download s7omwinx "OS Already in Use by Another ES" Error

The PCS 7 Operator Station (OS) download process is a distributed WinCC commissioning operation that opens the target project remotely, writes compiled OS server data, and closes the project cleanly. When the closing handshake fails, the engineering station leaves behind lock files (LCK) that prevent subsequent downloads. This article documents the root cause, the step-by-step remediation, and verification procedures for the s7omwinx "Entire loading is not possible at the moment, because the OS is already in use by another ES" error reported against SIMATIC PCS 7 V6.1 with WinCC V6.0 and SIMATIC Manager V6.1.

1. Problem Description

During a standard OS compile and download cycle, the engineer performs the following sequence in the SIMATIC Manager:

1. Edits the CFC / SFC charts on the AS (Automation Station) project.
2. Compiles the AS and downloads to the AS CPU (e.g., AS 416-3, AS 410).
3. Selects the OS in the component view and chooses OS > Compile OS to generate the WinCC server database.
4. Chooses PLC > Download > Entire OS to push the full image to the OS Master and OS Standby servers.

At step 4, the WinCC OS Project Manager (s7omwinx.exe) aborts the download with the following dialog:

s7omwinx
Entire loading is not possible at the moment, because the OS
is already in use by another ES

The dialog appears even when the engineer confirms that no other engineering station is online, no WinCC Explorer is open on any server, and the only active user is the same ES attempting the download. In redundant server pairs, the same error typically blocks both the Master and Standby download attempts until the orphaned lock state is removed.

2. Root Cause Analysis

When the OS download is initiated, s7omwinx.exe opens the target WinCC project on the OS server through a UNC path (e.g., \\OSMASTER\WinCCProjects\S7Project\OS\). WinCC then creates lock files inside the project directory to reserve the project against concurrent access. Two distinct lock mechanisms are involved:

The locks are written by s7omwinx.exe at the moment the remote project is mounted. The locks are supposed to be deleted automatically when the OS Project Manager closes the project on the remote station. The deletion depends on a clean unmount of the UNC path during normal shutdown of the download dialog.

Three conditions can interrupt that clean unmount, leaving an orphan lock:

1. Network interruption during download. A dropped SMB session, a transient firewall refusal, or a switch port flap on the ES <-> OS network link causes the file handle to be released by the OS kernel before s7omwinx can run its cleanup routine. WinCC then believes another station still holds the project open.
2. Abnormal termination of s7omwinx.exe. Killing the process via Task Manager, an unhandled exception, or a WinCC runtime crash (often logged as APPCRASH in the Windows Application log with faulting module WCCILdata.dll or CCWriteArchives.dll) prevents the cleanup path from executing.
3. Case-mismatched lock files. WinCC and s7omwinx may check the lock using a case-sensitive compare (*.LCK) but write the lock using the casing inherited from the Windows API (*.lck in some installations). The mismatch causes the application to ignore its own lock, while the lock still blocks subsequent opens from any other station.

3. Pre-Remediation Checklist

Before touching any file in the project directory, complete the following prerequisites. Skipping these steps is the single most common reason the error recurs after remediation.

1. Close every PCS 7 application on the ES: SIMATIC Manager, WinCC Explorer, CFC Editor, SFC Editor, SCL Compiler, WinCC Graphics Designer, Alarm Logging, Tag Logging, User Administrator, OS Project Editor, and the WinCC OS Project Manager itself. Verify via Task Manager that no S7OMWINX.EXE, CCExplorer.exe, WCCILdata.dll host process, or CCWriteArchives is running.
2. Close WinCC on the OS Master and Standby servers. Confirm WinCC Explorer is closed and the WinCC runtime service CCWriteArchiveService and CCArchiveConnectService are stopped. If the OS is actively running process control, schedule a maintenance window — the lock cleanup will momentarily close the operator interface on the target server.
3. Verify the OS server is reachable. From the ES, open \\OSMASTER\WinCCProjects in Windows Explorer and confirm the share is accessible. The download cannot succeed if the share is unreachable, and re-running the download against an unreachable share will recreate the lock condition.
4. Verify the SIMATIC Manager project is consistent. Choose File > Save As and re-save the project. A project with unsaved buffer data can cause s7omwinx to re-acquire the lock repeatedly after a failed download attempt.
5. Document current lock file inventory. Open a command prompt and run the inventory command in section 4 before deleting anything. This makes recovery possible if an unexpected file is removed.

4. Primary Remediation: LCK File Cleanup

The authoritative fix is to remove the orphaned lock files from both the ES and the OS target station.

4.1 Inventory the lock files

Open an elevated command prompt on the ES and run:

rem Locate the local ES project copy
cd /d "C:\Program Files\Siemens\Automation\PCS7\S7Project"
dir /s /b *.LCK *.lck > "%USERPROFILE%\Desktop\lck_inventory_es.txt"

rem Locate the remote OS Master project
dir /s /b \\OSMASTER\WinCCProjects\S7Project\*.LCK \\OSMASTER\WinCCProjects\S7Project\*.lck > "%USERPROFILE%\Desktop\lck_inventory_os.txt"

Inspect lck_inventory_es.txt and lck_inventory_os.txt. Expected file types you may find:

• project.LCK — generic project lock.
• <computername>.LCK — host-specific lock indicating which ES last opened the project.
• S7OMWINX.LCK — OS Project Manager lock, written when s7omwinx is active.
• CCWriteArchives.LCK — archive service lock.
• graCS\*.LCK — graphics designer per-picture locks.

4.2 Stop the processes that hold the locks

On each station (ES, OS Master, OS Standby), execute:

taskkill /IM s7omwinx.exe /F
taskkill /IM CCExplorer.exe /F
taskkill /IM WCCILdata.exe /F 2>NUL
taskkill /IM WinCCExplorer.exe /F 2>NUL
net stop "CCWriteArchiveService" 2>NUL
net stop "CCArchiveConnectService" 2>NUL
net stop "SIMATIC WinCC Service" 2>NUL

4.3 Delete the lock files (case-insensitive)

On the ES, clear the local project copy:

del /s /q /a "C:\Program Files\Siemens\Automation\PCS7\S7Project\*.LCK"
del /s /q /a "C:\Program Files\Siemens\Automation\PCS7\S7Project\*.lck"

On the OS Master (or via the ES, with administrative share credentials):

del /s /q /a "\\OSMASTER\WinCCProjects\S7Project\*.LCK"
del /s /q /a "\\OSMASTER\WinCCProjects\S7Project\*.lck"

Repeat for the OS Standby server. The /a flag ensures hidden and system-attributed lock files are removed; WinCC writes some lock variants with the +H (hidden) attribute when the project is opened across a slow link.

4.4 Re-attempt the OS download

Return to SIMATIC Manager on the ES, re-open the project, and repeat the OS compile and download cycle. The s7omwinx dialog should now complete the project open, push the OS image, and exit cleanly.

5. Secondary Remediation: reset_wincc.vbs

If lock removal alone does not clear the condition, Siemens ships a Visual Basic reset script that flushes the WinCC runtime state and clears internal flags. The script is located in the WinCC installation's bin directory on the OS server.

1. On the OS Master, close all PCS 7 applications.
2. Open a command prompt and execute: cscript "C:\Program Files\Siemens\WinCC\bin\reset_wincc.vbs"
3. The script displays status dialogs; press OK through each.
4. Wait for the script to report completion (typically 20 to 60 seconds, longer if MSDE/SQL is busy).
5. Repeat on the OS Standby.
6. Reboot the OS Master and OS Standby servers if the script indicates a restart is required.

The reset_wincc.vbs script performs the following actions in sequence:

• Stops all WinCC services (CCWriteArchiveService, CCEditor, etc.).
• Detaches the WinCC runtime database.
• Clears the CCWriteArchive ring buffer flag.
• Removes selected internal .lock and .LIS files from \<project>\ and \<project>\archive\.
• Re-initializes the database connection parameters.

6. Verification Procedure

After remediation, verify the fix is permanent and that the OS pair is back in a healthy redundant state.

6.1 Pre-download verification

1. From the ES, open \\OSMASTER\WinCCProjects\<project>\ in Windows Explorer. Confirm no *.LCK or *.lck files exist.
2. On the OS Master, open WinCC Explorer > Tools > Status of Server and confirm that the Standby server reports Standby and no station reports Fault.
3. In the Windows Event Viewer of the OS Master, look under Application for the most recent WinCC source entries. Confirm no entries with Event ID 1 from S7OMWINX flagging "OS in use".

6.2 Download execution verification

1. Start the OS compile in SIMATIC Manager: OS > Compile OS. The OS Project Manager should display a successful compile summary without lock dialogs.
2. Start the download: PLC > Download > Entire OS. s7omwinx should report Download complete within 5 to 30 minutes, depending on project size and link bandwidth.
3. On the OS Master, open WinCC Explorer and verify that the OS runtime starts. Check that the operator faceplate shows live process values from the AS.
4. Force a redundancy switchover: on the OS Master, open WinCC Explorer > Tools > Redundancy > Master Standby Switch. Verify that the Standby takes the role of Master within 30 seconds and that the original Master reverts to Standby cleanly.

6.3 Post-download lock inventory

Re-run the inventory command from section 4.1. Immediately after a successful download, s7omwinx should write at most one transient lock file and remove it within seconds. Persistent *.LCK files older than 60 seconds indicate a recurring fault condition.

rem Continuously monitor the OS project for stale locks
:loop
dir /b \\OSMASTER\WinCCProjects\S7Project\*.LCK \\OSMASTER\WinCCProjects\S7Project\*.lck 2>NUL | findstr "."
if errorlevel 1 (
  echo No locks present at %date% %time%
) else (
  echo Lock files detected at %date% %time%
)
timeout /t 5 >NUL
goto loop

Let this run for at least five minutes. If locks appear and do not disappear, escalate to the WinCC service diagnostic in section 8.

7. OS Download Architecture Reference

Understanding the OS download topology helps diagnose related errors that surface with similar wording.

The download flow over the network is:

ES (SIMATIC Manager)
   |
   |  SMB over TCP/445 (\\OSMASTER\WinCCProjects\<project>)
   v
OS Master (s7omwinx.exe, WinCC Explorer)
   |
   |  Terminal Bus / Plant Bus (Industrial Ethernet, ISO-on-TCP)
   v
AS 416-3 / AS 410 (live process values)
   |
   |  Redundancy link (RS-232 or TCP) between OS Master and OS Standby
   v
OS Standby (passive mirror of OS Master runtime database)

Any disruption on the SMB link between the ES and the OS Master is the most common cause of the lock error. The ISO-on-TCP Plant Bus between the OS and the AS is unrelated to the lock error; a Plant Bus failure will surface as a different alarm, typically "Connection to AS broken" in the WinCC diagnostics window.

8. Related Error Messages and Cross-Reference

The s7omwinx dialog surface is shared with several other fault conditions. The following table maps related errors to their likely root cause so the engineer can disambiguate quickly.

9. Preventive Measures and Hardening

To reduce the probability of recurrence, apply the following engineering practices:

9.1 Network hardening

• Configure the switch port connecting the ES to the OS server with portfast and disable BDPU guard if present. STP convergence on a transient failure can drop the SMB session for 30 to 50 seconds, long enough to orphan the lock.
• Reserve a dedicated VLAN for engineering traffic, separate from the operator / control network. This reduces broadcast storms that interrupt long-running file copies.
• Set the ES NIC to a fixed 100 Mbps / full duplex if the link is unstable, or to 1 Gbps if the switch supports flow control. Mismatched auto-negotiation is a common cause of intermittent SMB drops.

9.2 Pre-download procedure

• Always close the OS runtime before initiating a full download. A live runtime will hold CCWriteArchive.LCK indefinitely.
• Always compile the OS immediately before the download; do not assume a previously compiled image is still valid if charts were edited on the AS.
• Document each download with a timestamp and the operator-initiated or engineer-initiated reason. The PCS 7 Audit trail captures the action but not the lock state.

9.3 Lock file monitoring

Schedule a daily Windows task on the OS Master that runs:

rem C:\Scripts\check_lck.bat
set LOG=C:\Logs\lck_audit.txt
date /t >> %LOG%
time /t >> %LOG%
dir /s /b "C:\Program Files\Siemens\WinCC\WinCCProjects\*.LCK" "C:\Program Files\Siemens\WinCC\WinCCProjects\*.lck" >> %LOG%
echo --- >> %LOG%

If any lock file older than 24 hours appears, generate a Windows event log entry (Event ID 9001 from source PCS7Audit) and notify the on-call engineer.

10. Version-Specific Notes

While the original report applies to PCS 7 V6.1, the lock file mechanism is consistent across several releases. The following table summarizes behavior and any release-specific deltas.

11. Escalation Path

If the lock files reappear within minutes of being removed, escalate as follows:

1. Capture a Windows process dump of s7omwinx.exe using procdump -ma s7omwinx.exe c:\dumps\s7om.dmp immediately after the lock is recreated.
2. Collect the Windows Event Viewer application and system logs from the ES, OS Master, and OS Standby covering 24 hours before and after the error.
3. Capture a network trace on the ES NIC during a single download attempt using Wireshark with a filter of smb2 and tcp.port==445. Identify whether the SMB session is being torn down by the switch, the firewall, or the OS.
4. Open a support request with Siemens Industry Online Support referencing the captured artifacts, the PCS 7 version, the WinCC version, and the exact s7omwinx dialog text.

12. FAQ