Troubleshooting WinCC Flexible OPC DA Server Start Failure

Problem Summary

Siemens WinCC Flexible 2008 (SP3 through SP5) OPC DA Server fails to start reliably when remote OPC DA clients attempt to enumerate or connect to the runtime. The symptom is that the SOPC_HmiRTm.exe launcher either never appears, starts and terminates within seconds, or only stays alive while the remote client holds an active session. Remote OPC DA clients receive 0x80040154 (REGDB_E_CLASSNOTREG, "Class not registered") even though DCOM, group policy, and MSMQ settings appear identical to a working peer machine.

This is a classic WinCC Flexible OPC connectivity failure mode that surfaces most often on Windows 7 installations upgraded from older service packs, and it is rarely caused by a single misconfigured setting. In most field cases the root cause is a combination of: incomplete OPC COM class registration after a service pack upgrade, missing MSMQ triggers, and DCOM launch/activation policies that block the in-proc OPC server from being instantiated by a non-interactive network account.

Affected Versions and Environment

Error Code Reference: 0x80040154

The HRESULT 0x80040154 returned by the remote OPC DA client maps to REGDB_E_CLASSNOTREG. The COM class factory cannot supply the requested OPC server because the COM class identifier is not registered in the registry of the target machine, or the DLL/EXE that hosts it is blocked from starting.

When a remote OPC client logs 0x80040154 specifically while SOPC_HmiRTm.exe terminates within seconds of activation, the failure is almost always in the COM launch path, not in OPC namespace or tag configuration.

Root Cause Analysis

The WinCC Flexible 2008 OPC DA Server is implemented as an out-of-process COM executable (SOPC_HmiRTm.exe) that the WinCC Flexible Runtime starts on demand. When a remote client invokes CoCreateInstanceEx on the OPC server CLSID, DCOM launches SOPC_HmiRTm.exe under the security context assigned in dcomcnfg. Three conditions must all be true for the server to stay alive and serve requests:

1. The COM class (CLSID) is correctly registered under HKEY_CLASSES_ROOT\CLSID and HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID.
2. MSMQ is installed and the OPC listener queues are reachable, because WinCC Flexible uses MSMQ as the transport between the runtime and the OPC stub on certain remote-access code paths.
3. The DCOM launch and access permissions for the OPC server identity, the WinCC Runtime service account, and the connecting user's identity are correctly configured.

When a PC is upgraded from SP3 to SP5 in place, the COM class registration is sometimes rewritten with new binary paths, while leftover MSMQ private queues from the previous installation continue to exist. The OPC client can find the CLSID, but the launched process fails to bind to the stale queue and exits immediately, leaving the client to interpret the absence as REGDB_E_CLASSNOTREG.

SOPC_HmiRTm.exe Process Behavior

SOPC_HmiRTm.exe is the OPC DA wrapper that WinCC Flexible Runtime instantiates when an external client requests an OPC connection. It is registered as a service-style COM local server. Three observable lifecycle patterns are useful diagnostics:

Across all three patterns, the client receives the same 0x80040154, which is why many engineers misdiagnose this as a missing COM registration.

DCOM Configuration (dcomcnfg)

Open dcomcnfg from an elevated command prompt. Configure the following two scopes.

Default COM Security (applies machine-wide)

Navigate to Component Services → Computers → My Computer → right-click → Properties → Default COM Security. Set the four access/launch matrices as follows:

Application-specific Security for WinCC Flexible OPC

Navigate to Component Services → Computers → My Computer → DCOM Config. Locate the application whose AppID matches SOPC_HmiRTm.exe (commonly registered under "WinCC Flexible OPC Server" or "Siemens HMI OPC Server"). Right-click → Properties and configure on the Security tab:

• Launch and Activation Permissions: Use custom; allow Administrators, SYSTEM, INTERACTIVE, NETWORK, and the specific Windows user account that runs the WinCC Flexible Runtime service.
• Access Permissions: Use custom; allow Administrators, SYSTEM, INTERACTIVE, NETWORK, Everyone, and ANONYMOUS LOGON if remote clients authenticate as Anonymous.
• Configure Permissions: Allow Administrators and SYSTEM only.
• Identity: Set to "The launching user" for typical remote-client scenarios, or "This user" with a dedicated service account when the Runtime runs as a service.
• Endpoints: Leave at default (any). If a custom port range has been introduced, document it and open it on Windows Firewall.

MSMQ (Message Queuing) Configuration

MSMQ is the most frequently missed prerequisite on WinCC Flexible OPC installations. The Runtime uses private queues to marshal tag-change notifications to the OPC stub when the OPC client is remote and asynchronous updates are requested.

1. Install MSMQ via Control Panel → Programs and Features → Turn Windows features on or off. Enable Microsoft Message Queue (MSMQ) Server Core and all sub-features, particularly MSMQ Triggers and Multicast Support.
2. Open Computer Management → Services and Applications → Message Queuing → Private Queues. Confirm the WinCC-created queues exist. Typical names include private$\wincc_opc_* and queue names that contain the project GUID.
3. Right-click Private Queues → Properties → Security on each WinCC-owned queue. Grant Full Control to Everyone for testing; tighten to specific service accounts once connectivity is confirmed.
4. If queues exist from a previous WinCC Flexible install (e.g., before the SP3 → SP5 upgrade), delete the orphaned queues before starting the new Runtime. Conflicting queue GUIDs from the prior project version are a known source of 0x80040154 because the new Runtime binds to the old GUID, fails security handshake, and exits.
5. Verify the MSMQ service MSMQ is set to Automatic startup and is currently Running. MSMQ depends on the RPCSS and EventSystem services — these must also be running.

