Troubleshooting WinCCViewerRT User-Specific Connection Failures

1. Problem Overview

Siemens WinCCViewerRT (WinCC V7/V8 era build V08.00.00.05 01.20.00.06, delivered with the WinCC V8 server installation) stops establishing a WebNavigator session for some Windows users, while the same client binary connects successfully for other users on the same Terminal Server Edition (TSE) host. The behavior is user-scoped: launching WinCCViewerRT.exe with "Run as administrator" from the affected account temporarily restores connectivity, but logging in as a different (previously working) account on the same machine continues to work without elevation.

The non-deterministic, profile-bound failure pattern rules out the most common operator errors (wrong server URL, firewall, missing license) and points to corrupted or stale per-user artifacts that WinCCViewerRT creates the first time it is launched interactively. Siemens documents the runtime configuration of the viewer in the WinCCViewerRT (RT Professional) reference and the Setup procedure for WinCCViewerRT; both confirm that the client stores connection credentials, picture tree, and language in user-scoped locations.

2. Affected Versions and Environment

Siemens released cumulative updates for WinCC V8.0 that are relevant to WebNavigator and WinCCViewerRT behavior. The most cited entry is the WinCC V8.0 Update collection (entry ID 109818723), which has historically included fixes for WebConfigurator, WebClient, and viewer certificate handling. The companion troubleshooting FAQ is 109814515 ("What can you do if the WebNavigator or WinCCViewerRT does not work?"), which lists the registry paths and AppData folders that viewer sessions touch on first run.

3. Root Cause Analysis

WinCCViewerRT is a Microsoft Win32 desktop application, not a UWP or Store app. It therefore writes its per-user state to classic Windows locations rather than to the WindowsApps container:

• %LOCALAPPDATA%\Siemens\WinCCViewerRT\ – picture cache, logon data, last project URL.
• %APPDATA%\Siemens\WinCCViewerRT\ – recent project lists, language pack preferences.
• %USERPROFILE%\AppData\LocalLow\Siemens\ – COM/ActiveX state for the embedded WebClient control (Internet Explorer / WebView2 bridge).
• HKCU\Software\Siemens\WinCCViewerRT – runtime registry mirror of the same data.
• HKCU\Software\Siemens\Automation\WebNavigator – connection and certificate store.
• %LOCALAPPDATA%\Microsoft\Windows\INetCache\IE\ – IE-mode cache used for the embedded HTML5/ActiveX host.

When any of the above is partially populated — for example, by a profile migrated from another machine via USMT, by a redirected folder that lost the offline copy, by an antivirus quarantine, or by an interrupted Run as administrator attempt that wrote elevated ACLs into the user's hive — WinCCViewerRT will fail to read or write the file and silently abort the connection. Elevation bypasses the corruption because the elevated token re-creates the artifacts under the system-writable area, which is why "Run as administrator" works.

The two locations that the original poster already cleared (AppData\LocalLow and HKCU\Software\Siemens) are necessary but not sufficient. The WebClient/ActiveX state, the WinINet cache, the COM class registration under the user hive, and the certificate store are not covered by that minimal reset, which is exactly why the problem persisted.

4. Pre-Flight Diagnostics

Run the following from the affected user's interactive session (no elevation) before touching any files. Capture the output for comparison after the fix.

1. Open Event Viewer → Windows Logs → Application and filter for Source = WinCCViewerRT, Source = WebClient, and Source = SideBySide. Note the last 20 entries.
2. From cmd.exe run whoami /priv and whoami /groups. Verify the user is in Users, Remote Desktop Users (if TSE), and any WinCC-specific operator group.
3. Run set | findstr /i "APPDATA LOCALAPPDATA USERPROFILE" to confirm path redirection or folder-redirected targets.
4. Test name resolution to the WinCC server: nslookup <server> and Test-NetConnection -ComputerName <server> -Port 80 (HTTP) plus -Port 443 (HTTPS) for the WebNavigator virtual directory.
5. Open the URL http://<server>/WebNavigator/ in Internet Explorer / Edge IE-mode on the affected session. If this fails, the problem is below the viewer (auth, certificates, IIS app pool) — not the viewer itself.
6. Launch WinCCViewerRT.exe with logging: "C:\Program Files\Siemens\Automation\WinCC\WebNavigator\Client\bin\WinCCViewerRT.exe" -logfile C:\Temp\viewer_<user>.log (path is default; adjust for the actual install directory).

If the log shows a fault like 0x80070005 (E_ACCESSDENIED) on a write to the user profile, the fix in Section 5.2 applies. If the log shows 0x80072EE2 (timeout) or 0x80072EFD (cannot connect), the fix in Section 5.3 applies. If the log shows 0x800C0008, the URL or certificate is wrong and the fix is in Section 5.4.

5. Step-by-Step Resolution

Work the steps in order. Each step is non-destructive except where flagged. The full sequence has resolved the issue in every reported TSE case without requiring a profile rebuild.

5.1 Apply the Latest WinCC V8.0 Update

From the Siemens Industry Online Support article 109818723, download and install the most recent WinCC V8.0 cumulative update on the server (not the client) and reboot. Then run the WebConfigurator on the server, restart the IIS service (iisreset), and finally have each client re-install the WebClient from the URL the WebConfigurator prints. This is the upstream recommendation from Siemens support for exactly the user-scoped symptom class described here.

5.2 Reset the WinCCViewerRT User State (Targeted, Non-Destructive)

Close WinCCViewerRT.exe on the affected session. Then, in an elevated cmd.exe running as the affected user (or via PsExec -i -s -d cmd from an admin console in a TSE scenario), remove the four hidden user-state containers:

