Resolving WinCC Unified IIS HTTP Error 500.1013 on PC Runtime

Problem Summary

WinCC Unified PC Runtime (also referenced as WinCC Unified SCADA RT) is hosted by Microsoft Internet Information Services (IIS) on the engineering or operator station. When a user navigates to the locally published Runtime URL — typically https://localhost or https://<hostname> — the IIS front end accepts the TLS session and returns the start page, but clicking the WinCC Unified SCADA RT tile or navigating directly to the Runtime application path produces the response:

HTTP Error 500.1013 — Internal Server Error
The page cannot be displayed because an internal server error has occurred.
HRESULT: 0x6d
Module: iisnode

Substatus 1013 is reserved by the IIS pipeline for a Node.js hosting fault surfaced by the iisnode module: the WinCC Unified runtime is a Node.js application packaged as app.js and loaded by iisnode under a dedicated Application Pool. A 500.1013 response indicates the Node.js host process failed to bootstrap, the worker failed to register with IIS, or the Web.config path mappings do not match the installed WinCC Unified directory layout. The most common field cause on a Windows 10 / Windows 11 operator PC is an incomplete IIS feature installation — only a partial IIS role set is present, and the iisnode module (which depends on ISAPIModule, IISNodeModule, WebSocketModule, and several CGI/ASP components) cannot initialize.

Affected Versions and Components

Root Cause Analysis

Substatus codes in the 1000–1999 range of HTTP 500 are application-specific extensions generated by individual IIS modules. The 1013 code is produced by the iisnode Node.js hosting module when it cannot complete the worker handshake, and is frequently accompanied by an HRESULT: 0x6d entry in node_iisnode.log. Confirmed triggers include:

1. Partial IIS installation — required ISAPI, CGI, or HTTP features are not enabled in Windows Features.
2. The ISAPIModule and/or IISNodeModule not registered in the <modules> collection of the WinCC Unified web site.
3. Worker process identity lacking SeAssignPrimaryTokenPrivilege or SeImpersonatePrivilege.
4. A Web.config mismatch after an in-place upgrade of WinCC Unified or after a Windows Feature toggling.
5. An antivirus or EDR product intercepting the node.exe child process.
6. A stale Node.js installation conflicting with the WinCC Unified-bundled Node.js.

The single most common resolution reported by Siemens support — and confirmed by multiple engineering PC recoveries — is enabling the complete IIS feature tree under Control Panel → Programs and Features → Turn Windows features on or off. A partial install (for example, only IIS Management Console and HTTP Errors) compiles the listener but leaves the application-hosting modules absent, which yields exactly the 500.1013 signature.

Prerequisites

Before changing the IIS feature set, verify the following on the affected PC:

• Operating system account: a member of the local Administrators group is required to install Windows features and to modify applicationHost.config.
• WinCC Unified PC Runtime version is listed in the WinCC Unified Configuration under Runtime → PC Systems and the project downloads successfully.
• You have access to the Windows installation media or a configured WSUS / online Windows Update channel so that optional IIS sub-features (CGI, ISAPI, WebSocket) can be enabled without re-imaging.
• A complete backup or system-restore point exists, since the IIS configuration is rebuilt during this procedure.
• Document the current IIS site bindings: netsh http show sslcert and the contents of C:\inetpub\wwwroot\WinCCUnified\Web.config.

Step-by-Step Resolution

Step 1 — Capture the Current State

Before changing anything, export the IIS configuration so that the change can be reversed if necessary:

%windir%\system32\inetsrv\appcmd add backup "BeforeWinCCFix"
copy "%ProgramFiles%\Siemens\Automation\WinCCUnified\Web\Web.config" "%ProgramFiles%\Siemens\Automation\WinCCUnified\Web\Web.config.bak"

Confirm the WinCC Unified SCADA RT service is registered:

sc query "Siemens WinCC Unified Runtime"
sc qc "Siemens WinCC Unified Runtime"

Verify the runtime reports RUNNING in the WinCC Unified Configuration tool (Runtime Manager → Status) before continuing. If the runtime is not running, this entire procedure will not produce a working state — proceed only after the runtime service starts cleanly.

Step 2 — Open the Windows Features Dialog

1. Press Win + R, type appwiz.cpl, and press Enter.
2. Click Turn Windows features on or off.
3. Expand Internet Information Services.
4. Click the checkbox at the root of the IIS tree to enable every sub-feature. Do not selectively disable CGI, ISAPI Extensions, ISAPI Filters, HTTP Errors, HTTP Redirection, or WebSocket Protocol.
5. Click OK and allow Windows to apply the feature changes. Reboot when prompted.

Step 3 — Required IIS Feature Inventory