Group Policy Configuration (gpedit.msc)

Open gpedit.msc and navigate to Computer Configuration → Administrative Templates → System → Distributed COM. Audit and configure the following:

Additionally, under Windows Settings → Security Settings → Local Policies → Security Options, confirm:

• Network access: Let Everyone permissions apply to anonymous users = Enabled (only on systems that must support unauthenticated OPC enumeration).
• Network access: Sharing and security model for local accounts = Classic - local users authenticate as themselves.

Windows 7 Upgrade Path Issues

The most diagnostic scenario from field cases is a Windows 7 PC that was upgraded from WinCC Flexible 2008 SP3 to SP5 in place. Three things break specifically during this upgrade:

1. COM class registration mismatch. The installer registers new CLSIDs for SOPC_HmiRTm.exe but legacy InprocServer32 entries from SP3 remain. The OPC client enumerates the first match (old path), which points to a relocated binary, and the launch fails.
2. MSMQ private queue GUIDs are preserved. The new Runtime generates a new project GUID, but the old queues still exist. The new Runtime tries to create the same queue, fails with 0xC00E0025 (MQ_ERROR_QUEUE_EXISTS), and the OPC wrapper exits.
3. DCOM access tokens cached by SCM. After upgrade, the Service Control Manager retains a security descriptor for the OPC server application that references the pre-upgrade service SID. New remote launches fail the SCM access check.

A Windows 10 clean installation does not exhibit these failures because no legacy COM, MSMQ, or SCM state exists to collide with the SP5 install.

UAC and Firewall Considerations

User Account Control and Windows Firewall must be coordinated across both PCs. The recommended baseline for WinCC Flexible OPC remote access is:

The registry value LocalAccountTokenFilterPolicy = 1 removes the UAC remote-restriction filter for members of the local Administrators group. It is a documented Microsoft workaround for DCOM activation from a remote administrator account and is required when UAC is left enabled but the connecting user is a local admin. Remove this value once the system is on a permanent operating posture.

Resolution Procedure

Use the following sequence on the failing PC. Run every step from an elevated command prompt unless noted.

1. Stop the WinCC Flexible Runtime and confirm SOPC_HmiRTm.exe is not running in Task Manager.
2. Open comexp.msc. Navigate to DCOM Config, locate the WinCC OPC server entry, right-click → Properties → Advanced. Verify the AppID matches the binary path of SOPC_HmiRTm.exe. If it does not, unregister the stale entries:
   regsvr32 /u "C:\path\to\SOPC_HmiRTm.exe"
   then re-run the WinCC Flexible Runtime setup in repair mode.
3. Open Computer Management → Message Queuing → Private Queues. Delete all queues starting with wincc_opc_ or containing GUIDs that no longer match the current project.
4. Restart the MSMQ service:
   net stop MSMQ && net start MSMQ
5. Apply the DCOM default security and application-specific security per the tables above.
6. Configure gpedit.msc per the policy table. Force policy refresh:
   gpupdate /force
7. Set LocalAccountTokenFilterPolicy = 1 if the connecting OPC user is a local administrator on the target PC:
   reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
8. Reboot the PC. After reboot, start the WinCC Flexible Runtime and confirm SOPC_HmiRTm.exe is not running (this is normal — it is demand-started).
9. From a second PC with the OPC DA client (e.g., OPC Scout, Matrikon Explorer, or a custom client), attempt a remote connection. The first attempt will trigger SOPC_HmiRTm.exe to start; it must remain running for the entire browsing session.
10. If the process still exits within two seconds, enable DCOM error logging on the target PC by setting:
    HKLM\SOFTWARE\Microsoft\Ole\EnableErrorLogging = 1
    and review the resulting logs in %SystemRoot%\system32\config\OleErrorLogging for the specific COM failure point.

Verification

Verify a successful resolution with the following checks:

1. Process lifecycle: From the remote client, initiate a session and confirm SOPC_HmiRTm.exe appears in Task Manager on the WinCC PC and remains alive for the duration of the session.
2. OPC client log: Confirm no 0x80040154 entries are logged. Allowed HRESULTs are S_OK (0x00000000), S_FALSE (0x00000001), and the standard OPC DA quality codes.
3. Tag read/write: Read a configured tag from the remote client and verify the returned value matches the value shown on the HMI panel. Read-write back a value and confirm the change is reflected on the panel within 1 second.
4. Process disconnect behavior: Close the remote OPC client. SOPC_HmiRTm.exe should terminate within 30 seconds (DCOM idle timeout). Re-open the client; the process must restart cleanly without restart of the WinCC Flexible Runtime.
5. DCOM event log: On the target PC, open Event Viewer → Applications and Services Logs → Microsoft → Windows → DistributedCOM. Confirm no Error events with Event ID 10016 (DCOM launch permission denied) during the session.

OPC UA Migration Recommendation

WinCC Flexible 2008 OPC DA is a legacy interface and is the last Siemens HMI product line with OPC DA as the primary external interface. New deployments, and any retrofit where the controller side can be changed, should evaluate OPC UA. OPC UA removes the dependency on DCOM, MSMQ, and Windows user accounts, and provides explicit endpoint discovery, encryption, and authentication. Reference the Siemens Industry Online Support portal for migration paths from WinCC Flexible 2008 to TIA Portal WinCC Comfort/Advanced, which expose OPC UA natively. When OPC DA must be retained, lock the runtime PC to Windows 10 with a clean installation — Windows 7 SP1 in-place upgrades are no longer recommended for OPC server workloads.