Resolving WinCC DCOM Server Start Failure on Windows

Overview

The runtime error "Failed to start a server. Check your DCOM settings" is reported by SIMATIC WinCC (V7.x, WinCC Professional, and WinCC Runtime) when the Microsoft Distributed Component Object Model (DCOM) service cannot be brought online. Because WinCC's internal communication layer, OPC server, archive system, and channel connections rely on DCOM, a single corrupted or reverted DCOM configuration causes the entire HMI/SCADA runtime to refuse starting. The error dialog is shown by the WinCC Explorer or by the TIA Portal WinCC runtime loader the moment the project is activated.

The most diagnostic symptom is that the Windows Component Services > Computers > My Computer > Properties > Default Properties tab still shows Enable Distributed COM on this computer as checked, but after a reboot the option silently unchecks itself. Restoring the checkmark manually allows WinCC to start, yet the setting is lost on the next power cycle, making the problem recurring and unsuitable for production operation.

This reference documents the full root cause analysis, the permanent remediation steps (registry edit, Siemens Security Controller, Dcomenable utility), security-software interference (Kaspersky, antivirus, Windows Update rollback behavior), OPC and wireless link considerations, verification procedure, and a fault-cause matrix. It is written for commissioning engineers and system integrators who need to deploy a deterministic DCOM configuration that survives reboot, Windows updates, and AV scans.

Architecture: Why WinCC Requires DCOM

SIMATIC WinCC uses COM/DCOM for three distinct functions:

1. Internal WinCC data manager (Tag Management) – the WinCC server exposes channel DLLs and tag lists through COM to the WinCC client and to the graphics runtime.
2. OPC DA / OPC HDA / OPC AE server – WinCC ships an OPC server that registers itself as a local COM server and advertises its class GUIDs through the Windows registry; OPC clients connect over DCOM.
3. Redundancy and client/server replication – in distributed (multi-client) and redundant (Server/Server) topologies, WinCC uses DCOM to negotiate archive synchronization, alarm routing, and user administration between paired servers.

If DCOM is disabled, the WinCC service cannot instantiate any of the above COM objects, the WinCC Explorer receives a class-not-registered or access-denied response, and the application surfaces the generic Failed to start a server error. The wording is intentionally non-specific because the failure point may be WinCC's CCEServer, the OPC enum, or the channel DLL – the WinCC team treats the DCOM subsystem as the single point of fix.

Root Cause Analysis: Why the Checkbox Reverts

Field experience identifies four primary causes for the Enable Distributed COM on this computer checkmark being reset on reboot. Each must be ruled out in order.

Prerequisites and Tool Inventory

Collect the following before changing the configuration:

• Local administrator account or a domain account with Debug Programs and Manage auditing and security log rights.
• SIMATIC WinCC installation media matching the installed version (V7.4 SP1, V7.5, V16, V17, V18, V19 – the steps below are version-agnostic but you must run the same version's Security Controller).
• dcomcnfg.exe (Component Services) – built into Windows.
• regedit.exe – built into Windows.
• SiSecurityController.exe – located at C:\Program Files\Siemens\Automation\SiSecurityController.exe (WinCC V7) or C:\Program Files\Siemens\Automation\WinCC\bin (TIA).
• Dcomenable – a small WinCC support tool provided by Siemens Support; the engineer should request the current build by referencing the WinCC DCOM search term in Siemens Online Support (search string: "WinCC DCOM").
• Latest Windows cumulative update inventory – winver + wmic qfe list snapshot.

Step-by-Step Remediation

Step 1 – Verify the Current DCOM State

1. Open Component Services (run dcomcnfg).
2. Navigate to Console Root > Component Services > Computers > My Computer.
3. Right-click My Computer &strong> and choose Properties.
4. On the Default Properties tab, confirm Enable Distributed COM on this computer is checked, the default authentication level is set to Connect, and the default impersonation level is Identify.
5. Note the value – this is the symptom you will repair.

Step 2 – Apply the Registry-Based Permanent Fix

The checkbox maps to the registry value EnableDCOM = "Y" under HKLM\SOFTWARE\Microsoft\Ole. Setting it explicitly via a script makes the change survive reboots and most AV hardening cycles.

1. Open regedit as administrator.
2. Browse to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole.
3. Set EnableDCOM (REG_SZ) to Y. If the value is missing, create it.
4. Browse to HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DCOM. If this key exists, delete or rename it – it is the Group Policy override applied by AV suites and by Windows hardening updates.
5. Browse to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc. Verify DCOM Protocols contains ncacn_ip_tcp as the first entry.
6. Close regedit and run gpupdate /force to flush any cached policy.

For fleet deployment, push the same keys through a .reg file or a Group Policy Preference. The minimal file content is:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole]
"EnableDCOM"="Y"
"EnableRemoteConverter"="Y"
"LegacyAuthenticationLevel"=dword:00000002

