WinCC Picture Tree Navigator Grayed Out: Troubleshooting Guide

Problem Overview

On a WinCC V7.0 SP3 Up7 system running on Windows 7 Professional 64-bit, the picture tree navigator in Runtime occasionally renders blank or fully grayed out on individual HMI clients. The deployment in question is a multi-station SCADA architecture with:

• 1 Engineering Station (ES)
• 2 WinCC OS Servers (redundant pair)
• 11 WinCC OS Clients connected to the servers
• Clients accessed remotely through RDP on HMI panels

The failure is intermittent (approximately once per day) and is not a hard fault: when the picture tree fails on a single client, the OS servers and the other ten clients continue operating normally. Memory and CPU headroom on the affected client remain above 50% at the time of failure, and the CCPtmRTserver.exe process is observed running. No entries are written to WinCC_Sys_0x.log in C:\Program Files (x86)\Siemens\WinCC\diagnose during the incident window. The issue is reproduced with a full administrator login, which rules out a classic authorization-based grayout.

This article organizes the diagnostic path, root-cause candidates, and field-proven remediation steps for this class of failure.

WinCC Picture Tree Architecture

Before troubleshooting, it helps to understand the runtime components that paint the picture tree. The picture tree navigator is delivered to the client by a chain of three runtime services that are configured by the WinCC project and instantiated when Runtime starts.

The picture tree texts and hierarchy are typically generated server-side from the project database by C-actions under the Picture Tree Management area. The C-runtime compiles these actions at project startup; if compilation produces a soft error, the resulting tree control can render without errors in the log file yet still fail to populate the button captions at runtime.

Documenting the Symptom

Capture the following data the first time the failure occurs. This isolates the failure faster than a generic service request.

1. Timestamp and time zone of the grayout, accurate to the minute.
2. Affected client hostname and IP address, plus the RDP source IP (TS gateway / jump host).
3. Active OS server at the time of failure (WinCC Redundancy status window, or SIMATIC WinCC Explorer > Server Data).
4. Logged-in user and the WinCC authorization level (administrator, operator, supervisor).
5. Process state on the affected client: confirm CCPtmRTserver.exe PID, working set, handle count, and child processes with Process Explorer or tasklist /v.
6. Client-side screenshot of the grayed-out picture tree, plus a screenshot of the same client 30 minutes after the issue self-resolves.
7. Network latency between client and server at the time of the incident (ping -t continuous capture is acceptable for a quick check; psping is preferred for TCP latency).

Common Root Causes

For this WinCC V7.0 SP3 / Windows 7 Professional 64-bit topology, the failure pattern matches a small set of known causes. Treat them as a ranked checklist, not a guess.

Step-by-Step Diagnostic Procedure

Run the steps in order. Each step is faster than the next, and most field cases stop at step 4.

1. Confirm the version parity of all WinCC stations. On every ES / OS / client, compare Help > About in WinCC Explorer. They must all read WinCC V7.0 SP3 + Up7. Mixed levels are the single most common cause of intermittent picture tree issues that do not write to the log.
2. Check the C-script compilation status. Open the ES project, right-click the project node, and select Rebuild C-scripts. Redeploy the project to the OS servers and propagate to clients. C-script compilation errors that occur at runtime (not at project load) are written to CCAlgRtLog.txt in the project directory, not to WinCC_Sys_0x.log.
3. Capture a Process Monitor trace on the affected client. Filter on the WinCC project directory and on CCPtmRTserver.exe. Capture for 10 minutes before and 10 minutes after the expected incident. Look for FILE_NOT_FOUND, SHARING_VIOLATION, or ACCESS_DENIED on any .pdl, .fct, or *.ldf file.
4. Inspect the RDP session on the HMI client. Open tsadmin.msc or query qwinsta on the HMI. Check session idle time, session state, and whether the WinCC Runtime window is in a disconnected or active state. A disconnected RDP session can leave WinCC Runtime alive on the console but the GDI surface frozen.
5. Check authorization propagation. From the affected client, run apdiag.exe (shipped with WinCC in ...\WinCC\bin). It prints the effective rights for the currently logged-in user, including group membership. A user that appears as administrator to the OS but is missing the WinCC operator group will not have permission to enumerate the picture tree.
6. Inspect memory pressure on the RDP host. Open Reliability and Performance Monitor on the HMI / RDP jump host and look at \Memory\Available MBytes, \Processor(_Total)\% Privileged Time, and the WTS process for the affected session. Brief 5 to 15 second stalls are sufficient to break a picture tree repaint without a hard fault.

Log File Analysis

WinCC V7 writes multiple log streams. The single most common reason a "gray picture tree with no log entry" surprise happens is that the engineer is reading the wrong file.

RDP-Specific Considerations

Eleven clients reached over RDP concentrate every GDI and clipboard acceleration issue onto a single hop. Three settings are responsible for most picture tree instability on RDP sessions.

1. Disable Remote Desktop Composition. Open

   gpedit.msc > Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Remote Session Environment and set Do not allow desktop composition to Enabled. Composition uses the GPU and can stall on virtual HMI panels.

