Fix SwacLogin Component Creation Error in WinCC Unified

Problem Details

The SwacLogin: Error during component/s creation message is produced by the SwacLogin web component embedded in every WinCC Unified Runtime (RT Unified) web client - the same component used by a Unified Comfort Panel (UCP) in simulation, by a Unified PC Runtime, and by a Unified Operator Panel accessed over the network. The error is raised when the browser-side SwacLogin JavaScript module cannot instantiate one or more of its dependent web components (UMC user management client, WebSocket layer, certificate handler, or local storage binding) before the authentication handshake completes.

Typical field symptoms observed in Chrome 119+, Microsoft Edge 119+, and Firefox 121+:

• The Unified login page renders, then either freezes on the spinner or shows a red banner with the literal text SwacLogin - Error during component/s creation.
• Browser DevTools → Network tab shows that requests to /SwacLogin/, /umc/api/..., or the WSS endpoint on TCP 8443 fail with HTTP 502, 503, or never complete (stuck on (pending)).
• DevTools → Security tab reports a TLS error such as NET::ERR_CERT_COMMON_NAME_INVALID, NET::ERR_CERT_AUTHORITY_INVALID, or MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT.
• DevTools → Console shows Uncaught (in promise) SwacLogin: Error during component/s creation followed by a stack trace into swaclogin.bundle.js.
• On PC Runtime, the Windows Event Viewer (Applications and Services Log → COM+) may show Event ID 10016 (DistributedCOM) or a warning that the WinCC Unified Runtime COM+ application has been disabled.

Per the official Siemens support entry 109774151 - SwacLogin error message on WinCC Unified PC Runtime, the error is reproduced most often when (a) the URL is entered as an IP address but the WinCC Unified server certificate is bound to the host's computer name, (b) the engineering station's browser cache has been cleared after a "Complete download", or (c) the Windows COM+ subsystem on the PC Runtime host has been disturbed by a Windows update.

Affected Versions and Components

Verified symptom reproduction on the following product versions in the field; apply the same diagnostic flow to any release not listed:

Root Cause Analysis

Five distinct root causes account for the overwhelming majority of field reports. The first two are by far the most common, and Siemens documents them explicitly in the support article 109774151 and in the TIA Portal V20 in-product help SwacLogin: Errors after complete download (RT Unified).

Cause 1 - Hostname vs. IP Mismatch

WinCC Unified automatically generates a self-signed TLS certificate for the PC Runtime or simulated UCP using the Windows computer name as the Common Name (CN) and Subject Alternative Name (SAN). When an engineer types https://192.168.1.222 into the browser, the certificate presented by the server is valid for simatic-m6.local but not for 192.168.1.222. Modern browsers enforce RFC 2818 / RFC 6125 hostname verification and will not allow the SwacLogin WebSocket to upgrade to wss://. The component constructor never returns, and the SwacLogin container throws the generic component/s creation error.

Cause 2 - DNS Resolution Failure

The hostname is only useful if the client can resolve it. NetBIOS / mDNS works inside the same Windows workgroup but breaks across subnets, on Android devices, on isolated engineering networks, or when IPv6 is preferred over IPv4 and the WinCC server is not listening on IPv6.

Cause 3 - Port 8443 Blocked

WinCC Unified Runtime listens on TCP 8443 for HTTPS / WSS. If Windows Defender Firewall, a third-party EDR (CrowdStrike, SentinelOne, Trend Micro, etc.), or a corporate proxy blocks outbound 8443, the browser's WebSocket connection hangs and the SwacLogin component times out.

Cause 4 - Browser Cache After Complete Download

Each Complete download from TIA Portal rebuilds the runtime project, regenerates internal GUIDs, and invalidates cached service worker entries. If the engineer had a session open in the browser, SwacLogin keeps trying to reuse the stale IndexedDB entries and fails.

Cause 5 - COM+ Subsystem Failure (PC Runtime Only)

WinCC Unified PC Runtime uses COM+ to host inter-process communication between the visualization service, the logging service, and the web server. A Windows update that resets DCOM launch permissions, or a manual dcomcnfg change, can leave the WinCC Unified Runtime COM+ application stopped. The symptom is identical to the SwacLogin error in the browser, but the root cause is server-side.

Diagnostic Procedure

Run the following sequence on the engineering or operator PC that displays the error. Each step is non-destructive.