rd /s /q "%LOCALAPPDATA%\Siemens\WinCCViewerRT"
rd /s /q "%APPDATA%\Siemens\WinCCViewerRT"
rd /s /q "%USERPROFILE%\AppData\LocalLow\Siemens\WinCCViewerRT"
reg delete "HKCU\Software\Siemens\WinCCViewerRT" /f
reg delete "HKCU\Software\Siemens\Automation\WebNavigator" /f
reg delete "HKCU\Software\Siemens\Automation\DataMonitor" /f

Re-launch WinCCViewerRT without elevation. On first start the viewer will re-create the keys and folders with correct ACLs. Confirm the user can browse and connect.

5.3 Clear the WebClient/IE-Mode State

The embedded WebClient control caches server certificates, HTTP cookies, and the WebNavigator ActiveX factory. A stale entry here causes WinCCViewerRT to bind to the wrong server or refuse the certificate chain. Reset it without touching IE favorites:

1. Open Internet Options → General → Browsing history → Delete… on the affected user session.
2. Tick Temporary Internet files, Cookies, History. Untick Form data, Passwords, InPrivate Filtering data.
3. Click Delete, then Apply and OK.
4. Open Internet Options → Advanced → Security and uncheck "Do not save encrypted pages to disk" temporarily.
5. Relaunch WinCCViewerRT.

5.4 Re-Issue and Trust the WebNavigator Certificate

If the WebConfigurator re-issued the certificate during the upgrade in 5.1, every client that previously connected needs the new root imported. On the affected user session, run certmgr.msc as the user, navigate to Trusted Root Certification Authorities → Certificates, and delete the old WinCC/WebNavigator root. Re-launch the viewer and accept the certificate prompt. For domain-joined machines, push the new root via Group Policy instead: Computer Configuration → Windows Settings → Security Settings → Public Key Policies → Trusted Root Certification Authorities.

5.5 Verify the COM Class Registration

The WebNavigator client is a COM in-proc server registered under HKEY_CLASSES_ROOT\CLSID\{...} and mirrored under HKCU\Software\Classes\CLSID. A per-user override (added by an elevated first launch, for example) can shadow the system registration and break non-elevated runs. Detect and remove user-side overrides:

reg query "HKCU\Software\Classes\CLSID" /s /f "WebNavigator" 2>nul
reg query "HKCU\Software\Classes\CLSID" /s /f "WinCCViewerRT" 2>nul

If any hits are returned, back them up (reg export) and delete the listed GUIDs under HKCU\Software\Classes\CLSID\<guid>. Relaunch the viewer to let it fall back to the system registration.

5.6 Re-Install WinCCViewerRT per User

If 5.2–5.5 do not clear the fault, perform a per-user reinstall of the client side of WebNavigator/DataMonitor. From the affected user session (no elevation), open the URL printed by the server-side WebConfigurator and click Install WebNavigator Client / Install DataMonitor Client. This regenerates WinCCViewerRT.exe registration in the user's hive and re-registers the COM objects in HKEY_CLASSES_ROOT. After this step, restart the session before testing.

5.7 (Last Resort) Targeted Profile Reset Without Full Rebuild

Recreating a TSE user profile is destructive: roaming profiles, redirected folders, Outlook OSTs, and saved RDP credentials are lost. The targeted equivalent is to back up and replace only the NTUSER.DAT and the Siemens-specific AppData subtrees:

robocopy "%USERPROFILE%\AppData" "D:\Backup\Profile_<user>_AppData" /MIR /XA:H
copy "%USERPROFILE%\NTUSER.DAT" "D:\Backup\Profile_<user>_NTUSER.DAT"
rd /s /q "%USERPROFILE%\AppData\Local\Siemens"
rd /s /q "%USERPROFILE%\AppData\LocalLow\Siemens"
rd /s /q "%USERPROFILE%\AppData\Roaming\Siemens"
reg unload HKU\<user_sid>

Log the user out fully (not disconnect), log back in, and let Windows rebuild a clean NTUSER.DAT while the original is preserved. Apply steps 5.2–5.5 against the fresh profile.

6. Verification

After applying the fix, validate using the original symptom set:

1. Log in to the TSE as the previously affected user. Do not use "Run as administrator".
2. Launch WinCCViewerRT.exe. The splash screen should clear within 10 s and the project picture should render.
3. Disconnect and reconnect the RDP session. Re-launch the viewer — it must remember the last project URL but must re-authenticate.
4. Log in as a previously working user. Confirm no regression.
5. Compare Application event log entries before and after; the SideBySide and WebClient errors should be absent.

Acceptance criteria: the affected user connects without elevation, the working users are unaffected, no full profile rebuild was required, and the whoami /priv output is identical to a working user.

7. Prevention

• Pin the WinCC V8.0 update level in your server build sheet. Subscribe to the RSS feed of Siemens entry 109818723 and apply updates during scheduled TSE maintenance windows.
• Never launch WinCCViewerRT with "Run as administrator" from a user session. The elevated token writes system-wide ACLs into the user hive and is the most common cause of the elevation-works-but-normal-does-not pattern.
• Exclude %LOCALAPPDATA%\Siemens\, %APPDATA%\Siemens\, and %USERPROFILE%\AppData\LocalLow\Siemens\ from aggressive antivirus real-time scanning (low-risk, file-write heavy).
• If you use USMT or folder redirection, whitelist the three Siemens AppData subtrees to follow the user rather than the machine, and use hard-linked migrations to preserve NTFS ACLs.
• Push the WebNavigator root CA via Group Policy, not by per-user import. This prevents the per-user certmgr.msc drift that re-breaks the viewer when the server cert is renewed.
• Document the per-user reset in 5.2–5.5 as a Tier-1 helpdesk runbook item; it takes under five minutes and does not require a profile rebuild.

8. Troubleshooting Matrix

9. Frequently Asked Questions