Troubleshooting WinCC Unified Web Control 404 Error on Client PCs

Problem Description

A Siemens WinCC Unified PC Runtime V17 system hosts an embedded Web Control object on a screen, configured to navigate to a Google Docs spreadsheet that has been published via "Publish to web". The behavior splits cleanly along the runtime topology:

The fault is reproducible only when the page is rendered inside the embedded browser control of a remote client session; the underlying resource exists and is reachable. The host PC does not exhibit the fault, which immediately rules out content availability and points to a rendering-path or transport-path restriction that is unique to the client connection.

Affected Environment and Versions

The WinCC Unified V17 system manual states that the Web Control object uses an embedded browser that obeys the standard web security model. This model includes HTTP headers returned by the target site such as X-Frame-Options, Content-Security-Policy: frame-ancestors, and authentication cookies bound to the originating network.

Root Cause Analysis

Three concurrent conditions must be inspected before any single root cause is declared:

1. HTTP security headers on the target page — X-Frame-Options: DENY, X-Frame-Options: SAMEORIGIN, or Content-Security-Policy: frame-ancestors 'none' on the Google Sheets response will prevent the page from being framed by the Web Control. When such a header is present, browsers surface a generic error page that — depending on the version of the embedded browser control — is presented as a 404-style blank page or as an opaque browser error.
2. Routing asymmetry between host and client — The Runtime host PC frequently shares the same default gateway, DNS resolver, and proxy configuration as the resource host (the Google Docs origin). A remote client PC may route to the Internet through a different proxy or firewall that returns a 404 (often a captive portal or web-filter response) instead of the genuine site content.
3. Session-bound tokens and IP-bound auth — Google "Publish to web" issues a content URL that is not bound to a user session; it is anonymously fetchable. However, if the operator instead pastes the regular edit/view URL of the sheet (which requires a Google account and binds cookies to the host origin), the embedded Web Control on the host may appear to work via cached credentials while the remote client triggers Google auth redirect — and on some browsers this redirect chain terminates with a 404-shaped page.

How the Embedded Web Control Resolves URLs

The Unified Web Control object instantiates a Chromium-based web view (Microsoft WebView2 in V17) on each runtime node. The URL property is passed to the control and navigated inside the runtime process. The key behavior difference between host and remote client is the network namespace in which the navigation occurs:

Because the host process executes the WebView2 inside the Runtime's own network context, it normally follows the host's authenticated egress path. The remote client's WebView2 runs inside the client session on the operator workstation; that workstation's network stack, proxy, and group policies are the ones applied to the navigation. Anything that the host's stack permits but the client's stack filters will cause a divergence of behavior.

Diagnostic Procedure

Run the following steps in order on the failing remote client PC. Each step isolates one variable. Stop when the 404 disappears.

1. Capture the exact URL embedded in the Web Control. In TIA Portal V17, open the screen containing the Web Control and read the URL property. Confirm it begins with https:// and points to the public publish link (not the edit link).
2. Test the URL in a standalone browser on the client PC. Open Microsoft Edge on the remote client and navigate to the published URL. If this returns 404, the URL is wrong, the publishing was disabled, or the egress is filtered. Re-publish and confirm.
3. Inspect HTTP headers with curl on the client PC. From a command prompt on the remote client, run:
   curl -I -L "https://docs.google.com/spreadsheets/d/<ID>/pubhtml"
   Look for these red-flag headers:
   X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'none' ...
   If any of these is present, the page will be blocked inside an <iframe>-style host (which the WebView2 internally implements).
4. Compare headers from the host PC. Run the same curl -I from the host PC. Headers should be identical. If the host receives permissive headers and the client receives restrictive ones, a transparent proxy on the client network is rewriting responses — a captive portal or web filter.
5. Test egress without proxy. On the client PC, open Settings → Network & Internet → Proxy and disable any automatically detected settings. Restart the Unified Client and retest. If 404 disappears, the proxy is injecting HTML or rewriting responses.
6. Capture the WebView2 console. WinCC Unified V17 logs WebView2 console output to the Runtime diagnostic directory. On the host:
   C:\ProgramData\Siemens\Automation\WinCCUnified\WebClient\logs\
   and on the client:
   %LOCALAPPDATA%\Siemens\Automation\WinCCUnified\WebClient\logs\
   Search for net::ERR_BLOCKED_BY_RESPONSE, 404, X-Frame-Options, or frame-ancestors.
