WinCC V8.0 UP4 OpcUaServerWinCC Service Fails to Start with 0x80004005: Root Cause and Field Repair

1. Problem Description

The OpcUaServerWinCC Windows service refuses to start on a freshly installed WinCC V8.0 Update 4 system. The Windows Service Control Manager (SCM) returns the generic COM error 0x80004005 (HRESULT E_FAIL) the first time the service is started, regardless of the launch account (LocalSystem or a configured domain user), the installation mode (standard or custom), or whether the OpcUaServerWinCC plug-in is uninstalled and reinstalled in isolation. The error reproduces on both Windows Server 2019 Standard and Windows Server 2022 Standard editions with Desktop Experience installed.

Downgrading the same image to WinCC V7.5 SP2 on the same hardware and OS produces a healthy OpcUaServerWinCC service. The regression is therefore bounded to the V8.0 UP4 code path of the OPC UA server plug-in, the WinCC Connectivity Pack license handling, or the interaction between the new WinCC V8.0 process model and the legacy SCM service registration. A valid WinCC Connectivity Pack license (the entitlement that unlocks the OPC UA server in WinCC Runtime) is present in every observed failure case, which rules out the simple "missing license" cause but does not rule out license-binding corruption introduced by the installer.

2. Affected Software, Versions, and Operating Systems

The OPC UA server for WinCC is a separate plug-in installed by the WinCC Setup under the WinCC > Options tree. Its service host is registered as a Windows service named OpcUaServerWinCC with the display name OPC UA Server for WinCC and a startup type of Automatic (Delayed Start).

3. Error Code Analysis: 0x80004005

HRESULT 0x80004005 is the generic E_FAIL returned when an underlying COM call returns a non-specific failure. The Windows SCM surfaces it as "Windows could not start the OPC UA Server for WinCC service on Local Computer. Error 0x80004005: Unspecified error". In the context of a Siemens WinCC OPC UA host it commonly maps to one of the following lower-level conditions, all of which should be ruled out in order:

Always read the Application and System event logs in the minute immediately after a failed start; the actual cause appears as an event with source OpcUaServerWinCC, DCOM, or Service Control Manager in the seconds before the SCM rewrites the entry as 0x80004005.

4. Root Cause Analysis

Three independent, well-documented root causes reproduce the failure pattern. The correct repair depends on which one is in play; treat the list as a decision tree, not a single root cause.

4.1 Connectivity Pack License Binding Not Visible to the Service Account

The OPC UA server for WinCC is gated by the WinCC Connectivity Pack license. The license is stored in the Siemens License Server and is read at service start. If the license file is present but the service account cannot read it (commonly because the service is configured to run as LocalSystem on a machine where the License Server is bound to a specific user profile), the service returns 0x80004005 with a license-check event in the log. The user-visible symptom matches the case here: a valid license exists, the service still fails.

4.2 Mixed or Reused OPC UA Plug-in Installation

WinCC V8.0 UP4 install media installs the OPC UA server plug-in, the OPC DA server, and the OPC A&E server as separate components. If a V7.x install was previously present, the COM class registrations, Windows service registrations, and DCOM application entries from V7.x can remain in the registry and are loaded in preference to the V8.0 binaries. The service host can therefore start, load a V7.5 OpcUaServerWinCC.exe referenced by a V7.5 CLSID, and crash because the WinCC V8.0 runtime DLLs it then loads do not match. The error is again 0x80004005. The only reliable repair is a clean removal of all OPC plug-ins (DA, A&E, UA) and the WinCC Connectivity Pack before reinstalling.

4.3 WinCC V8.0 Runtime Not Yet Running When OpcUaServerWinCC Starts

The OpcUaServerWinCC service is registered with Automatic (Delayed Start), but on a V8.0 UP4 image the WinCC Runtime can take longer than the delayed-start window to complete project activation. If the OPC UA service attempts to open the WinCC project database before the runtime has finished activation, the host returns E_FAIL and the SCM records 0x80004005. This is a startup-ordering defect, not a code defect, and is sensitive to disk and SQL performance.

5. Pre-Diagnostic Checklist

Run every check in order before opening a Siemens support ticket. Record the result of each.

1. Open services.msc and confirm the OPC UA Server for WinCC service exists and is registered to %ProgramFiles%\Siemens\Automation\WinCC\opc\OpcUaServerWinCC.exe (or the matching Program Files (x86) path on 32-bit-only installs).
2. Confirm the WinCC Connectivity Pack license is valid: open the Automation License Manager and verify that the entry WinCC Connectivity Pack shows a green check and a non-expired validity date.
3. Confirm the WinCC Runtime is running and that the project on the configured project path activates without error in the WinCC Explorer.
4. Capture the last 5 minutes of the Application event log filtered to sources OpcUaServerWinCC, DCOM, Service Control Manager, and Siemens Automation License Manager.
5. Run netstat -ano | findstr 4840 and confirm no other process is bound to the OPC UA discovery port.
6. Check the WinCC project path is reachable from the service account (the project must not live in a per-user roaming profile).
7. Confirm %ProgramData%\Siemens\OPC\PKI exists and is writable by the service account; this is the OPC UA certificate store and its absence is a known start-failure trigger.
8. Confirm DCOM is enabled: dcomcnfg → Component Services → Computers → My Computer → DCOM Config. The OpcUaServerWinCC DCOM application entry should be present and not flagged with a red X.

