WinCC Error 310:3 Troubleshooting: Objects Cannot Be Edited

Problem Description

WinCC Runtime error 310:3 is reported as "WinCC objects cannot be edited" (German: "WinCC-Objekte können nicht bearbeitet werden"). It appears spontaneously in operating stations running WinCC V7.x SP3 that were previously upgraded from SP1 or SP2. The error is not project-specific — it survives a complete WinCC project restore and is reproduced on a single-station configuration with no changes made by the operator to user accounts, project files, or hardware configuration. The symptom typically appears days after installation, often after a reboot, and frequently correlates with:

• A second error from the Station Configuration Editor reading "Proxy saying: Not all applications have logged off from the proxy with index 2" (event ID 10124 / message class "Proxy").
• Windows event log entries under Source: Userenv, Event ID 1517: "Windows saved user <domain>\<user> registry while an application or service was still using the registry during log off. The memory used by the user's registry has not been freed…"
• A WinCC user that has been moved to the local group SQLServer2005MSSQLUser$<COMPUTERNAME> following the SP3 installation, rather than remaining a member of Simatic HMI or RC_Maintenance.

Error Code Reference

For the canonical WinCC API error structure (DM_E_SYS_ERROR = 0x10000000 and subsequent flags) refer to the official Siemens documentation: Error messages (RT Professional) — WinCC. Although the page is indexed under "RT Professional," the same DMS error taxonomy is inherited from the WinCC V7 base, and the hex return values apply to the legacy V7 SP3 runtime as well.

Station Configurator Index Mapping

The Station Configuration Editor (CCAgent.ini / CCAlgCfg.exe) is responsible for binding WinCC applications to the correct network interface. Each logical index corresponds to a hardware or software component:

The 310:3 fault is therefore functionally tied to Index 2: the WinCC service's own DCOM/COM proxy. When the proxy handle is not released cleanly during the last logoff (most often because an underlying service such as CCArchiveConnect, CCMsgGrp, CCAlgChnLgr, or the SQL writer held the registry hive), the next start of the WinCC Runtime refuses the editing request and returns 310:3.

Root Cause Analysis

Three independent root causes have been confirmed on WinCC V7.0 SP3 / V7.1 SP3 / V7.2 SP3 stations. Field evidence indicates they frequently co-occur.

Cause A — SP3 Security Group Renaming

When Siemens rolled up SP3, the SQL Server 2005 host instance that backs WinCC was reconfigured. The legacy local group Simatic HMI still exists but is no longer the principal host account. SP3 creates a per-instance group named SQLServer2005MSSQLUser$<COMPUTERNAME> and adds the WinCC operators there. If the engineer who installed SP3 left the WinCC logon user only in RC_Maintenance and removed it from SQLServer2005MSSQLUser$…, the next database open fails the access-check, leaves the COM handle open, and surfaces 310:3 on the next runtime start. See the SP3 readme file shipped with the WinCC DVD under Readme\Readme_SP3.htm, section "Notes on user accounts and groups".

Cause B — Wrong Network Card Bound to Index 2

On stations with two NICs (plant bus on Intel/PCIe, terminal bus on the integrated / Wi-Fi adapter), Index 2 in HW Config / Station Configurator can be inadvertently assigned to the wrong adapter. When the Wi-Fi link is down at boot — or when no DHCP lease is granted because the terminal bus SSID is out of range — the WinCC service starts, the index-2 proxy cannot bind to a routable address, and the proxy logoff handshake never completes. Windows therefore still holds the per-user registry hive for that user (Userenv 1517). The next runtime open reads the stale hive and emits 310:3.

Cause C — Stale Per-User Registry Hive (Userenv 1517)

Windows event id 1517 is logged when a service running as an interactive user is still attached to HKEY_USERS\<SID> at logoff. With WinCC V7, the runtime loads registry preferences from the user hive during activation. If the hive is not freed, the next LoadUserProfile returns ERROR_PRIVILEGE_NOT_HELD (0x545) and the runtime cannot complete object initialization. The visible error is again 310:3.

