Troubleshooting WinCC 7.5 OPC UA Server Disconnect on Reboot

Troubleshooting WinCC 7.5 OPC UA Server Disconnect on Reboot

When SIMATIC WinCC 7.5 is configured as an OPC UA client against the MELSOFT MX OPC Server UA from Mitsubishi Electric, the runtime may report the OPC channel in red (Tag Management) immediately after a project restart or WinCC Explorer reactivation. The MELSOFT MX OPC Server UA process is running, the Browse OPC server dialog enumerates the address space correctly, and a manual reconnect from the channel diagnostic does not re-establish the link. The only field-proven recovery in this exact symptom pattern is a full Windows reboot. This reference isolates the root cause, provides deterministic diagnostics, and walks through the corrective steps that bring the channel back to a green state without rebooting the host.

1. Problem Overview

The failure mode is reproducible and behaves as follows:

• WinCC Explorer is left running; the project is activated.
• The operator (or a scheduled event) deactivates and reactivates the project, or WinCC is restarted as a service.
• Within seconds, the OPC UA channel in WinCC Tag Management shows a red connection icon.
• Opening Tag Management → OPC → Browse OPC server enumerates tags successfully; the OPC server process is responsive.
• Clicking Update on the channel does not clear the red state.
• Restarting the MX OPC Server UA, the PLC, or the WinCC Runtime service does not clear the red state.
• A full Windows reboot is the only action that returns the channel to green.

The contradiction between a red channel and a working Browse dialog is the diagnostic fingerprint of the issue: the WinCC channel cache and the OPC Enum path are out of sync with the live server.

2. Affected Versions and Environment

3. Root Cause Analysis

Three root causes dominate this exact symptom pattern. They can co-occur; treat them in the order presented.

3.1 OPC Server Auto-Start Service Order Race

The WinCC 7.5 OPC UA client channel discovers servers through the Windows OpcEnum service, not through OPC UA Discovery. When WinCC Runtime initializes, it requests the Enum result synchronously. If the MELSOFT MX OPC Server UA service is registered with a Manual start type, or if it depends on a network resource (license server, MX Component management service) that has not finished initializing, the Enum returns a NULL server pointer even though MXOpcUaServer.exe is launchable on demand. The WinCC channel marks the connection red, but the Browse dialog still works because it uses CLSID lookup to instantiate the COM object directly, bypassing Enum.

3.2 COM/DCOM Orphaned Process in the Running Object Table

Repeated project re-activations without exiting WinCC Explorer can leave orphaned COM server instances. Each new activation increments the reference count on the OPC server's Running Object Table (ROT) entry, but the previous ROT entry is not released because the WinCC CSPA (Channel State Persistence Agent) fails to call IUnknown::Release() on channel teardown. The MELSOFT MX OPC Server UA, running in-process or local out-of-process, eventually refuses new client subscription requests until the ROT is rebuilt, which only happens at Windows logon or a full restart. UA Expert will reproduce the same refusal when it is the first client opened after a WinCC cycle, which is a useful cross-check.

3.3 Stale Security Token in the WinCC Channel Cache

The WinCC OPC UA channel caches the user identity token obtained at the first successful connect. When WinCC Runtime restarts inside the same Windows session, the cached SecurityToken is reused even though the server has generated a new one after a session timeout. The server returns Bad_SessionClosed or Bad_IdentityTokenRejected, which WinCC displays as a red channel. The Browse dialog bypasses the channel cache and opens a fresh UA session, which is why it succeeds.

4. Diagnostic Procedure

Run these checks before applying any fix. The order is intentional: each step isolates one of the three root causes.

