WinCC Tag Logging CS Write-Protected: Resolving Stale TlgCS.loc Lock Files

Tag Logging in WinCC v6.2 SP2 monitors the read/write status of the Tag Logging CS (Configuration Studio) database. When the editor reports that the archive is "write-protected by another computer," the cause is almost always a stale .loc lock file left behind by a client or engineering workstation that previously opened the project. This reference covers the exact procedure for clearing that lock, the underlying file architecture, the SQL Server interaction, and the related WinCC write-protection scenarios that are frequently confused with it.

1. Problem Description

When you attempt to add, modify, or remove a tag inside the Tag Logging editor of WinCC v6.2 SP2, the following error is displayed:

Common characteristics of the fault:

• The referenced host (for example, XP123) is not present on the network.
• Active Tag Logging runtime continues to function correctly — historical values are still being archived.
• Only the configuration side of Tag Logging CS is locked; operator screens, alarms, and the runtime database are not affected.
• Rebooting the SCADA PC does not clear the condition.
• Stopping the WinCC SQL Server instance does not clear the condition.
• Duplicating the project reproduces the same lock reference.

The referenced hostname is typically a decommissioned PC, a VMware snapshot that has been deleted, a renamed domain account workstation, or a laptop used by an engineer that was subsequently rebuilt or reimaged. The lock survives because WinCC writes a persistent lock file at the moment a project is opened in the Tag Logging Configuration Studio and removes it only on a clean, controlled close.

2. Lock File Architecture in WinCC v6.2 SP2

WinCC v6.2 SP2 uses a distributed lock-file mechanism to prevent two engineering stations from modifying the same Tag Logging configuration at the same time. The relevant files are stored inside the active project directory.

Each .loc file is a small text document. Its body contains the fully qualified Windows hostname of the workstation that acquired the lock and a UTC timestamp of when the lock was issued. The WinCC project manager consults these files on every open transaction. A non-empty, valid hostname match causes the write-protection prompt.

3. Root Cause Analysis

Three root causes account for nearly every reported case of a stale TlgCS lock:

3.1 Decommissioned engineering host

An engineer opened the project on a Windows XP or Windows 7 workstation, made changes, saved the project, and either powered down the machine abruptly (crash, hard reset, or VM power-off) or left the project open while the workstation was rebuilt. The shutdown did not run the CCWriteAndArchiveClose clean-up, so the .loc file was never removed.

3.2 Virtual machine snapshot removal

This is the most common cause in modern deployments. A VMware Workstation, VMware Fusion, Hyper-V, or VirtualBox instance is used as a sandbox engineering environment. The project is opened inside the VM, and the VM is reverted to a clean snapshot or deleted without the engineer closing the Tag Logging CS editor. The host name recorded in the lock file no longer resolves on the network, and the lock cannot be released remotely.

3.3 Re-imaged or renamed PC

A laptop is re-imaged or joined to a new Active Directory OU and receives a new computer name. The project was previously opened on the old computer name. The host record persists in the lock file even though the hostname has been freed up.

4. Pre-Resolution Diagnostic Procedure

Before deleting a .loc file, run the following diagnostics to confirm that the lock is the actual cause and not a downstream SQL or permission issue.

1. Verify network presence of the reported host.
   From the engineering workstation, open a command prompt and run:

   nbtstat -a <ReportedHostName>
   ping <ReportedHostName>
   net view \\\<ReportedHostName>

   If all three commands return "host not found," the lock is stale.
2. Check SMB shares on the engineering PC.
   Determine whether the project is being reached through a residual share:

   net share
   net session

   If a share to the project folder is exposed, anyone with read/write permission on the share can plant a lock. Remove the rogue share with:

   net share <ShareName> /delete

3. Inspect the project directory for .loc files.
   Open the WinCC project root and inspect the per-computer folder:

   dir /s /a "C:\WinCCProjects\<ProjectName>\*.loc"

   Any file older than the most recent known save is a candidate for removal.