Network Topology Considerations

For the index-2 binding to be correct, the Station Configurator entry must point at the NIC that owns the WinCC server's own IP. A typical PCS 7 single-station has:

• Plant bus: 10.x.x.x / 16 — IEC 61784 (PROFINET), SIMATIC S7 communication (ISO-on-TCP port 102), bound to the field-level Intel NIC. Index 1 = IE General.
• Terminal bus: 192.168.x.x / 24 — TCP/IP between OS server and OS clients, bound to the integrated / secondary NIC. Index 2 = WinCC Application.

Open the Station Configurator and confirm:

1. The MAC address of the entry "WinCC Application" matches the MAC address printed on the integrated NIC, not the Wi-Fi card.
2. The TCP/IP settings for that NIC are static (not DHCP). DHCP-induced address churn is a primary trigger of the proxy-not-logged-off condition.
3. The Windows service CCAlgChnLgr has "Log On As" = Local System (not a domain user). If "Log On As" was changed to a domain account during the SP3 setup, restore it.

SQL Server User Account Configuration in SP3

Use the following procedure to verify and restore the correct group memberships on the WinCC user. Run from an elevated cmd.exe:

1. lusrmgr.msc → Groups → confirm the existence of SQLServer2005MSSQLUser$<COMPUTERNAME>. If absent, the SP3 installation of SQL Server Express 2005 was not completed; reinstall from SQL Server 2005 Express SP3\SQLEXPR2005_SP3.exe.
2. Open computer management → Local Users and Groups → Users → select the WinCC operator account. On the Member Of tab, the following groups must be present:

Add the missing group with:

If the account is local rather than domain:

Userenv Registry Event Analysis

To resolve the stale-hive issue, switch all WinCC services from per-user identities to LocalSystem or NetworkService:

1. Run services.msc as Administrator.
2. Stop and reconfigure each of the following services, setting Log On to Local System account with "Allow service to interact with desktop" ticked:

Reboot and verify that Userenv 1517 is no longer logged under Windows Logs → Application. The corresponding SYSTEM\CurrentControlSet\Control\hivelist entry should be cleaned automatically; if not, run reg unload HKU\<orphaned-SID> from an elevated prompt.

Step-by-Step Diagnostic Procedure

1. Capture the event log. Save eventvwr.msc → Windows Logs → Application and System as .evtx before rebooting.
2. Check Station Configurator. Confirm the Index 2 binding, and which NIC owns the index-2 IP.
3. Verify IP connectivity. From cmd.exe run ipconfig /all and ping <own-IP>. If the index-2 NIC shows "Media disconnected," fix the cabling or disable the Wi-Fi power-saving policy.
4. Inspect SQL login. From SSMS (or SQLCMD -S .\WinCC -E) run SELECT name FROM sys.syslogins WHERE name LIKE '%<USER>%';. If the user is missing, re-add via WinCC User Administrator.
5. Inspect DCOM permissions. Run dcomcnfg → Component Services → Computers → My Computer → DCOM Config. Locate SIMATIC WinCC Archive Provider, SIMATIC WinCC Tag Provider, SIMATIC WinCC Alarm Provider, and verify that the WinCC user has both Local and Remote access.
6. Trigger proxy cleanup. Stop all CC* services, then iisreset /stop && net stop winmgmt /y && net start winmgmt. Restart the station.
7. Open the project with WinCC Explorer. If the 310:3 disappears, the issue was transient; if it persists, continue.
8. Reset the registry hive. Delete the user's profile under C:\Users\<user> and let Windows rebuild it. Do NOT delete C:\Program Files (x86)\Siemens.

Resolution Procedures

The complete fix on a station that matches all three root causes consists of the following actions, executed in the order listed.

Fix 1 — Correct the Network Card Binding