1. Open WinCC Explorer → Tools → Channel Diagnostics. Record the channel state, error code, and last successful poll timestamp. A red state with code 0x80070005 (E_ACCESSDENIED) points to DCOM; 0x80004005 (E_FAIL) points to the CSPA cache.
2. Open Windows Event Viewer → Windows Logs → Application. Filter on Source = OPC, COM, MELSOFT, and OpcEnum. Look for events with Event ID 10010 (DCOM launch failure) and 10016 (DCOM permission).
3. Start the MELSOFT MX OPC Server UA configuration tool. Verify the UA endpoint URL (default opc.tcp://localhost:48050) and the security policy in use.
4. From an elevated Command Prompt, confirm the server process is alive:

   tasklist /fi "imagename eq MXOpcUaServer.exe"

5. Verify the OPC Enum service is running:

   sc query OpcEnum

   Expected state: RUNNING. Start type: Auto.
6. Use a third-party OPC UA test client (for example UA Expert) to confirm the endpoint is reachable independent of WinCC. A successful UA Expert session proves the server is healthy; a failure proves the issue is server-side or network-side.
7. Export the WinCC channel logs from C:\ProgramData\Siemens\Automation\WinCC\Diagnostics and review the most recent OPCUAChannel.log for token reuse messages.
8. Capture a network trace with Wireshark on the loopback interface, filter on opc.tcp, and verify that a CreateSessionRequest is sent within 5 seconds of project activation. The absence of the request confirms the CSPA cache orphan.

5. Step-by-Step Solution

5.1 Convert the MX OPC Server UA to an Auto-Start Service

Open an elevated Command Prompt and execute:

sc config "MELSOFT MX OPC Server UA" start= auto
sc start "MELSOFT MX OPC Server UA"

Add a service dependency on the WinCC service to enforce start order:

sc config "MELSOFT MX OPC Server UA" depend= "WinCC/OpcEnum"

Reboot Windows. Confirm the service state is RUNNING before launching WinCC Explorer.

5.2 Re-Register the OPC Server in the Windows Registry

Re-run the MELSOFT MX OPC Server UA installer with the Register OPC Server option, or manually merge the following registry fragment with the actual CLSID from the OPC server About dialog:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\CLSID\{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}]
@="MELSOFT MX OPC Server UA"

[HKEY_CLASSES_ROOT\CLSID\{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}\LocalServer32]
@="C:\\Program Files\\Mitsubishi\\MXComponent\\MXOpcUaServer.exe"

[HKEY_CLASSES_ROOT\CLSID\{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}\ProgID]
@="MELSOFT.MXOPCServerUA.1"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\MELSOFT.MXOPCServerUA.1]
@="MELSOFT MX OPC Server UA"

After merging, restart the OpcEnum service:

net stop OpcEnum && net start OpcEnum

5.3 Configure the WinCC Channel Reconnect Parameters

Edit the WinCC OPC UA channel configuration (typically OPCUA.ini in the project \<ProjectName>\Library folder) and set the following values. The defaults are conservative; the values below balance recovery time and server load.

5.4 Apply Windows DCOM Permissions

Open dcomcnfg.exe and navigate to Component Services → Computers → My Computer → DCOM Config. Right-click the MELSOFT MX OPC Server UA entry and configure the following tabs:

• Identity: select This user and enter the WinCC runtime service account (typically .\Siemens or the logged-on operator account).
• Security: under Launch and Activation Permissions, add the WinCC service account with Allow on Local Launch, Remote Launch, Local Activation, Remote Activation.
• Endpoints: confirm the OPC UA TCP port 48050 is in the static exceptions list. If the Windows Firewall is active, add an inbound rule:

netsh advfirewall firewall add rule name="MX OPC UA 48050" dir=in action=allow protocol=TCP localport=48050

5.5 Clear the WinCC Channel State Cache

Stop the WinCC Runtime services:

net stop "CCAgent"
net stop "WinCC"

Delete the CSPA cache files:

del /q "C:\Program Files\Siemens\Automation\WinCC\bin\CSPA*.dat"
del /q "%ProgramData%\Siemens\Automation\WinCC\ChannelState\*.csc"

Restart the runtime. The first activation will rebuild the cache and issue a fresh CreateSessionRequest, clearing the stale token issue.