6. Diagnostic Procedures

6.1 Service Registration Audit

From an elevated command prompt, dump the service definition and binary path:

sc qc OpcUaServerWinCC
sc queryex OpcUaServerWinCC
wevtutil qe Application /c:5 /rd:true /f:text /q:"*[System[Provider[@Name='OpcUaServerWinCC']]]"

The expected BINARY_PATH_NAME for WinCC V8.0 UP4 is:

"C:\Program Files\Siemens\Automation\WinCC\opc\OpcUaServerWinCC.exe"

If the path points to a Siemens\Automation\WinCC V7.5\opc directory you are looking at the mixed-installation root cause (4.2) and a clean reinstall is required.

6.2 COM Class Registration Audit

Verify the InprocServer32 path of the OPC UA host CLSID:

reg query "HKLM\SOFTWARE\Classes\CLSID" /s /f OpcUaServerWinCC.exe

The resolved path must match the V8.0 UP4 install. Any CLSID resolving to a 7.x path is stale and must be removed before the new service can register cleanly.

6.3 License Audit

Open the Automation License Manager (almsui.exe) on the affected machine and on the license server. Confirm that:

• The WinCC Connectivity Pack license is assigned to this machine's host ID.
• No license is currently checked out to another machine (a stuck checkout blocks the service).
• The License Server service is running (sc query "SLS" on the license server).

6.4 Startup Dependency Audit

Check the WinCC project activation timing:

wevtutil qe Application /c:5 /rd:true /f:text /q:"*[System[Provider[@Name='CCProjectMgr']]]"
wevtutil qe Application /c:5 /rd:true /f:text /q:"*[System[Provider[@Name='OpcUaServerWinCC']]]"

If the OpcUaServerWinCC failure timestamp precedes the WinCC project activation timestamp, the service is starting before the runtime and the startup-ordering root cause (4.3) is in play. Add a manual dependency or extend the delayed-start window.

7. Resolution Methods

7.1 Method A - Full OPC Plug-in Clean Reinstall (most common repair)

This is the field-proven repair for the mixed-installation and license-binding cases and is the procedure recommended by Siemens support for this exact symptom pattern. Run each step in order from an elevated PowerShell or cmd prompt.

1. Stop the WinCC Runtime: net stop "WinCC Runtime" (or stop the project via WinCC Explorer).
2. Stop the OPC UA service: sc stop OpcUaServerWinCC.
3. Open Control Panel → Programs and Features and uninstall, in this order, on the affected machine:
   1. SIMATIC WinCC OPC Server (DA)
   2. SIMATIC WinCC OPC A&E Server
   3. SIMATIC WinCC OPC UA Server
   4. SIMATIC WinCC Connectivity Pack
4. Reboot the machine. Do not skip this step; the COM class database is rebuilt on boot.
5. Verify no residual entries remain:

   reg query "HKLM\SOFTWARE\Classes\CLSID" /s /f OpcUaServerWinCC.exe
   reg query "HKLM\SOFTWARE\Classes\CLSID" /s /f "Siemens OPC"
   

   Both queries must return zero rows.
6. Reinstall the same four components in the reverse order, starting with the Connectivity Pack. Reboot when prompted by Setup.
7. Reapply the WinCC Connectivity Pack license in the Automation License Manager.
8. Start the WinCC Runtime, wait for full project activation (green status in WinCC Explorer), then start the OPC UA service: sc start OpcUaServerWinCC.
9. Verify the service stays up. The first 60 seconds are the critical window.

7.2 Method B - Repair the License Binding Only

If the pre-diagnostic checklist confirms a valid Connectivity Pack license exists but the service log clearly indicates a license failure, repair the binding without a full uninstall.

1. Stop the OPC UA service: sc stop OpcUaServerWinCC.
2. Open the Automation License Manager, locate WinCC Connectivity Pack, and click Repair. If the entry is missing, click Activate and re-enter the license key.
3. Reboot the machine.
4. Start the service. Confirm in the log that the license check no longer appears in the failure path.

7.3 Method C - Force the OPC UA Service to Start After the WinCC Runtime

For the startup-ordering case (4.3), add an explicit dependency so the SCM waits for the runtime to activate the project first.

sc config OpcUaServerWinCC depend= "WinCCRuntimeManager/RTProjectManager"
sc config OpcUaServerWinCC start= delayed-auto

