Fixing WinCC OPC Browser Interface Errors and Stale Tag Reads

Overview

Siemens WinCC V6.0 SP3 bundles an integrated OPC DA 2.0/3.0 server (OPCServer.WinCC, CLSID {28E68F94-9D14-11D0-A984-00C04FD705B2}) and a local OPC DA client that allow process tags, alarms, and archive values to be exchanged with third-party SCADA, MES, and historian packages. When OPC connectivity breaks, plant visibility, supervisory control, and historian logging all degrade simultaneously, which makes a deterministic resolution path mandatory.

This reference documents two distinct WinCC 6.0 SP3 failure modes observed on the original validated operating systems (Windows 2000 Professional SP4 and Windows XP Professional SP2):

• Problem 1 — The OPC client dialog reports "This OPC Server does not support a Browser Interface!" when a connection is established.
• Problem 2 — Tag writes from the client succeed (S_OK), but tag reads continually return the configured tag start value and never refresh.

Both symptoms are registry, DCOM, or OPC runtime contamination issues rather than product defects, and both resolve after a controlled rebuild that installs only Siemens software on the affected workstation.

Problem 1 — "OPC Server Does Not Support a Browser Interface"

When a third-party OPC DA client (Excel add-in, generic OPC browser, another SCADA runtime, or the WinCC OPC test client against a foreign server) calls IOPCBrowseServerAddressSpace::Browse() against a WinCC 6.0 SP3 OPC server, the browse dialog returns "This OPC Server does not support a Browser Interface!". Synchronous read/write calls in the same session often succeed, isolating the failure to the discovery path of the OPC DA stack.

Observed Environment

Root Cause

The WinCC 6.0 SP3 OPC server implements the optional IOPCBrowseServerAddressSpace interface (IID {0002E012-0000-0000-C000-000000000046}) together with the optional IOPCServerList2 discovery interface. Both interfaces are exposed through a proxy generated by the Windows OpcEnum service (CLSID {63D5B7C0-91C4-11D1-9B81-00C04FB95101}) using the registration entries under HKEY_CLASSES_ROOT\CLSID and the OPC categories under HKEY_LOCAL_MACHINE\SOFTWARE\OPC Foundation.

If the OPC server proxy DLL fails to load, or if OpcEnum cannot enumerate the WinCC server because its category registration is missing or pointing to an obsolete proxy, the browse path receives an empty or invalid interface pointer and the OPC client falls back to the "not supported" string. This message is therefore almost always a registration or DCOM integrity defect, not a missing feature in the OPC server itself.

Recurring contributors during field escalations include:

• Partially installed or repaired Siemens toolchain — for example STEP 7 V5.4, S7-PCT, or a SIMATIC NET update applied on top of an existing WinCC install without the matching registry merge.
• OPC core components overwritten by a non-Siemens OPC stack or a partial uninstall that removed OpcEnum but left WinCC OPC entries intact.
• DCOM access permissions tightened by Windows XP SP2 hardening, which shipped with RPC/COM Security in a default-restricted state.
• Anti-virus, backup, or system-tuner software quarantining or replacing the binary files OPCEnum.exe and opccomn_ps.dll.

The OPC Foundation's OPC Classic overview documents the Browser interface as an optional IOPCBrowseServerAddressSpace contract per the OPC DA 2.0/3.0 specification.

Problem 2 — Writes Succeed, Reads Always Return Start Value

The second failure mode is more subtle: the OPC client opens the WinCC server without error, the synchronous and asynchronous writes return S_OK, but every read returns the configured tag start value and the value never updates. The behavior reproduces regardless of the polling rate configured in the client.

Observed Environment

Root Cause

A read that returns the start value indefinitely while writes succeed indicates that the WinCC OPC server accepted the connection, registered the group and items, and processed the IOPCSyncIO::Write and IOPCAsyncIO2::Write calls — but its data-acquisition callbacks into the WinCC tag manager are not arriving at all.

In WinCC 6.0 SP3 this pattern is the hallmark of a partial runtime install. One or more supporting components is missing, blocked, or running under a different Windows account than the rest of the runtime:

• CCDataMgr.exe — the WinCC data manager that owns tag acquisition.
• OPCServer.exe — the OPC DA 2.0/3.0 out-of-process server.
• opcproxy.dll — the custom-interface proxy.
• CCProjectMgr.exe — the project manager that brokers tag lookups.

Because the OPC connection setup and group create succeed, the WinCC OPC server does not raise a connection error in the diagnostic trace. The user's first symptom is therefore always my tags do not refresh, with writes appearing to work by coincidence.

Common Diagnostic Steps (Before Rebuild)

Run the following checks to confirm the failure mode is registration/DCOM, not a network or tag-mapping issue, before any rebuild is scheduled.

1. Verify OPC Server Registration