7. Inspect IIS logs on the host. WinCC Unified publishes its Runtime web pages on Microsoft IIS. 404s that originate from the Runtime web pages (as opposed to the embedded page) are logged in:
   C:\inetpub\logs\LogFiles\W3SVC*\
   See Microsoft's Troubleshoot HTTP 404 File Not Found in IIS for the standard field layout and remediation matrix.

Solution 1 — Host the Page on the Local Network

The supported engineering practice is to host the operator-facing page on a server that the operator controls. This eliminates both the X-Frame restriction and the cross-Internet authentication problem.

1. Export the Google Sheet as .xlsx or .csv on a scheduled task (or use Google Apps Script to write the file directly).
2. Place the file (or a generated HTML view of it) under an IIS virtual directory on the Runtime host, for example https://rt-host.local/operator/.
3. Confirm the virtual directory is reachable from the remote client: curl -I https://rt-host.local/operator/sheet.html must return HTTP/1.1 200 OK.
4. In TIA Portal, set the Web Control URL property to the local HTTPS URL.
5. If TLS is used for the local URL, install a certificate from the plant CA on the WebView2 host. WebView2 enforces certificate validation by default and will not display pages with self-signed or untrusted certs.

Solution 2 — Configure Permissive Headers on the Hosting Server

If the page must be hosted on a server the operator does not own, the only reliable workaround is to make the response explicitly framable. This is a configuration change on the target server and cannot be applied to docs.google.com. For internally hosted pages:

1. Open IIS Manager on the host that serves the page.
2. Select the site or virtual directory, then open HTTP Response Headers.
3. Either remove the existing X-Frame-Options header or set it to ALLOW-FROM https://rt-host.local (legacy) or, preferably, add a Content-Security-Policy header:
   Content-Security-Policy: frame-ancestors 'self' https://rt-host.local https://*.your-plant.local
4. Reset IIS with iisreset and retest from the remote client.

If the page is served by a Linux/nginx host instead, add the equivalent header in the server block:

The same logic applies for Apache mod_headers:

Solution 3 — Fix the Client Network Path

If the URL itself must remain at docs.google.com, the client-side network stack must be made equivalent to the host's. Verify each item below.

IIS-Specific 404 Diagnostics

If the Runtime's own pages (not the embedded sheet) return 404, the WinCC Unified web is itself failing. Microsoft publishes a structured troubleshooting matrix for IIS 404s that applies directly here. The most common causes found in WinCC Unified sites are:

1. Renamed or relocated files. The Unified RT web is installed under C:\Program Files\Siemens\Automation\WinCCUnified\WebClient\. After a TIA Portal re-installation or a project recompile, file layout can shift. Compare the virtual directory's physical path to the actual on-disk layout.
2. Disabled web service extensions. The Unified web relies on ASP.NET Core Module and the WebSocket Protocol. In IIS Manager, confirm the following are set to Allowed:
   — ASP.NET Core Module
   — WebSocket Protocol
   — HTTP Activation
3. Unmapped MIME types. Unified uses .json, .wasm, and .pck files at runtime. If IIS does not have MIME mappings for these, the request returns 404. Add:
   .json → application/json
.wasm → application/wasm
.pck → application/octet-stream

Microsoft's Troubleshoot HTTP 404 File Not Found in IIS article enumerates additional scenarios, including permission-denied masquerading as 404 (sub-status 404.7 / 404.8) and URLScan rejections.

Verification Checklist

After applying any of the three solutions above, run the following matrix to confirm a complete fix. Each row must pass before the issue is closed.

Preventive Configuration

To prevent recurrence after TIA Portal upgrades or network changes:

• Pin the WinCC Unified PC Runtime to a specific maintenance version and document it in the plant's automation asset register.
• Use only locally hosted, plant-controlled URLs inside the Web Control. Avoid public SaaS links inside embedded browser objects.
• Maintain a list of permitted destinations in the Unified Client's proxy exception file. Re-apply after any proxy firmware update.
• Keep Microsoft Edge WebView2 Runtime on a current Evergreen channel build; legacy builds handle X-Frame-Options and CSP inconsistently.
• Schedule a quarterly smoke test that opens every Web Control URL from at least one remote client and verifies the diagnostic log.

FAQ