The dependency group name must match the service name of the WinCC Runtime process on the specific V8.0 UP4 build. The above example is the common name on the V8.0 line; confirm the exact name with sc query | findstr /i "WinCC" on the affected machine.

7.4 Method D - Manual OPC UA Server Configuration (RT Professional Model)

If the service starts but the OPC UA endpoint does not expose the expected tags, the project-level configuration is missing. For an RT Professional model (TIA Portal V18 / V19 / V20) the OPC UA server is configured directly in the project. The official procedure, per the TIA Portal help portal, is:

1. Open the WinCC project file in the TIA Portal.
2. Select the HMI device (RT Professional) and open Properties → OPC UA Server.
3. Enable the OPC UA server and configure the server endpoint URL, port (default 4840), and security policies (None, Basic128Rsa15, Basic256, Basic256Sha256).
4. Configure the user authentication mode: Anonymous, Username/Password, or Certificate.
5. Define the certificate: either generate a self-signed certificate automatically or import a CA-signed certificate into the OPC UA certificate store at %ProgramData%\Siemens\OPC\PKI\CA\certs.
6. Compile the project and download to the RT Professional runtime.
7. Restart the OpcUaServerWinCC service to pick up the new configuration.

8. Service Configuration Reference

Key Windows service parameters for the OpcUaServerWinCC service on a healthy V8.0 UP4 install:

9. OPC UA Endpoint Configuration Reference

The OPC UA server in WinCC V8.0 UP4 is configured to expose the WinCC tag database (the internal tag manager) and, if enabled, the WinCC alarm archive. The endpoint URL syntax is:

opc.tcp://<hostname-or-ip>:<port>

Default port is 4840. If the WinCC project runs as a redundant pair, the OPC UA service is installed on both nodes but the active node alone accepts client connections; the standby node holds the service in Stopped state with the reason "Runtime is standby" in the event log.

For the TIA Portal V20 documentation set covering WinCC OPC UA Server (RT Professional) configuration, refer to the official Siemens documentation portal entry Configure WinCC OPC UA Server (RT Professional). The same V8.0 line uses an analogous structure in the WinCC Explorer under OPC UA → Server Configuration.

10. Integration with Third-Party OPC UA Clients

After the OpcUaServerWinCC service is up and the endpoint is reachable, third-party OPC UA clients connect to opc.tcp://<host>:4840. For HMS Anybus and similar gateway products the Siemens OPC UA Client driver in the gateway configuration is the standard integration path. The HMS Networks support article Communicating to a Siemens WINCC SCADA via OPC UA documents the connection-string format, security policy selection, and certificate exchange for the common case where the gateway lives on a separate host from the WinCC server.

11. Verification Procedure

1. Confirm the service is in Running state and has been running for at least 60 seconds: sc query OpcUaServerWinCC.
2. Confirm the TCP endpoint is listening: netstat -ano | findstr 4840 must show a LISTENING entry owned by the OpcUaServerWinCC PID.
3. Browse the endpoint with a UA client (UaExpert, Prosys OPC UA Browser, or a Siemens S7-1500 OPC UA client function block). The first browse must return the Objects folder and the configured tag namespace without an access-denied or certificate-rejected error.
4. Read a known tag, for example an internal WinCC tag HMI_Tag_1, and confirm the value matches the WinCC tag value reported by the WinCC Explorer.
5. Subscribe to a tag and force a value change in the WinCC Runtime. The subscription must receive the change within the configured publishing interval (default 1000 ms).
6. Restart the WinCC Runtime. The OpcUaServerWinCC service must reconnect and re-browse the tag namespace without manual intervention.
7. Inspect the event log for the 10 minutes following each test. No Application Error, DCOM 10010, or OpcUaServerWinCC source errors are acceptable.

12. Troubleshooting Matrix

13. Preventive Configuration for New Deployments

To prevent recurrence on a new WinCC V8.0 UP4 buildout:

1. Image the OS first, install the Automation License Server, then install WinCC. Do not install any V7.x WinCC on the target machine before V8.0.
2. Install the WinCC Connectivity Pack before the OPC UA server plug-in so the license is bound at the time the service first registers.
3. Add the OpcUaServerWinCC service to the WinCC Runtime health-check script and alert if it is not in Running state for more than 90 seconds after a system boot.
4. Open TCP 4840 (and the discovery port if a different value is configured) in the Windows Firewall with Advanced Security inbound rules, scoped to the engineering and plant networks only.
5. Pre-create the OPC UA certificate store at %ProgramData%\Siemens\OPC\PKI with read/write permission for the service account. A missing store at first start is a known 0x80004005 trigger on freshly imaged machines.
6. Configure the OPC UA server endpoint certificate in the TIA Portal project, not after the fact on the runtime, to avoid the self-signed-cert regeneration that breaks existing client trust on first project download.