Resolving WinCC Operation List Not Displayed in PCS7 V9.1

Problem Details

A redundant PCS 7 V9.1 SP2 UC04 OS Server pair that has been operating for an extended period suddenly stops displaying the Operation list on client operator stations. The list was visible one to two days prior and is now completely absent from every connected client. In the affected installation, an E-Signature for Button Control workflow was being configured at the time the failure was first observed. The runtime under use is WinCC Runtime V7.5 SP2 Update 16.

Symptom summary:

• Operation list window is empty / not rendered on every client.
• No filter is applied in the alarm / operation control.
• Restart of WinCC Runtime on the OS Server does not recover the list.
• Clients are correctly logged in (no licensing fault, no connection loss).
• Alarm OCX control and message logging subsystem suspected.

Environment Reference

Root Cause Matrix

When the operation list disappears without a configuration change, the failure is almost always one of the following seven causes. Diagnose in the order shown because each step eliminates a class of faults that the next step cannot detect.

Pre-Diagnostic: Capture System State

Before any restart or reconfiguration, freeze the evidence. WinCC diagnostics are overwritten on each runtime cycle.

1. Open WinCC Explorer > Tools > Project Duplicator and create a backup of both OS Server projects (Master and Standby).
2. From the OS Server desktop, open C:\ProgramData\Siemens\Automation\WinCC\Diagnostics (path valid for V7.5). Copy the *.log and *.txt files of the last 72 h.
3. On every client, save the runtime screen of the operation list (empty state) to a file share for the failure report.
4. Export the Windows Application Event Log of both OS Servers (eventvwr.msc > Action > Save All Events As…) for the day before the failure to one hour after.
5. Open a Siemens Support Request in parallel — the engineering hours consumed by the support team in Munich are the fastest path for this exact symptom pattern, and Siemens offers a hot-fix path specific to UC04 / Update 16 customers.

Diagnostic Step 1 — Verify Alarm OCX Health

The ALARM OCX is the ActiveX control that streams operations and messages to the runtime. A single broken registration is enough to silence the operation list on all connected clients while alarms still display.

1. On the OS Server, open Command Prompt (administrator) and run:
   regsvr32 /u "C:\Program Files (x86)\Siemens\Automation\WinCC\bin\CCAlarmEventProvider.dll"
   followed by:
   regsvr32 "C:\Program Files (x86)\Siemens\Automation\WinCC\bin\CCAlarmEventProvider.dll"
2. Repeat for CCAlgRtClient.dll, CCEventManager.dll, and CCMsgFilter.dll located in the same directory.
3. Restart the WinCC Alarm Logging Service (CCAlgLgcService.exe) and the WinCC Runtime.
4. Check the Windows Event Log for the source CCAlarmEventProvider. Error 1001 = COM registration failed, error 1005 = access denied (security policy / UAC).

Diagnostic Step 2 — Inspect Operation Logging Database

Operation messages in WinCC V7.5 are written into the OperationLog segment of the runtime database. When the segment reaches its size limit without a configured rollover, the writer thread stalls.

1. Open WinCC Explorer > Alarm Logging > Archives.
2. Right-click the OperationLog archive > Properties.
3. Verify:
   • Path resolves to a drive that is reachable from both OS Servers (UNC path with identical share on the redundant partner).
   • Size limit is greater than 0 (typical 500 MB to 2 GB).
   • Rollover = enabled and Backup target exists.
4. If the path is a local path on Master but UNC on Standby, the partner's writer will fail silently and the operation list will appear empty on all clients because the active server replicates the request to the failed partner.

Diagnostic Step 3 — Redundancy Synchronization Check

PCS 7 redundant OS Servers run a state machine: Primary, Standby, and Fault. If synchronization breaks, the Standby drops into a state where it does not serve the operation list query.

1. On the Master, open WinCC Explorer and select the redundancy icon in the status bar.
2. Verify both servers report State: Synchronized and Time: < 30 s drift.
3. If the Standby reports State: Wait or Fault, force a manual synchronization:
   WinCC > Tools > Redundancy Control > Master-Slave switch
4. Compare the package timestamp on both servers:
   WinCC > Server Data > Show > OS Server Packages
   A delta > one compile cycle indicates a missing re-compile after a recent graphics or E-Signature change.

Diagnostic Step 4 — User Authorization for E-Signature

With E-Signature for Button Control enabled, the operation list is filtered by the user group of the operator currently logged in. If the configured group is missing on the redundant partner, the master will show entries and the standby will not. After a failover, the operation list becomes empty.