4. Confirm runtime is not active.
   Open WinCC Explorer. If runtime is running, deactivate it before any file-system intervention. Active runtime can re-acquire a lock the moment the editor is closed and re-open.
5. Check SQL Server state.
   Open SQL Server Configuration Manager on the SCADA server and confirm the WINCC-MSSQLSERVER service is running. If it is stopped, restart it; an interrupted SQL transaction can occasionally leave a phantom lock in the metadata tables even after a clean file-level unlock.

5. Resolution Procedure: Deleting TlgCS.loc

The definitive fix is to delete the TlgCS.loc file from the affected project directory. The procedure below is the canonical field method.

1. Close WinCC Explorer on the engineering PC.
2. Deactivate WinCC Runtime if it is running.
3. Open Windows Explorer (or WinCC Project Duplicator's project folder) and navigate to:

   <ProjectPath>\<ComputerName>\

   where <ProjectPath> is the project root and <ComputerName> is the engineering station's local computer name.
4. Locate TlgCS.loc. Right-click and inspect the Modified timestamp. If the timestamp predates the last known clean save, the file is stale.
5. Delete TlgCS.loc.

   del "C:\WinCCProjects\<ProjectName>\<ComputerName>\TlgCS.loc"

6. Re-open WinCC Explorer.
7. Open the Tag Logging editor and confirm that the write-protection prompt is gone.
8. Add, modify, or remove a tag. Save the project.

6. Alternative Resolution Methods

If the deletion procedure does not work — typically because another process re-creates the lock on open — apply the alternative methods in this order.

6.1 Project duplication with Project Duplicator

The WinCC Project Duplicator copies the entire project to a new folder and re-binds the local computer name. Any .loc file in the duplicate is rewritten to reflect the new owner. Open the duplicate, perform the configuration change, then copy the edited database tables back into the master project using the Project Migrator or a manual export/import of the affected *.mdf / *.ldf files.

6.2 Service restart cascade

Restart all three WinCC services in this order:

1. WinCC Explorer (close the application).
2. S7DOS service (or CCPublisher on newer revisions) — restart.
3. SQL Server (WINCC-MSSQLSERVER) — restart.

The lock file is independent of SQL Server, but a stuck database connection from a previous editor session can keep the editor in a read-only state even after the file is deleted.

6.3 Stand-alone engineering on an isolated workstation

Disconnect the engineering PC from the network, copy the project to a USB drive, open it locally, and attempt the change. If the lock does not appear in the isolated environment, the original lock is from a network host that is still emitting SMB traffic to the project share even though its name does not resolve from the engineering PC's perspective.

6.4 Direct registry inspection (WinCC v6.2 SP2)

The lock state is mirrored in the registry under:

HKEY_LOCAL_MACHINE\SOFTWARE\Siemens\WinCC\<ProjectName>\TagLogging

A value named LastOwnerHost holds the hostname that last acquired the configuration lock. If the lock file has been deleted but the registry still references the old host, edit the value to the current COMPUTERNAME environment variable and restart the WinCC Explorer process.

7. Verification

Confirm the resolution using the following checks.

1. Tag Logging editor opens without prompt. Open WinCC Explorer → Tag Logging. The status bar must show "Editable" and no hostname reference must be visible in the title bar.
2. Add a new tag. Create a test tag, point it at a real process value, set the archive cycle to 1 second, and save. The save must complete without the write-protection dialog.
3. Verify runtime pickup. Activate Runtime. Use the WinCC Online Trend Control to confirm the new tag is being archived at the configured cycle.
4. Confirm the lock file is re-created cleanly. Close WinCC Explorer normally. Inspect the project directory. A fresh TlgCS.loc must be present with the current COMPUTERNAME and a recent timestamp.
5. Stress test with multiple engineers. Open the same project on a second engineering station. The second station must now receive the write-protection prompt, confirming that the lock mechanism is intact.

8. Related Write-Protection Scenarios in WinCC

The TlgCS lock is one of several distinct write-protection mechanisms in WinCC. Confusing them is a common source of misdiagnosis.

8.1 AS-OS Engineering write-protection

Per the official Siemens support entry "Why can WinCC tags have the status 'write-protected' and thus cannot be edited, deleted or moved?", tags generated by AS-OS Engineering (the STEP 7 / TIA Portal ↔ WinCC symbol import) carry an internal "managed by STEP 7" flag. These tags cannot be edited, deleted, or moved from the WinCC side; the source of truth is the STEP 7 symbol table or the TIA Portal HMI tag table. The remedy is to change the tag in the controller project and re-run the AS-OS transfer, not to manipulate WinCC files.

8.2 Project-wide read-only attribute

If the entire <ProjectPath>\<ProjectName>.mcp file or its containing folder has the Windows read-only attribute set, every editor will report write-protection. Clear the attribute recursively:

attrib -r "C:\WinCCProjects\<ProjectName>\*.*" /s /d

8.3 UNC vs. local path access

Opening the project over a UNC path (\\ServerName\WinCCProjects\<ProjectName>) instead of a mapped drive or local copy causes WinCC to treat the project as remote. Remote projects are always read-write locked when more than one client is connected. Copy the project locally before configuration.

8.4 WinCC user rights

Starting with WinCC 7.0, the User Administrator enforces per-user rights on configuration actions. A standard operator login cannot edit tag logging. Log in as a member of the WinCC Administrators group before attempting any configuration change.

9. WinCC Unified Comparison

In WinCC Unified (TIA Portal V17 and later), the tag logging architecture moves from local .loc files to a centralized database schema. Per the TIA Portal Siemens documentation "Basics of data logging (RT Unified)", data logging in Unified is configured as logging tags with associated logging cycles and is stored in the runtime database. Concurrent write protection in Unified is enforced by database row-level locking rather than by .loc files. The general workflow of "which client currently owns the configuration" still applies, but the recovery procedure is a database transaction rollback rather than a file deletion.

10. Preventive Measures

Once the lock is cleared, prevent recurrence with the following hardening steps.

1. Always close WinCC Explorer cleanly. Train engineering staff to use File → Exit in WinCC Explorer, never to power down the workstation or revert a VM snapshot while WinCC is open.
2. Disable WinCC on VM snapshots. Set VMware Tools or Hyper-V Integration Services to "Always time sync" but never revert to a snapshot that has WinCC Explorer in an open state. Snapshot the project directory only when WinCC is closed.
3. Centralize project storage. Host the master project on a controlled file server. Use the WinCC Project Duplicator to push copies to engineers. This ensures that stale locks from a single engineer's laptop are isolated to a local copy and never reach the master.
4. Schedule a nightly lock scan. Add a scheduled task that runs:

   find "\\fileserver\WinCCProjects" -name "*.loc" -mtime +1 -ls

   and emails the result to the SCADA administrator. Locks older than 24 hours are reviewed manually.
5. Restrict SMB shares to authenticated engineers only. Audit the file server's share permissions quarterly. Remove stale net share entries when engineers leave the project.
6. Document host ownership. Maintain a register of which Windows hostname owns which project copy. When a host is decommissioned, run a project-wide search for any reference to its name in .loc files.

11. Troubleshooting Matrix

12. Field-Proven Caveats

• Do not run multiple WinCC Explorer instances on the same project from the same Windows account. The OS will appear to allow it, but the second instance will silently acquire the .loc and may corrupt the project on save.
• On Windows 10 / 11 workstations used for WinCC v6.2 SP2 engineering, disable Controlled Folder Access in Windows Defender. The OS will silently block WinCC from writing back the .loc file, which can produce a phantom lock after the engineer closes the editor.
• WinCC v6.2 SP2 does not honor symbolic links in the project path. A redirected Documents folder (OneDrive, Offline Files) can break the lock logic. Always store the project on a fixed local NTFS volume.
• If the SCADA PC is part of an Active Directory domain, host name resolution failures from a removed engineer workstation are usually DNS-side. The stale .loc will appear again after a domain replication if the workstation record is not scavenged. Purge the stale A/AAAA records from DNS after decommissioning any engineering host.