2. Pin the color depth. Group Policy: Limit maximum color depth = 16 bit. 32-bit RDP sessions with a SCADA picture tree that refreshes a label can produce 1 to 2 second repaints that the user perceives as a grayout.
3. Disable font smoothing. On the HMI client, System > Properties > Advanced > Performance > Visual Effects clear Smooth edges of screen fonts. WinCC Runtime caches fonts aggressively; a font handoff between GDI and DirectWrite during an RDP reconnect is a known picture tree failure trigger.

On the RDP jump host, verify that no screen saver, lock policy, or disconnected-session policy is killing the GDI surface of the WinCC Runtime window. Session timeout policies longer than 4 hours are typical for HMI panels and prevent the silent disconnects that often look like a picture tree failure.

User Rights and Authorization

The grayout behavior is intentional when the active user lacks Authorization Area 0 — Picture Tree. The check is performed at the moment the tree is repainted, so a user change that occurs while the tree is being re-evaluated can produce a transient state in which the area buttons are visible but have no text.

Verify in three steps:

1. In WinCC Explorer > User Administrator, open the affected user and confirm the group membership under Authorizations.
2. Run apdiag.exe on the affected client while Runtime is running. Confirm the user resolves to a group with the picture tree rights.
3. Check APLOG on the server for the affected timestamp. Look for a Logoff or Authorization change event within 60 seconds of the incident.

If the user is administrator, the user-rights path is closed; the failure is then a C-script, RDP, or project-parity problem.

Memory, CPU, and Process Diagnostics

The 50% free memory figure is a steady-state average, not a worst-case capture. A 5-second stall is enough to break a tree repaint and is invisible in 1-minute polling. Capture the following counters on the affected client and the RDP host at 1-second resolution for 24 hours.

You can also dump the working set of CCPtmRTserver.exe with psapi tools or a one-liner: Get-Process CCPtmRTserver | Select-Object Id,WorkingSet64,HandleCount,CPU. A growing handle count combined with stable memory is a strong signal that the runtime is leaking GDI handles, which is what produces the grayout as the desktop GDI budget is exhausted.

SIMATIC Assessment Suite — Data Collector

When the in-place diagnostics do not isolate the cause, escalate with a structured data capture. Siemens ships the SIMATIC Assessment Suite - Data Collector (SAS-DC), formerly SIMATIC Diagnostics Tool (SDT), which collects a complete snapshot of the system in a single archive.

1. Download SAS-DC from the Siemens support entry referenced in the official documentation: SIMATIC Assessment Suite - Data Collector (SAS-DC).
2. Run SAS-DC on the affected client during the failure window if possible, or immediately after.
3. Re-run SAS-DC on the active OS server so the service request contains both sides of the conversation.
4. Open a Service Request at Siemens Industry Online Support and attach the archives. Reference the WinCC version (V7.0 SP3 Up7), the OS, and the symptom class Picture Tree Manager: empty / grayed area buttons.

Fixes and Workarounds

Apply the changes in the order listed; each is independently sufficient for a subset of the failure modes and each is reversible.

1. Repackage the picture tree C-scripts. On the ES, run Rebuild C-scripts and redeploy. This is the single most effective fix when CCAlgRtLog.txt is empty but the C-action handles are stale.
2. Align all stations to V7.0 SP3 Up7. Mixed levels in the picture tree path are an unsupported configuration and a documented cause of intermittent grayouts.
3. Configure the WinCC client for autostart via a scheduled task that runs WinCCExplorer.exe -autostart at session start. This guarantees that CCPtmRTserver.exe is started by a known mechanism after RDP reconnects.
4. Add an exception to antivirus for the WinCC project directory and for CCPtmRTserver.exe. Real-time scanners that touch *.pdl during a repaint produce a soft lock that the runtime does not log.
5. Disable RDP desktop composition and pin color depth as described in the RDP section above. This is required, not optional, for picture tree stability on HMI panels.
6. Patch the runtime with the latest hotfix available for WinCC V7.0 SP3. Several picture tree fixes are released as Up readmes and not advertised in release notes; check the entry list on the Siemens support portal for the exact Up build installed on the OS server.

Verification

After applying a fix, validate over a 48-hour window with the picture tree on the previously affected client. The acceptance criteria are:

1. The area button captions render within 2 seconds of Runtime start and within 1 second of an authorization change.
2. CCPtmRTserver.exe working set is stable across the 48-hour window. A drift above 10% warrants a fresh diagnostic capture.
3. No entries in CPtmRtServer_<computername>.log indicating a C-action failure or a picture reload storm.
4. The apdiag output of the affected user matches the expected authorization set after every re-login.
5. The 24-hour, 1-second counter capture of the RDP host shows no session churn at the time of any grayout, ruling out RDP reconnection as the cause.

If the failure recurs with the same profile after all six fixes, escalate with SAS-DC data and the 48-hour counter capture. The picture tree is the most sensitive runtime component to a wide range of environmental factors and is the one that surfaces environment-level bugs before any other WinCC subsystem.