[-HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DCOM]

Step 3 – Run the Siemens Security Controller with Repeat Settings

The Security Controller is the canonical Siemens tool for re-applying the WinCC-specific DCOM ACLs (the default values are listed in the WinCC installation manual, section "DCOM Configuration with the Security Controller").

1. Close WinCC Explorer and stop all SIMATIC services: net stop "S7IEFOx" /y, net stop "CCAgent" /y, net stop "CCEServer" /y.
2. Navigate to Start > Programs > Siemens Automation > Security Controller (or run SiSecurityController.exe from the install path).
3. Choose Repeat settings from the program menu. This action re-issues the WinCC-specific DCOM launch and access permissions to the local SIMATIC HMI and SIMATIC NET user groups, restores the default authentication level, and writes the AppID ACLs for the WinCC and OPC servers.
4. Wait for the Settings applied confirmation dialog. Do not interrupt the process.
5. Reboot the machine.

Step 4 – Run the Dcomenable Utility

The Dcomenable tool is a small executable distributed by Siemens Support specifically to repair DCOM after an antivirus or update cycle has re-disabled it. It combines Steps 1–3 in a single execution and is useful when the Security Controller is not available (for example on a TIA WinCC Runtime installation that does not include the V7-era controller).

1. Extract the tool to a working directory. The executable is typically Dcomenable.exe; the bundled readme lists the registry keys it touches.
2. Run it from an elevated command prompt: Dcomenable.exe /enable /silent. The /silent switch suppresses the dialog and writes a log to %TEMP%\Dcomenable.log.
3. Restart the machine.

Step 5 – Re-enable WinCC

1. Start WinCC Explorer (V7) or open the project in TIA Portal (V16+).
2. Activate the project.
3. Confirm in the WinCC diagnostics window that no DCOM or OPC alarm is raised in the startup phase.

Handling Security Software Interference (Kaspersky and Similar)

Kaspersky Endpoint Security, Kaspersky Internet Security, and Kaspersky Small Office Security install a host-based intrusion prevention (HIPS) component that actively monitors the DCOM launch surface. The HIPS rules remain in the registry and the Windows service catalog even after the product is uninstalled, which is why the original engineer observed the same fault after removal.

To clean up the residual policy:

1. Use the vendor's official removal tool (e.g. kavremover.exe for Kaspersky) – standard uninstall is insufficient.
2. Delete the residual services: sc delete AVPM, sc delete kavsvc (do not delete blindly; verify the service description first).
3. Remove the policy keys:
   • HKLM\SOFTWARE\Policies\KasperskyLab
   • HKLM\SOFTWARE\Wow6432Node\KasperskyLab
   • HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DCOM (this is the DCOM override that the AV product wrote)
4. Reboot and re-run the Security Controller in Repeat settings mode.

For environments that require an active endpoint protection product, configure an exception for the WinCC directories (C:\Program Files\Siemens\Automation, C:\Program Files\Siemens\WinCC) and for the SIMATIC services (CCAgent, CCEServer, S7IEFOx, OPCEnum). Document the exception list in the plant cybersecurity policy.

Handling Windows Update Regressions