1. Open WinCC Explorer > User Administrator on both OS Servers.
2. Compare the user group hierarchy. Pay particular attention to:
   • Group OperatorLevel_1 through OperatorLevel_n
   • Authorization Operation list visible (numeric level 50–100 depending on project convention)
3. If the right-hand panel shows Use local user administration on one server and Use central user administration (SIMATIC Logon) on the other, this is the fault. PCS 7 V9.1 enforces one mode per redundant pair.
4. Align both servers to the same SIMATIC Logon configuration, redeploy, and recompile OS.

Diagnostic Step 5 — Internal Tag Integrity

The operation list is driven by the internal WinCC tag @OperationEnable (Boolean). When the redundant partner is faulted, the tag returns 0 and the runtime suppresses the list to prevent dual-write.

1. On a client, open WinCC Online Tag Diagnosis (in the project: @OperationEnable).
2. If the value is 0, the redundancy layer has disabled operation logging — solve the redundancy fault first (Step 3), then re-evaluate.
3. Verify the tag connection to the Standby server is healthy: Tag Management > Internal Tags > @OPCTags_Standby must show Quality: Good.

Solution: Field-Proven Recovery Sequence

Apply the steps in this order. Do not skip — each step has prerequisites for the next.

1. Stop WinCC Runtime on both OS Servers (Master first, then Standby).
2. Re-register the Alarm OCX suite (Diagnostic Step 1).
3. Align the operation archive path to a shared UNC, e.g. \\PLCSVR01\WinCCArchive\OperationLog\. Both OS Server service accounts (SIMATIC HMI user) must have Modify rights on the share.
4. Re-compile the OS on the engineering station: PCS 7 > WinCC Explorer > OS Project Editor > Compile OS. Select Complete recompile with all picture changes and transfer to both OS Servers.
5. Force redundancy re-sync: start Standby first, wait for State: Synchronized, then start Master.
6. Start WinCC Runtime on Master, then activate the clients.
7. Trigger one operator action on a client (any valve open / close). Verify the entry appears in the operation list within 2 seconds (default refresh interval for WinCC V7.5 SP2).

Configuration Lock: E-Signature on Button Control

Because the original failure was observed while configuring E-Signature, lock the related parameters to a known-good baseline. The E-Signature feature on PCS 7 V9.1 UC04 is regulated by the parameters below; any deviation must be re-validated.

Verification

1. On the OS Server Master desktop, open the operation list. Verify entries appear in chronological order with operator name, timestamp, tag name, and old/new value.
2. Force a failover: in WinCC Explorer, right-click redundancy > Switch master-slave. Repeat the operation on a client. The entry must appear identically on the new master within 2 s.
3. Disconnect the redundant partner (simulate a hardware fault). The single remaining server must continue to populate the operation list — confirm.
4. Reconnect the partner. The duplicate count of operation messages must be zero (WinCC V7.5 SP2 includes a de-duplication filter for redundancy).
5. Run a 24-hour soak test. Verify the operation log archive rolls over correctly and the previous segment is backed up to the configured network share.

Preventive Hardening

• Apply WinCC V7.5 SP2 Update 17 or later (UC04 + 1). Siemens consolidated several operation-logging fixes in UPD17 — confirm availability through the Siemens Industry Online Support portal.
• Set the Windows service WinCC Alarm Logging recovery to Restart the Service on first failure, Restart the Computer on second failure.
• Schedule a daily differential backup of the OperationLog archive directory. This satisfies the audit trail requirement and limits the impact of a corrupted segment.
• Lock the operation log archive size to a value that produces a 30-day retention minimum at the site's logging rate.
• Disable the Windows time service drift to more than 5 s — the operation list ordering depends on server-clock alignment between Master and Standby.

When to Escalate to Siemens Support

Open a service request with Siemens if any of the following are true after the recovery sequence:

• Re-registration of the Alarm OCX suite fails with error 0x80070005 (access denied) — this indicates a Group Policy conflict that the local engineer cannot override.
• Operation list is empty on Master but populated on Standby even after a forced resync.
• De-duplication of operation messages after failover is incorrect (duplicate entries observed).
• E-Signature comment / reason code is not written to the audit log even though the dialog was completed.

For all of the above, attach the diagnostic bundle collected in the Pre-Diagnostic section to the support request. The bundle reduces average resolution time from days to a single engineering shift.