Resolving WinCC Runtime HTML Browser File Download Errors

Problem Overview

When deploying a Siemens WinCC Runtime Advanced (TIA Portal V17) HMI panel or PC-based runtime, the embedded HTML Browser Control frequently fails when an operator attempts to download any file from a hosted webpage. The browser renders the page correctly—SELECT queries against a local SQL database, live table refresh via JavaScript, navigation between links—but the moment a download action fires (Excel export from a PHP/ASP page, GSD file pull from a vendor site, PDF report, CSV dump), the runtime returns an error dialog stating:

"The requested page could not be found."

The same URL and same download work without issue in Internet Explorer 11, Microsoft Edge, Chrome, or Firefox on the same engineering station. The error is therefore not network-, DNS-, or HTTP-server related; it is a limitation of the WinCC HTML Browser Control component itself.

Affected Products and Versions

Earlier TIA Portal releases (V15.1, V16) exhibit the same behavior because the underlying HTML control is IE-based (MSHTML) and was never updated with full HTTP download stack support.

Root Cause Analysis

The WinCC Runtime Advanced HTML Browser Control is not a full-featured web browser. It is a stripped-down rendering surface designed to display static or lightly dynamic HTML inside the HMI screen. Its capabilities and limitations are governed by:

1. The selected browser engine: ActiveX (MSHTML / Internet Explorer Trident) or WebKit (CEF-based).
2. The runtime's hard-coded feature set, which excludes file-system write operations initiated from Content-Disposition HTTP response headers or anchor download="" attributes.
3. Security zone configuration inherited from Windows Internet Options.

When a browser receives an HTTP 200 OK response with a header such as:

Content-Type: application/vnd.ms-excel
Content-Disposition: attachment; filename="export_2024.xlsx"

Edge/Chrome/IE trigger the download manager. The WinCC HTML control cannot route this through a writable temp directory or the Windows download dialog, so it substitutes the generic "page could not be found" response. The same is true for plain anchor links pointing to a binary (.gsd, .pdf, .zip): the control's navigation handler returns the localizable error string and discards the payload.

Engine Selection: ActiveX vs WebKit

From TIA Portal V16 onward, the HTML Browser Control exposes a property to choose between the legacy MSHTML/ActiveX engine and the modern WebKit engine. The path in the HMI configuration tree is:

1. Open the screen containing the HTML browser.
2. Select the HTML Browser object in the screen layout.
3. In the Properties pane, expand Miscellaneous > Browser type.
4. Choose between ActiveX control (Internet Explorer) and WebKit engine (CEF).

Critical observation: Switching from ActiveX to WebKit (or vice versa) does not enable downloads. The constraint is enforced above the engine layer by the WinCC runtime. Document the engine choice based on rendering fidelity, not on download capability.

Diagnostic Procedure

Step 1 — Confirm the symptom is engine-agnostic

1. Create a minimal HTML test page hosted on a workstation within the same subnet as the HMI panel.
2. Place a single anchor: <a href="test.pdf" download>Get PDF</a>
3. Load the page in the WinCC HTML browser on the runtime.
4. Click the link and capture the runtime's localized error string.
5. Switch the HTML browser engine property to the other value, recompile, and repeat.

Identical failure on both engines confirms the WinCC control, not the engine, is the cause.

Step 2 — Validate the same URL on an external browser

On the runtime PC, open the same URL in Edge or IE11 on the engineering station. The download must succeed. If it fails on a real browser, the issue is the web server (MIME type, CORS, HTTPS cert) and not the WinCC control.

Step 3 — Check Windows Security Zone inheritance

The HTML control inherits the Local Intranet or Trusted Sites zone of the runtime process. Even with a working test page, restricted zones can suppress Content-Disposition: attachment responses. Configure Internet Options > Security on the runtime PC and add the server FQDN to Local Intranet. This will not enable downloads but is necessary hygiene for any workaround involving window.open.

Workaround 1 — Trigger the Download from an External Browser Launched by VBScript

The most reliable field-tested approach is to keep the SQL query page inside the WinCC HTML control but route the export action out to a real browser using the WinCC script interface. The runtime exposes the Windows Shell through VBScript.

' WinCC VBScript attached to a button "Export to Excel"
Sub OnClick(ByVal Item)
    Dim sUrl, sFile
    sUrl = "http://10.0.0.50/sqlweb/export.php?table=line01&fmt=xlsx"
    ' Option A: open in default browser, OS will handle the download dialog
    CreateObject("WScript.Shell").Run Chr(34) & sUrl & Chr(34), 1, False
    ' Option B: use Edge in private mode to suppress cached state
    ' CreateObject("WScript.Shell").Run "msedge.exe -inprivate " & Chr(34) & sUrl & Chr(34), 1, False
End Sub

Notes:

• On a panel-based runtime (Comfort Panel), WScript.Shell is not available. Use a button that triggers an HTTP redirect to a URL the operator opens from a connected PC, or export the data via a Siemens S7 connection straight to a USB stick.
• On a PC runtime, ensure the user account under which WinCC Runtime runs has the right to launch explorer.exe or the chosen browser. The default SCADA service account on locked-down builds may need adjustment via secpol.msc > User Rights Assignment > Replace a process-level token.
• Edge and Chrome honor Content-Disposition automatically; the user receives a normal browser download bar.

Workaround 2 — Server-Side Direct Download via WinCC Filesystem Tags

For automated, unattended exports (e.g., end-of-shift report), bypass the browser entirely:

1. Configure a scheduled task on the web server that writes the SQL query result to a network share.
2. In WinCC, create a File System tag pointing to the share, or use a VB script with FileSystemObject to copy the file to a local path the operator can access.
3. Trigger the copy with a button or a scheduled event.

Dim fso, src, dst
Set fso = CreateObject("Scripting.FileSystemObject")
src = "\\10.0.0.50\reports\export_2024.xlsx"
dst = "C:\Users\Public\Documents\export_2024.xlsx"
If fso.FileExists(src) Then
    fso.CopyFile src, dst, True
    HMIRuntime.Trace "Export copied to " & dst & vbCrLf
End If

Workaround 3 — Embed the Excel Export Inline Using JavaScript

If the goal is for operators to view the data inside WinCC without an external file, generate the Excel as a base64 data URI client-side and surface it inside the HTML control. This works because the WinCC control will render any HTML returned in the page; it only fails on discrete file downloads.

<script>
function exportInline() {
    const rows = document.querySelectorAll("#results tr");
    let csv = "";
    rows.forEach(r => {
        const cells = r.querySelectorAll("th,td");
        csv += Array.from(cells).map(c => '"' + c.innerText + '"').join(",") + "\\r\\n";
    });
    const w = window.open();
    w.document.write("<pre>" + csv + "</pre>");
}
</script>

The operator can then use WinCC's soft-keyboard copy/paste or a USB-export script to retrieve the text. This is the most contained approach when strict IT policy prevents launching external browsers.

Workaround 4 — Use the WinCC "Open Internet Explorer" System Function

TIA Portal provides a system function on Comfort Panels and PC Runtime that opens a URL in the default Windows browser (not the embedded control):

1. In the screen, place a button.
2. In the Events tab, click Add function.
3. Navigate to System functions > Open Internet Explorer.
4. Configure the URL parameter to point at the export endpoint.

On a PC runtime this opens Edge/IE; on a Comfort Panel it opens an external viewer if one is configured. This sidesteps the HTML control entirely and preserves the file download path.

Verification Steps

1. Compile the project in TIA Portal V17 with the updated configuration.
2. Start WinCC Runtime and navigate to the screen containing the HTML browser.
3. Confirm the live SQL data renders correctly (no JavaScript errors in the trace).
4. Activate the export action and verify the file lands in the operator's Downloads folder or the configured network share.
5. Open the file and confirm row count, headers, and data types match the database.
6. Repeat the test on a Comfort Panel if the deployment is mixed (PC + panel).

Trace and Logging

Enable WinCC trace logging to confirm the script path executed:

HMIRuntime.Trace "VB Export Trigger: " & Now() & " URL=" & sUrl & vbCrLf

Logs default to %ProgramData%\Siemens\Automation\WinCCRT\Logs\ on PC runtime.

Troubleshooting Matrix

Field-Proven Notes and Caveats

• The Siemens support entry HTML Browser Control in WinCC Runtime (entry ID 109798671) describes supported HTML scope and explicitly notes that complex interactive features beyond simple navigation are not guaranteed.
• When the deployment is on a WinCC Comfort Panel (TP/ KP/ Comfort series), the WScript.Shell approach is not available; the panel's Windows Embedded Compact 7/8 shell has no equivalent automation object. Use the system function or a server push instead.
• If the host PC is hardened under application whitelisting, launching msedge.exe from a VBScript may be blocked. Coordinate with IT to add the runtime process to the allowed launchers.
• On multi-monitor PC runtime setups, opening Edge behind the WinCC window can confuse operators. Pass the window handle so Edge comes to the foreground, or schedule the export to a known folder and show a WinCC message box.
• Verify licensing: the "Open Internet Explorer" system function works on every WinCC Advanced license, but launching external processes through VBScript is restricted on read-only runtime configurations.

Related Standards and References

For deployments that handle regulated data (FDA 21 CFR Part 11, IEC 62443), document the export path and the operator's role-based access controls. The audit trail should record which operator triggered which export, matching the WinCC user log. The web server's authentication should be paired with WinCC's user administration so the SQL query results are scoped to the operator currently signed in to the runtime.