Resolving WinCC V6 Overview Window Blinking and OPC

1. Problem Summary

On a WinCC V6.0 SP4 runtime pair running on Windows XP SP2/SP3, a redundant Operator Station (OS) configuration of one Master and one Standby exhibits the following symptoms in the customer overview window:

• Active alarms inside the assigned picture do not cause the standard incoming/outgoing/acknowledged blink states to appear on the overview window field.
• Blinking appears intermittently and does not correlate with the alarm buffer state on either OS.
• The "Create/update group display" checkbox in the OS Project Editor is set, and the Picture Tree Manager has been re-saved after every graphics change, yet the behavior persists.
• The WinCC channel diagnosis log contains a CoCreateInstanceEx failure for OPCServer.WinCC on the partner OS, returning HRESULT = 80070005 with the symbol E_ACCESSDENIED.

This composite failure almost always combines (a) a Picture Tree Manager / group display misconfiguration and (b) a DCOM access-denied condition between the redundant WinCC servers. Either defect alone can suppress overview blinking; both must be confirmed before closing the ticket.

2. Error Log and Symptoms (HRESULT 80070005)

The canonical evidence source is the WinCC channel diagnosis folder:

Inside this folder are several *.log files that are rotated by the WinCC runtime; sort by Date modified and open the latest entries with Notepad or the WinCC Channel Diagnosis editor. The decisive line for this failure mode is:

Decoding the line:

When CoCreateInstanceEx returns E_ACCESSDENIED, the OPC group cache on the requesting machine is never built. Without that cache, the alarm engine has nothing to read on the next polling cycle, the picture-window AKKZ/BKZ/ZAKZ tags do not toggle, and the standard overview blink graphics remain frozen. Intermittent blinking happens when the cached DCOM handle survives a transient ACL hit and then expires again under load.

3. Root Cause Analysis

Three independent layers must each be correct for redundant overview blinking to work. Any one of them failing produces a silent symptom:

1. DCOM launch + access permissions for the OPCServer.WinCC application. WinCC uses two distinct identities in this scenario: the WinCC runtime service account that calls CoCreateInstanceEx, and the account under which the partner OPCServerWinCC.exe launches on the target machine.
2. Picture Tree Manager group display mapping. The "Create/update group display" process generates the named picture hierarchy that the overview window iterates. If the regeneration fails or runs against a stale *.PDL, the overview pointer cannot resolve the picture name returned by the alarm block.
3. Alarm logging runtime state on both Master and Standby. The blinking state is sourced from the message frame tags AKKZ (acknowledgment bit), BKZ (incoming/outgoing), and ZAKZ (queued acknowledgment). These tags are only updated when the alarm channel successfully receives MsgFlag updates from the partner OS via the OPC channel.

In the logged case, layer (1) is failing first: every picture the overview window enumerates will be starved until the OPC handle is restored, which is why none of the configured groups blink regardless of how the Picture Tree Manager is rebuilt.

4. DCOM Security Configuration (Primary Fix)

The 80070005 error is resolved by giving the WinCC service account and the partner machine's WinCC user Launch and Access permissions on the OPCServer.WinCC DCOM application. On Windows XP this is done through dcomcnfg.exe + the registry on both machines.

4.1 Configure DCOM defaults

1. On both OS machines, log in as a member of the local Administrators group.
2. Open Start > Run > dcomcnfg.
3. Navigate to Console Root > Component Services > Computers > My Computer.
4. Right-click My Computer > Properties. On the Default Properties tab:
   • Enable Enable Distributed COM on this computer.
   • Set Default Authentication Level to Connect (default is correct for the WinCC OPC channel).
   • Set Default Impersonation Level to Identify. Do not select Impersonate here; the WinCC channel will explicitly request RPC_C_IMP_LEVEL_IMPERSONATE per call.
5. Switch to the COM Security tab. Under Access Permissions click Edit Limits... and add:
   • Everyone — Allow Local Access, Allow Remote Access.
   • The WinCC runtime service account (e.g. CC_Admin or the domain user configured in the WinCC Service Mode).
   • ANONYMOUS LOGON — Allow Local and Remote Access. This is required because the OPC channel hop from OS1 to OS2 may cross an authentication boundary under the standby path.
6. Under Launch and Activation Permissions click Edit Limits... and grant Local Launch, Remote Launch, Local Activation, and Remote Activation to the same set of accounts.
7. Click OK on every dialog. The DCOM service must be restarted for the changes to take effect: net stop winmgmt && net start winmgmt or reboot.

4.2 Configure the OPCServer.WinCC application

1. In dcomcnfg, expand My Computer > DCOM Config.
2. Locate OPCServer.WinCC. If multiple OPCServer.WinCC entries exist, treat the one whose Application Name matches the installed WinCC build as the canonical entry; the duplicates are shadows from earlier SP installations.
3. Right-click > Properties.
   • General tab — set Authentication Level to Default (inherits from My Computer default).
   • Location tab — select Run application on the following computer and enter the partner OS hostname. This is critical on the Standby OS: it must point to the Master OS, not to itself.
   • Security tab — under Launch and Activation Permissions choose Customize, then Edit, and add the same accounts listed above with Remote Activation.
   • Under Access Permissions choose Customize, then Edit, and grant Remote Access to the same accounts.
   • Under Configuration Permissions allow Full Control to the WinCC administrator account so the Picture Tree Manager regeneration can write the group display *.PDL files.
   • Identity tab — select The launching user. This forces the OPC server to run under the caller's identity and is the most common cause of 80070005 when set to The interactive user while the WinCC service is started from a non-interactive session.
   • Endpoints tab — confirm that Use static endpoints is selected and that the port range (default 135 plus dynamic) is not blocked.