6. Verification

After applying the corrective steps, perform the following validation sequence:

1. Reboot Windows. Verify the MELSOFT MX OPC Server UA service starts automatically and reaches the RUNNING state before the WinCC services.
2. Launch WinCC Explorer and activate the project. Confirm the OPC UA channel in Tag Management transitions to green within 30 seconds.
3. Open Channel Diagnostics and confirm no error code is reported.
4. Stop and restart the project five times in succession. The connection should remain green throughout, with no orphaned ROT entries observable in Process Explorer → System Information → ROT.
5. Run a 24-hour soak test. Monitor OPCUAChannel.log for any Bad_SessionClosed or Bad_IdentityTokenRejected messages. A clean run confirms the fix.

7. Connection Lifecycle Diagram

8. Related Configuration Notes

For environments planning a migration from WinCC 7.5 to TIA Portal / WinCC Unified, the OPC UA client architecture is fundamentally different. The WinCC Unified OPC UA client is configured directly in TIA Portal as an HMI device connection, supporting both alarm and tag subscription models without a separate OPC server process. The native MELSOFT MX OPC Server UA integration path is not required when using WinCC Unified, because the Mitsubishi MC protocol can be loaded directly via the Mitsubishi driver in TIA Portal. For users of SIMATIC WinCC classic on third-party OPC servers, the OPC UA Extension for SIMATIC WinCC from Unified Automation provides a drop-in channel that bypasses the legacy COM Enum entirely and is worth evaluating for new deployments.

For teams using the modern TIA Portal toolchain, the Using the WinCC Unified OPC UA client (RT Unified) documentation describes the equivalent configuration on the Unified platform. WinCC V7.5 does not use that configuration model; treat the two as separate architectures when porting example projects.

9. Alternative Approaches

If the OPC UA route continues to fail after the corrective steps above, evaluate the following alternatives. They are listed in order of operational impact.

9.1 Direct MX Component to WinCC Tags

If a license is available, the WinCC Mitsubishi MX Channel provides direct MX Component access without an OPC server in the loop. This removes the entire OPC Enum / CSPA failure surface and is the most robust long-term fix for classic WinCC installations.

9.2 Modbus TCP Gateway

Most Mitsubishi MELSEC controllers expose a Modbus TCP gateway either natively (iQ-R, iQ-F) or via the MX Component Modbus Server add-on. Configuring a Modbus TCP channel in WinCC is a well-documented path and avoids the OPC UA stack entirely.

9.3 Fallback to OPC DA

The symptom does not reproduce on the legacy MELSOFT MX OPC Server DA. If OPC UA is not a hard requirement, OPC DA is a pragmatic fallback for the duration of the upgrade project.

10. Field-Proven Caveats

• The MELSOFT MX OPC Server UA does not support a watchdog keep-alive. The WinCC channel will not detect a server crash within the session timeout window. Plan for an external watchdog (for example, a scheduled task that pings the endpoint with a ReadRequest) if server availability is safety-relevant.
• The red channel state in WinCC Tag Management is purely cosmetic for OPC UA subscriptions. Runtime tag values continue to update from the cached subscription for the duration of the session timeout. Loss of the red state alone is not a process control risk.
• Always test with the OPC UA Discovery URL (opc.tcp://localhost:48050) before assuming a server-side fault. A failure to resolve the URL is a Windows Firewall issue, not a WinCC issue.
• The MELSOFT MX OPC Server UA service name varies by installation language. The English installer registers it as MELSOFT MX OPC Server UA; the Japanese installer registers it as MELSOFT MX OPC Server. Verify with sc query state= all before scripting service control.
• Do not disable the OpcEnum service. WinCC 7.5 OPC DA channels still depend on it. The CSPA orphan can be cleared by restarting OpcEnum alone, without a full Windows reboot, after the CSPA cache is deleted.

11. Quick Reference: Fault Code Matrix