1. Open Station Configuration Editor from the WinCC program group.
2. Click Properties on Index 2.
3. In the Network Connection dropdown, select the wired terminal-bus NIC, not the Wi-Fi adapter.
4. Click OK and close the editor. Do not modify Index 1.

Fix 2 — Restore the SP3 User Groups

1. Add the operator user to SQLServer2005MSSQLUser$<COMPUTERNAME> and Simatic HMI.
2. Open WinCC User Administrator and confirm the operator's password is valid and not expired.
3. Open Computer Management → Services and restart SQL Server (WINCC), then CCArchiveConnect.

Fix 3 — Eliminate Userenv 1517

1. Reconfigure the WinCC Runtime service to log on as Local System.
2. Reboot. Confirm in Event Viewer that no Userenv 1517 entry is logged for the WinCC user.
3. Re-open the WinCC project. 310:3 should not recur.

Fix 4 — Nuclear Option (only if 310:3 still persists)

1. Back up C:\Program Files (x86)\Siemens\WinCC\<project>.
2. Uninstall WinCC V7 SP3 via Control Panel → Programs and Features. Keep the project directory intact.
3. Reboot. Manually delete C:\Program Files (x86)\Siemens and C:\ProgramData\Siemens.
4. Reinstall WinCC V7 from the original DVD, then apply SP1, then SP3 — in that order.
5. Restore the project backup.

Verification

After each fix, validate in the following order. Record results in the project logbook.

1. 310:3 silent check. Open WinCC Explorer → Tools → Output Window. No 310:3 should appear in Alarm Logging or Tag Logging.
2. Object edit check. Open a graphics designer picture, double-click a smart object, modify a property, save. The lock indicator (red dot) on the project tree should be absent.
3. Proxy check. Open Station Configuration Editor → Diagnostics. Index 2 should report "Active — no errors". The proxy logoff message must be gone.
4. Userenv check. Event Viewer → Application → Userenv. No 1517 entries since the last boot.
5. SQL connectivity check. From cmd.exe run osql -E -S .\WinCC -Q "SELECT @@VERSION". Expected output: Microsoft SQL Server 2005 - 9.00.5000.00 (SP3)…
6. Runtime check. Activate WinCC Runtime. After 90 s, the license manager should display a green check on all licensed components.

Preventive Maintenance

• Lock the SP3 build to a fixed level in the customer DVD image; do not allow Windows Update to push a SQL 2005 post-SP3 hotfix unless Siemens documents it.
• Disable Windows automatic updates on operator stations; install only Siemens-tested hotfix bundles.
• Schedule monthly checks of net localgroup membership to detect accidental removal from SQLServer2005MSSQLUser$<COMPUTERNAME>.
• Apply UPS-backed power to operator stations; index-2 NIC link loss during a brownout is the most common trigger of the proxy-not-logged-off fault.
• Where the terminal bus is Wi-Fi, replace with wired Ethernet; WinCC V7 was designed for wired operation only.

Troubleshooting Matrix

Related Diagnostics and Edge Cases

On a redundant WinCC server pair, 310:3 may appear on the standby server only. The fault then migrates to the master during the next failover. Treat it as a cluster-wide fix.

If the station uses WebNavigator or WinCC/Audit, the index-2 binding is shared with the IIS application pool. After applying Fix 1, restart W3SVC as well.

If WinCC/WebUX is installed, confirm that the WinCC Unified collaboration port (443 + 8080) is also bound to the same NIC as index 2. Otherwise the IIS proxy for WebUX will hold a parallel stale handle.

For SQL Server 2005, Microsoft mainstream support ended on 12 April 2011 and extended support ended on 12 April 2016. SP3 + the latest cumulative update (SQL Server 2005 SP4 cumulative update 4) is therefore the maximum service level available, and any investigation that requires Microsoft support must respect that boundary. Plan a migration to WinCC V7.5 / V8 on a supported OS before SP3 OS support runs out.