5. WinCC Service Account and Account Lockdown

WinCC V6 runtime must run under a dedicated domain or local account. Using LocalSystem for the WinCC service is a frequent contributor to E_ACCESSDENIED errors on remote OPC calls because LocalSystem has no network credentials and is mapped to ANONYMOUS LOGON across the network. The required posture:

Configure the accounts through the WinCC Service Mode tool (Start > Simatic > WinCC > WinCC Service Mode) and confirm the same identity is registered on the partner OS. If the local security policy Network access: Do not allow storage of credentials or .NET Passports for network authentication is enabled, the partner OS will silently fail the authentication handshake and return E_ACCESSDENIED. Set this policy to Disabled via secpol.msc on both machines.

6. Redundant OS Configuration (Master/Standby)

The redundant OS pair requires the channel unit OPCHN to be configured with the partner OS as a logical connection. In the WinCC Explorer:

1. Open Tag Management > OPC > OPC Groups (OPCHN Unit #1).
2. Right-click > System Parameters. On the OPC tab set:
   • OPC Server Name: OPCServer.WinCC.
   • Run OPC Server on Computer: partner OS hostname (e.g. V112OS1).
   • Update Rate: 1000 ms minimum; 250 ms is too aggressive and will queue COM calls that mask as access-denied under load.
3. On the Filter tab enable Connection break + Reconnection. Without it, the OPC group is marked dead after the first E_ACCESSDENIED and is not retried, which is why a manual restart of the WinCC runtime often "fixes" the symptom temporarily.

On the redundancy side, open Redundancy > Server in the project tree and confirm that both OS machines are listed with their preferred role (Master / Standby). The role bit is replicated through CCRedundancyAgent on TCP 5003. If the role bit toggles faster than the OPC channel reconnection timer, the overview window will see partial state and appear to blink randomly — this matches the customer's "intermittent" observation.

7. Picture Tree Manager and Group Display Configuration

The blink state is fed to the overview window through group display picture objects generated by the Picture Tree Manager. When the OPC layer is restored, regenerate the group displays:

1. Open WinCC Explorer on the configuration computer (not the runtime OS).
2. Open Graphics Designer > Picture Tree Manager.
3. For each picture that should contribute to the overview, ensure Create Group Display is set on every alarm-capable control.
4. Save the Picture Tree Manager; the change writes PictureTree.pdt in the project folder.
5. Open the OS Project Editor. Under Overview > Area, confirm the picture tree is bound to the runtime picture tree.
6. Check Create/update group display. Click Generate; the project editor will compile all referenced *.PDL files into the overview target. Watch for warnings in the generation log: a missing PDL referenced by an alarm block is logged as Warning 1007141 and silently skipped.
7. After regeneration, transfer the project to the Master OS first, allow a full redundancy sync cycle (default 30 s), then to the Standby.

8. Channel Diagnosis Procedure

Use the WinCC Channel Diagnosis tool to capture a clean log after every change. The procedure:

1. Start > Simatic > WinCC > Tools > Channel Diagnosis.
2. Select File > Open Log Folder; confirm the timestamp matches the live runtime session.
3. Activate Trace > All On and reproduce the fault by triggering a known alarm in the configured picture.
4. Stop the trace after 30 s and inspect the OPCCHN.LOG and OPCHN.LOG files inside the diagnose folder.
5. Search for 0x80070005, E_ACCESSDENIED, and CoCreateInstance. Each occurrence marks a failed OPC bind attempt.
6. If CoCreateInstance succeeds but the next line shows AddGroup failed: 0x80004005 (E_FAIL), the DCOM layer is fine and the OPC server itself rejected the group; restart the WinCC runtime on the partner OS.

The full set of files to attach to a Siemens support request is WinCC_Sys_.log, OPCCHN.LOG, OPCHN.LOG, CCAgent.log, CCSyslog.log, CCRedundancy.log, and the project backup.

9. OPCServer.WinCC Registration and Health Check

Verify the COM registration on both machines:

1. From a command prompt run reg query "HKCR\CLSID" /f "OPCServer.WinCC" /s and confirm a CLSID is returned with LocalServer32 pointing to "C:\Program Files\Siemens\WinCC\bin\OPCServerWinCC.exe".
2. Run dcomcnfg and confirm the CLSID resolves to the same entry shown under DCOM Config.
3. From the Master OS, execute the OPC test client: Start > Simatic > WinCC > OPC > OPC Scout (if installed). Connect to OPCServer.WinCC on the partner OS and add a tag. A successful read+write cycle proves the COM plumbing end-to-end.
4. If OPC Scout also returns 0x80070005, the issue is purely DCOM and not WinCC-specific.

Re-register the OPC server if any registration key is missing or points to a moved executable:

cd "%ProgramFiles%\Siemens\WinCC\bin"
OPCServerWinCC.exe /RegServer
net stop "CCAgent" && net start "CCAgent"

10. Windows XP-Specific Considerations

Windows XP SP2 introduced DCOM hardening that broke pre-SP1 WinCC installs. The post-SP2 fixes that are mandatory here:

• KB875423 — restricts DCOM to authenticated connections only. The fix is to add ANONYMOUS LOGON as documented above; do not disable the hardening globally.
• KB884575 — RPC over TCP defaults to a restricted port range. Ensure the WinCC OPC server's static endpoints are configured to a non-default range and that the firewall is opened.
• Simple File Sharing — must be Off on both OS machines. Simple File Sharing flattens ACLs and causes DCOM to intermittently report E_ACCESSDENIED when the partner looks up the local SID.

11. Verification Matrix

12. Extended Troubleshooting

If the 0x80070005 is cleared but blinking is still absent, walk this matrix:

FAQ