1. Capture the exact error - open DevTools (F12) → Console → reload the page → copy the red error line and the URL of the failing request from the Network tab.
2. Identify the URL form used - in the address bar, note whether you typed an IP (https://192.168.x.y) or a hostname (https://simatic-m6).
3. Resolve the hostname from the client - open a Command Prompt and run ping <hostname> and nslookup <hostname>. Both must succeed and return the same IPv4 address as the WinCC server's ipconfig.
4. Test TCP 8443 reachability - run Test-NetConnection -ComputerName <hostname> -Port 8443 (PowerShell) or curl -vk https://<hostname>:8443 --max-time 5. A successful TLS handshake proves the port is open; a certificate warning proves the hostname binding is the issue (Cause 1).
5. Verify the certificate subject - in the browser, click the padlock icon → Certificate → Details → Subject and SAN. Confirm the CN and SAN match the hostname you typed, not the IP.
6. Check Event Viewer on PC Runtime - Windows Logs → Application and Applications and Services Logs → COM+. Look for Event ID 10016 (DCOM), 13568 (COM+), or 19011 (WinCC Unified service) in the last 15 minutes.
7. Check Windows Firewall rules - Get-NetFirewallRule | Where-Object {$_.DisplayName -like "*WinCC*" -or $_.DisplayName -like "*Siemens*" -or $_.Enabled -eq "True" -and $_.Profile -eq "Any"} and confirm inbound 8443 is allowed on the active profile.
8. Reproduce in an Incognito / Private window - if the error disappears, the cause is browser-cache related (Cause 4).

Solutions

Apply the solution that matches the root cause identified above. Multiple causes can be present simultaneously - apply all that match your diagnostic results.

Solution 1 - Use the Hostname URL, Not the IP

Replace https://192.168.1.222 with the actual Windows computer name of the PC Runtime or simulated UCP. Confirm the computer name with hostname on the server side.

Examples:

• Simulation on the engineering PC: https://simatic-m6:8443 (replace simatic-m6 with your engineering PC name)
• PC Runtime on a different PC: https://simatic-pc-rt:8443
• Real Comfort Panel: https://mtp1500-01:8443 (matches the panel's device name from TIA Portal → Devices & networks → Panel → Properties → General)

For cross-PC access where mDNS does not work, add a manual entry in C:\Windows\System32\drivers\etc\hosts:

On Android devices that cannot resolve Windows hostnames, deploy a local DNS server such as Simple DNS Plus (trial version supports up to 50 records) on the engineering subnet and add an A-record for each Unified target.

Solution 2 - Repair the Certificate

If the certificate CN does not match the hostname, regenerate the WinCC Unified self-signed certificate so the SAN list includes every DNS name and IP the client will use:

1. On the PC Runtime, stop the WinCC Unified Runtime service: net stop "WinCCUnifiedRT".
2. Delete the existing certificate: certlm.msc → Personal → Certificates → delete the WinCC Unified entry.
3. Restart the service. The runtime regenerates a new self-signed certificate bound to the current hostname.
4. On the client PC, browse to the new URL once, accept the self-signed certificate warning, and (optionally) export it via the browser to the Trusted Root Certification Authorities store.

For production deployments, replace the self-signed certificate with a certificate issued by the company's internal CA. Import both the server certificate and the CA chain into the Personal store of the PC Runtime account that runs the WinCC Unified service.

Solution 3 - Open TCP 8443

Create a Windows Firewall rule that allows inbound 8443 on the active profile (Domain, Private, Public):

For corporate networks with a central proxy or EDR, ask the network team to allowlist TCP/8443 between the engineering subnet and the runtime subnet. Some EDR products inspect TLS handshakes and drop self-signed certificates - in that case, deploying a CA-signed certificate (Solution 2) is required.

Solution 4 - Clear and Reset the Browser Cache

After every Complete download, follow the exact cleanup sequence listed in the TIA Portal V20 in-product help SwacLogin: Errors after complete download (RT Unified):

1. Close every browser tab connected to the Unified Runtime.
2. Chrome / Edge: Settings → Privacy and security → Clear browsing data → select Cookies and other site data, Cached images and files, and Site settings → clear for the last 1 hour only.
3. Firefox: Settings → Privacy & Security → Cookies and Site Data → Clear Data → also clear Offline Website Data.
4. Re-open the Unified Runtime URL with the hostname form (Solution 1).

Solution 5 - Repair the COM+ Subsystem (PC Runtime Only)

When the Event Viewer shows DCOM Event ID 10016 for the WinCC Unified service account, repair DCOM permissions per Microsoft: An application fails to create a COM+ component:

1. Open dcomcnfg → Component Services → Computers → My Computer → DCOM Config.
2. Locate the WinCC Unified Runtime application.
3. Right-click → Properties → Security tab → set Launch and Activation Permissions to Customize and add the local service account that runs WinCCUnifiedRT with Local Launch and Local Activation rights.
4. Reboot the PC Runtime host.
5. Verify the COM+ application status: Component Services → Computers → My Computer → COM+ Applications → WinCC Unified Runtime should show a green arrow (running).

If the COM+ application is still stopped after the permission fix, run msdtc -resetlog and reboot. This resets the Microsoft Distributed Transaction Coordinator logs that COM+ depends on.

Verification

After applying the relevant solutions, confirm the fix with this checklist. Each item must pass before closing the incident.

Troubleshooting Matrix

Related Configuration Checks

Beyond the five primary causes, the following configuration items are worth verifying to prevent recurrence:

• UMC user store - the User Management Component must have at least one administrator. After a fresh install, the default admin account is the only one present; if it is locked, the SwacLogin authentication will fail and the error message can read as component creation in older V17 builds.
• Time synchronization - the TLS handshake is sensitive to clock skew. A PC Runtime whose clock has drifted more than 5 minutes from the client triggers certificate validation failures that surface as SwacLogin errors. Enable w32time on both ends.
• Browser WebSocket support - confirm chrome://flags/#enable-websockets is not disabled. Some locked-down engineering images disable WebSockets by default.
• Session timeout - the default Unified session is 30 minutes. After it expires, the next click can produce a SwacLogin error if the auto-refresh is not enabled. Set Runtime Settings → Web Client → Session timeout to 0 (no timeout) for 24/7 operator stations.

When to Escalate to Siemens Support

If all five solutions have been applied and verification steps V1-V6 still fail, gather the following bundle and open a support request via the Siemens Industry Online Support portal, referencing entry 109774151:

1. Project archive: TIA Portal → Project → Archive (HSP-supported if the panel is involved).
2. WinCC Unified diagnostics archive: SIMATIC Runtime Tools → Diagnostic files or C:\ProgramData\Siemens\Automation\WinCCUnified\Logfiles.
3. Browser HAR file from DevTools after reproducing the error.
4. Output of Test-NetConnection -ComputerName <host> -Port 8443 from the failing client.
5. Screenshot of the Event Viewer Application log covering the 15 minutes before and after the error.

FAQ