The following features must be enabled for WinCC Unified PC Runtime to host correctly. Verify each one is checked after Step 2:

Step 4 — Restart the WinCC Unified Site

After the reboot in Step 2, reset IIS and the WinCC Unified Application Pool:

iisreset /restart
%windir%\system32\inetsrv\appcmd recycle apppool /apppool.name:"Siemens.WinCCUnified.WebAppPool"

If the application pool name differs in your installation, list the pools first:

%windir%\system32\inetsrv\appcmd list apppools

Step 5 — Validate the Web.config

Open %ProgramFiles%\Siemens\Automation\WinCCUnified\Web\Web.config and confirm the following handlers and modules are present. If any are missing, re-run the WinCC Unified Configuration tool's Compile & Download to regenerate the configuration.

<system.webServer>
  <handlers>
    <add name="iisnode" path="*.js" verb="*" modules="iisnode" resourceType="File" />
  </handlers>
  <modules>
    <add name="iisnode" />
    <add name="IsapiModule" />
    <add name="WebSocketModule" />
  </modules>
</system.webServer>

Step 6 — Re-publish the Runtime Project

1. Open the WinCC Unified Configuration tool.
2. Right-click the affected PC station → Compile and Download.
3. Confirm the SCADA RT tile shows Running in Runtime Manager.
4. Browse to https://localhost and click the SCADA RT tile.

Verification

Use the following checks to confirm the fault is cleared:

1. Browser request to https://localhost/ returns HTTP 200 with the WinCC Unified start page.
2. Browser request to https://localhost/WinCCUnified/ (or the path published by Configuration) returns HTTP 200 with the Runtime application shell — no 500.1013.
3. Command-line probe: curl -k -i https://localhost/ shows HTTP/1.1 200 OK.
4. Open IIS Manager → select the WinCC Unified site → Modules. Verify iisnode, IsapiModule, and WebSocketModule are listed and Enabled.
5. Inspect the IIS log at %SystemDrive%\inetpub\logs\LogFiles for the latest request — it should record 200 rather than 500 1013.
6. Confirm the node.exe worker is running: tasklist /FI "IMAGENAME eq node.exe" should show at least one instance owned by the application pool identity.

User Rights and Domain Policy Checks

If enabling all IIS features does not clear the 500.1013 fault, the issue may be a stripped-down worker identity. Confirm the following:

Group Policy objects that explicitly deny Log on as batch job or that remove SeAssignPrimaryTokenPrivilege from local administrators will produce the same 500.1013 signature. Audit with gpresult /h gpreport.html and look for policies that override the default user rights assignments.

WinCC Unified Configuration Verification

In the WinCC Unified Configuration tool under Runtime → PC Systems → Web System, validate:

• The HTTPS port (default 443) is not bound by another process. netstat -ano | findstr :443 should resolve to the IIS worker PID.
• The certificate is valid, not expired, and the Subject or SAN matches localhost for local testing.
• The runtime is set to Auto start and the start mode is Start as service.
• The Web Access check box is enabled on the runtime properties.

iisnode and ISAPI Diagnostic Reference

For deep diagnostics, capture both the IIS HTTPERR log and the iisnode log:

type "C:\inetpub\logs\FailedReqLogFiles\*" | findstr /C:"1013"
type "%ProgramFiles%\Siemens\Automation\WinCCUnified\Web\iisnode\*\*\*.log" | more

The iisnode log typically reports HRESULT 0x6d when the worker process exited before it could attach to the named pipe used by iisnode. Common remedies beyond enabling IIS features include:

• Setting the application pool's startMode to AlwaysRunning in applicationHost.config.
• Increasing the nodeProcessCountPerApplication from the default 1 if the start-up race condition persists.
• Excluding the WinCC Unified installation directory from real-time antivirus scanning (a known false-positive trigger).

Troubleshooting Matrix

Preventive Measures

To avoid recurrence after future Windows updates or feature toggles:

1. Use Windows Server roles-as-features or a configuration management baseline (DSC, Ansible, Intune) that enforces the full IIS feature set on operator PCs.
2. Disable the Windows optional feature Internet Information Services Hostable Web Core only if you have a documented reason — some enterprise images strip this and it interacts with iisnode.
3. Schedule a monthly iisreset /status and sc query "Siemens WinCC Unified Runtime" health check in Task Scheduler.
4. Pin the WinCC Unified installation in a documented image and audit any deviation with Get-WindowsOptionalFeature -Online | Where-Object {$_.FeatureName -like "IIS*"}.
5. Back up %ProgramFiles%\Siemens\Automation\WinCCUnified and C:\inetpub after every successful commissioning.

FAQ