Several cumulative updates re-tighten DCOM ACLs as part of the MS-DCOM hardening track. Symptom: the engineer enables DCOM, the system works for weeks, then the next Patch Tuesday silently reverts the setting.

Mitigation options:

• Add a scheduled task that runs at startup and calls Dcomenable.exe /enable /silent under the SYSTEM account. This is the most reliable belt-and-braces fix.
• If the schedule is not acceptable, deploy a Group Policy Preference that writes EnableDCOM = Y at computer startup. GPP runs in the computer context, before the user logon, and is processed after Group Policy but before AV hardening scripts in the majority of environments.
• Pause updates on production HMI stations via wuauserv service configuration or via Windows Server Update Services (WSUS) approval – this is the only deterministic way to prevent regressions in FDA/GMP validated environments.

OPC and Wireless Considerations

The original report mentions that the DCOM fix succeeded but the wireless network connection ceased to work. This is a known interaction: the DCOM firewall exception created by the Security Controller opens TCP port 135 and the dynamic RPC port range (49152–65535 in Windows 7 and later). Some Wi-Fi drivers – particularly the Intel Wireless-N and Realtek RTL8xxx series shipped with industrial panel PCs – enter a low-power state when the dynamic RPC range is touched by a wake-up packet. If the field engineer sees Wi-Fi drop after the Security Controller runs:

1. Limit the RPC port range to a fixed allocation by setting HKLM\SOFTWARE\Microsoft\Rpc\Internet > Ports = 5000-5020 and HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Rpc > UseInternetPorts = 0.
2. Add a Windows Firewall rule for the fixed range only.
3. Disable the Wi-Fi adapter's power-saving mode in Device Manager > Wi-Fi Adapter > Properties > Power Management.

For OPC traffic specifically, prefer OPC UA (which does not use DCOM) on any link where Wi-Fi is the only option. WinCC Professional supports OPC UA natively; V7.x supports it through the WinCC OPC UA Server option. The DCOM-free architecture eliminates the entire class of regressions documented in this article.

Verification Procedure

After every remediation step, perform the following checks before declaring the system ready:

1. Persistent setting test: Reboot three times. After each boot, open dcomcnfg and confirm the checkbox is still set. A failure on the second reboot indicates that a Group Policy or AV hardening cycle is still active.
2. WinCC activation test: Start WinCC Explorer, activate the runtime, monitor CCEServer.log in the project directory for 10 minutes. No DCOM or OPC errors should be logged.
3. OPC connectivity test: Use the OPC Scout (V7) or the OPC UA client in TIA Portal to connect to the local WinCC OPC server. A successful read of a configured tag proves the full DCOM stack is functional.
4. Event log scan: eventvwr > System. No DCOM error 10016 (application-specific permission settings) should appear. Any 10016 entries for WinCC AppIDs indicate that the Security Controller's Repeat settings run was incomplete.
5. Service health: sc query CCAgent, sc query CCEServer, sc query S7IEFOx, sc query OPCEnum – all must report STATE = 4 (RUNNING).
6. Wireless coexistence test: If a Wi-Fi link exists, ping the panel for 5 minutes after activation. No packet loss above 0.1% should be observed.

Troubleshooting Matrix

Preventive Hardening for Production Deployments

To make the configuration survive the full lifecycle of the panel PC, apply the following baseline during commissioning:

• Create a scheduled task named Siemens DCOM Hardening Reset running as SYSTEM, triggered at startup, executing Dcomenable.exe /enable /silent. Enable the Run task as soon as possible after a scheduled start is missed option.
• Document the install media build number, the Windows build, the AV product and version, and the WinCC build in the plant asset register. Changes to any of these three numbers require a re-validation of the DCOM configuration.
• Where possible, migrate OPC DA / HDA traffic to OPC UA. WinCC V7.4 and later, and TIA WinCC Professional V16 and later, support OPC UA without DCOM.
• Disable SMBv1 and harden the RPC key set (TLS 1.2, NTLMv2) – some old AV products that inject into the DCOM launch surface will misbehave on a hardened Windows image.

FAQ