Open regedit on the OPC server node and confirm the WinCC server entries exist under both HKEY_CLASSES_ROOT\CLSID and HKEY_LOCAL_MACHINE\SOFTWARE\OPC Foundation. The minimum required entries are:

[HKEY_CLASSES_ROOT\CLSID\{28E68F94-9D14-11D0-A984-00C04FD705B2}]
@="OPC.WinCCServer.1"

[HKEY_CLASSES_ROOT\CLSID\{28E68F94-9D14-11D0-A984-00C04FD705B2}\InProcServer32]
@="C:\\Program Files\\Siemens\\WinCC\\bin\\opcproxy.dll"
"ThreadingModel"="Both"

[HKEY_CLASSES_ROOT\CLSID\{28E68F94-9D14-11D0-A984-00C04FD705B2}\ProgID]
@="OPC.WinCCServer.1"

[HKEY_LOCAL_MACHINE\SOFTWARE\OPC Foundation\ServerCategories\HKEY_LOCAL_MACHINE]
@="{28E68F94-9D14-11D0-A984-00C04FD705B2}"

[HKEY_LOCAL_MACHINE\SOFTWARE\OPC Foundation\Aliases\OPC.WinCCServer.1]
@="OPC.WinCCServer.1"

If the InProcServer32 path is wrong, or the ProgID entry is missing, the browser discovery path returns a stub interface and clients emit the "not supported" string.

2. Verify the OpcEnum Service

The OpcEnum service enumerates registered OPC servers on the node. Confirm it is running and that its binary matches the OPC Foundation version that shipped with WinCC 6.0 SP3 (version 2.0 of the OPC Core Components):

C:> sc query OpcEnum

SERVICE_NAME: OpcEnum
TYPE               : 10  WIN32_OWN_PROCESS
STATE              : 4  RUNNING
WIN32_EXIT_CODE    : 0  (0x0)
CHECKPOINT         : 0x0
WAIT_HINT          : 0x0

If the service is absent or stopped, restart it and re-test the browser path. A permanently missing OpcEnum is the leading indicator that a third-party OPC stack replaced the original Windows components.

3. Inspect DCOMCNFG Permissions

Windows XP SP2 ships with the Windows Firewall enabled and tightened COM Security. On both client and server machines, configure:

• COM Security > Access Permissions > Edit Limits: allow Everyone, or at minimum the interactive user running WinCC Explorer, plus Anonymous Logon and the Network SID.
• COM Security > Launch and Activation Permissions > Edit Limits: allow Everyone or Interactive User for local and remote activation.
• My Computer > Properties > Default Properties: enable Enable Distributed COM on this computer and set default impersonation to Identify.
• My Computer > Properties > Default Protocols: confirm the Connection-oriented TCP/IP sequence is listed.

DCOM errors do not always surface as explicit HRESULTs to the OPC client. Tightened launch permissions can manifest as the silent read failure pattern of Problem 2. The Microsoft Learn DCOM documentation describes the canonical access and launch permissions.

4. Capture the WinCC OPC Trace

WinCC 6.0 SP3 records an OPC-specific trace under C:\Program Files\Siemens\WinCC\diagnose. Activate the trace from WinCC Explorer > Tools > OPC Trace or directly:

Run a failing read/write sequence for two minutes, stop the trace, and review OPC_Trace_*.log. Capture any of the following HRESULTs:

Resolution Procedure — Clean Re-Install of Siemens Software Only

The combination of both failure modes, plus an OPC trace that shows the server reaching the data manager but receiving no callback, points to a contaminated install. The definitive resolution is a controlled rebuild that puts only Siemens software on the workstation. Mixed installs of STEP 7, SIMATIC NET, S7-PCT, third-party OPC packs, and Office 365 along with heavy OS patching consistently reproduce the symptoms above.

Prerequisites

• WinCC 6.0 SP3 installation media (DVD or ISO), including the OPC Server WinCC option pack.
• License key — USB hardware dongle or software license file — and the matching WinCC project backup.
• List of PLC connection drivers used by the project: S7 TCP/IP, S7 MPI/IE, Allen-Bradley DF1, OPC, and any user DLLs.
• Documented COM/DCOM, firewall, and DCOMCNFG settings.
• Change-control approval to format the system partition if a clean rebuild becomes necessary.
• A spare workstation or virtual machine for staged re-validation before reconnecting to plant.

Step-by-Step Rebuild

1. Capture the current WinCC project and archive it using the Project Duplicator or a manual copy of the project directory. Tag and script exports are stored on a different physical drive or external media.
2. Export the registry hive HKEY_LOCAL_MACHINE\SOFTWARE\OPC Foundation and the CLSID key {28E68F94-9D14-11D0-A984-00C04FD705B2}. Save as a baseline for future restore operations.
3. Document the COM Security, default protocol, and firewall settings from DCOMCNFG.
4. Detach the hardware license dongle (if used) and store it in a known location.
5. Format the system partition (or the entire disk) and reinstall the original operating system: Windows XP Professional SP2 for the OPC server node and Windows XP Professional SP2 for the OPC client node. Apply only the OS service pack and the WinCC prerequisites before any other software is installed.
6. Install WinCC V6.0 SP3 with the OPC Server WinCC option selected. Do not install any third-party OPC stack on the same machine. Confirm the presence and registration of OPCServer.exe, opcproxy.dll, and the OpcEnum service.
7. Restore the project archive and attach the dongle. Start the WinCC runtime once in service mode and verify the local OPC connection to OPCServer.WinCC through the test client under Start > Programs > Siemens Automation > WinCC > Tools > OPC Test Client.
8. If the workstation must host both WinCC and a vendor SCADA client, run them in separate VM sessions or separate Windows user profiles rather than layering them in the same session.
9. Apply all subsequent Windows updates, virus definition updates, and driver updates only after the OPC functionality has been verified. Re-run the OPC browser test after each restart.

Verification

After the rebuild, run the following verifications in order. Each step must pass before the machine is returned to production.

Verification 1 — OPC Browser Test

Start the WinCC OPC test client and connect to OPCServer.WinCC on localhost. Open the Browse dialog and confirm that the project tag tree is enumerated. The "does not support a Browser Interface" message must not appear.

Verification 2 — Round-Trip Read/Write

Select any internal WinCC tag (for example a binary memory bit). Force a write from the OPC test client and confirm the value appears in the WinCC tag browser. Then read the same tag from the OPC client and confirm the value refreshes within the configured update interval (typically 250 ms or 1 s). Stale reads that return the start value indefinitely are not acceptable.

Verification 3 — Cross-Machine OPC

From the OPC client node, repeat verification 1 and 2 against the server node using its NetBIOS name or IP address. Confirm the DCOMCNFG permissions on the server allow both browse and read traffic.

Verification 4 — Trace Verification

Capture a 60-second OPC trace during the cross-machine test. Confirm no 0x80004005, 0x80040200, or 0x80040206 HRESULTs are present in the trace. The trace should show regular IOPCServer::AddGroup, IOPCItemMgt::AddItems, IOPCSyncIO::Read, and IOPCAsyncIO2::Write calls.

Prevention and Hardening

Once the OPC errors are resolved, the following practices keep a WinCC 6.0 SP3 installation stable over time.

• Disable automatic Windows Update on the OPC server node. Schedule updates only through a maintenance window approved by the controls team.
• Avoid installing third-party OPC DA clients (generic OPC browsers, Matrikon OPC Explorer, etc.) on the same machine as the WinCC runtime. Use a separate workstation for vendor exploration tools.
• Take a full system image (Clonezilla, Acronis, Ghost) immediately after commissioning and store it offline. The image is the fastest recovery path for any future OPC registration drift.
• Maintain a written component list — every service pack, hotfix, driver, and SCADA option installed on every WinCC node. Any deviation is a leading indicator of repeat symptoms.
• Document the DCOMCNFG and registry baseline (exported reg keys) in the same controlled-document repository as the WinCC project backup.
• Avoid running third-party firewall products on the OPC server node. Windows XP SP2's built-in firewall is adequate once the relevant COM and OPC ports are opened.

Extended Diagnostics — When a Full Rebuild Is Not Possible

If a full reinstall is not feasible on a running plant (weekend-only cutover, regulatory change control, etc.), the following minimal-restore sequence has been demonstrated to recover both Problem 1 and Problem 2 in many cases without reformatting the OS.

1. Uninstall every third-party OPC component: OPC Core Components, third-party OPC DA packs, OPC UA stacks. Use the vendor's official removal tool rather than appwiz.cpl.
2. Reinstall the OPC Core Components bundled with WinCC 6.0 SP3, located under the Redist\OPC Core Components directory on the installation media. Reboot when prompted.
3. Re-register the WinCC server manually:
   regsvr32 "C:\Program Files\Siemens\WinCC\bin\opcproxy.dll"
regsvr32 "C:\Program Files\Siemens\WinCC\bin\OPCServer.exe"
4. Reregister OpcEnum:
   mofcomp "C:\WINDOWS\system32\wbem\OpcEnum.mof"
net stop OpcEnum & net start OpcEnum
5. Reset DCOMCNFG to the values captured in step 2 of the rebuild procedure. Apply the OPC Foundation recommended Access and Launch permissions.
6. Reboot. Run verification 1 through 4 in sequence.

Related Failure Modes to Exclude First

Before applying the procedures above, rule out the following unrelated symptoms that share language with OPC errors but are caused by other subsystems.

FAQ