Resolving WinCC Unified V19 Trace 0x8006e010 IPv6 Parsing Errors

Problem Summary

WinCC Unified V19 PC Runtime installations running build V19.0.0.2 emit a continuous stream of trace entries every two seconds from the graphic runtime subsystem. The Trace Viewer records two related errors: an IPv6 loopback address is being submitted to a parser that expects IPv4 dot-decimal notation, and the PHMI service layer reports an inconsistent configuration using hex code 0x8006E010. In addition to cluttering the trace log, the runtime interface periodically restarts because the underlying service flags a "no connection to server" condition. This article documents the symptom, isolates the root cause, prescribes the corrective update path, defines the verification steps that prove the fix is in place, and supplies workarounds for stations that cannot be updated immediately.

Observed Error Text and Frequency

Each polling cycle the Trace Viewer appends two entries with identical timestamps and location stamps. The exact strings logged are:

The location metadata for both lines is consistent across the project and across HMI stations that share the same compiled runtime image:

The 0x8006E010 HRESULT belongs to the PHMI range. The 0x8006 facility code is FACILITY_WIN32 (user-mode runtime components) and the lower 16 bits 0xE010 map to the symbolic name PHMI_E_INCONSISTENT_CONFIG. Tools that translate HRESULT values render 0x8006E010 as "Inconsistent configuration (PHMI/General)" rather than a generic Win32 system error. The symbolic name is not exposed to the trace text; only the hex literal and the human-readable message appear.

The "::1" literal in both messages is the IPv6 loopback address (RFC 4291, Section 2.5.3.2). It is the IPv6 equivalent of 127.0.0.1. The error indicates that a configuration parameter that the parser expects in IPv4 dotted form is being supplied with an IPv6 string, and the parser refuses the input. Because the same loopback value is used by the in-process HMI server health check, the failure repeats on every poll.

Affected Versions and Components

The reported defect is reproducible on WinCC Unified PC Runtime V19.0.0.2 and was first observed in installations derived from TIA Portal V19 Update 1 and Update 2 media. The defect is not present in WinCC Unified V17 SP3 or V18 SP1 builds, and Siemens corrected the parser logic in the consolidated V19 update rollup published on the Siemens Industry Online Support portal.

Only PC Runtime on Windows is impacted. Comfort Panel and RT Advanced variants do not ship the affected parser code. Confirm the active build with the About dialog of the WinCC Unified Configuration or read the version stamp from the WCCILrt.exe file properties under the installation path C:\Program Files\Siemens\Automation\WinCCUnified\Bin\.

Root Cause Analysis

The graphic runtime component GfxRTS(22) hosts the ServiceBL module of the PHMI subsystem. When the runtime initializes, ServiceBL walks the project's HMI connection table and resolves each connection endpoint into a transport address string. On Windows systems with IPv6 enabled (the default on Windows 10 1903 and later, and on Windows 11), the resolver for "localhost" returns "::1" before "127.0.0.1" when the application uses getaddrinfo with the AF_UNSPEC hint.

The PHMI parser, however, is hard-coded to expect IPv4 dot-decimal strings. The validation routine emits the message "IP address '::1' must be provided with '4' numbers separated by a '.'", and the caller in ServiceBL maps the validation failure to PHMI_E_INCONSISTENT_CONFIG (0x8006E010). The failed parse is then re-raised to the trace layer as "Failed to parse IP range '::1'".

Why the 2-second interval? The HMI runtime schedules a health-check job in ServiceBL with a 2,000 ms period. Each tick re-evaluates the loopback address used for the in-process HMI server, hits the same parser, fails, logs, and re-tries. Disabling scheduled tasks visible in the engineering interface does not stop the loop because the health check is internal to the runtime service, not user-configured.

Why does the MyWinCC Unified interface restart? When the health check fails repeatedly, the connection manager raises "no connection to server" and the umbrella service bounces the affected HMI connection. In multi-station or large-screen configurations this manifests as the interface cycling every few seconds, which is what users observe in addition to the trace noise. The cycle length depends on the timeout setting of the connection manager; the default is 5,000 ms for a service-level restart, which roughly matches the observed behaviour.

Loopback Resolution Order on Windows

Understanding why the resolver returns "::1" is the key to a permanent fix. The Windows DNS resolver follows a defined order for "localhost":

1. Check the Hosts file at C:\Windows\System32\drivers\etc\hosts. If an entry exists, it is used verbatim.
2. If the Hosts file is silent, query the DNS resolver service for the AAAA record of "localhost". On modern Windows, this returns "::1".
3. If the AAAA query is refused or returns no record, query the A record. The Windows stub resolver returns "127.0.0.1".
4. If both records are present, the order returned to the caller depends on the address family hint. AF_UNSPEC returns the IPv6 record first; AF_INET returns the IPv4 record only.

The PHMI parser calls the resolver with the default hint (AF_UNSPEC) and therefore receives "::1" first. The fix in the V19 update rollup changes the hint to AF_INET for loopback resolutions and adds a normalization step that maps the IPv6 loopback to 127.0.0.1 when the hint cannot be honoured. This is a parser-side change and does not alter global Windows resolver behaviour.

ServiceBL Module Architecture

ServiceBL is the Service Business Logic layer of the PHMI subsystem. It sits between the connection manager and the transport adapters and is responsible for endpoint validation, transport negotiation, and health-check scheduling. The relevant call path during a loopback resolution is:

1. Connection manager requests a transport endpoint for the in-process HMI server.
2. ServiceBL resolves the local hostname and produces a candidate address string.
3. ServiceBL submits the candidate to the PHMI parser for validation.
4. The parser returns either OK or PHMI_E_INCONSISTENT_CONFIG.
5. On failure, ServiceBL schedules a retry in 2,000 ms and logs the trace entry.

The retry is bounded by a configurable maximum (default 600 s) but is not bounded in count. The retry continues until the parser accepts the input, which in turn happens only when the resolver returns an IPv4 address. The V19 update short-circuits the retry by handling the IPv6 case inside the parser.

Hex Code Decoding and HRESULT Layout

0x8006E010 follows the standard HRESULT layout: the high bit indicates failure (1), bits 16-26 encode the facility code, and bits 0-15 encode the error value. Breaking 0x8006E010 into its components yields:

The facility code 6 (FACILITY_WIN32) is a catch-all for user-mode runtime components that do not have a dedicated facility. The PHMI subsystem reuses this facility because the underlying COM layer is generic. The lower 16 bits 0xE010 are the value that distinguishes PHMI_E_INCONSISTENT_CONFIG from other PHMI errors such as 0xE001 (PHMI_E_NOT_INITIALIZED) or 0xE020 (PHMI_E_TIMEOUT). When a future PHMI error needs to be identified, look up the lower 16 bits in the PHMI header file that ships with the WinCC Unified SDK.

Diagnostic Procedure

Follow this sequence on the affected PC Runtime station to confirm the diagnosis before applying the update.

1. Open WinCC Unified Trace Viewer. If Trace Viewer is not pinned, launch it from the Start menu or from the TIA Portal under Tools > WinCC Unified Trace Viewer. The viewer runs independently of TIA Portal but can be opened from it as an external tool; see the canonical procedure in the Siemens Industry Online Support document 109777593 - Using Trace Viewer with WinCC Unified.
2. Apply a filter for Subsystem == PHMI and Application == GfxRTS. Count the entries over a 30-second window.
3. Verify that the count is 15 plus or minus 2 entries. A count of 15 confirms a 2-second period.
4. Right-click one of the 0x8006E010 entries and select Show context. Confirm that the application is GfxRTS(22), the subsystem is PHMI, and the module is ServiceBL.
5. Open an elevated command prompt and run nslookup localhost. Confirm that the response contains a record with ::1 (AAAA) before any 127.0.0.1 (A) record. If the AAAA record is listed first, the loopback resolver is IPv6-first and the runtime parser will fail.
6. Check the Hosts file at C:\Windows\System32\drivers\etc\hosts. Confirm whether any line maps localhost to a non-default address. Default Windows content has only the commented "localhost name resolution" line, so an absence of an explicit entry is normal and contributes to the IPv6-first resolution.
7. Inspect the HMI connection table in TIA Portal under HMI tags > Connections. Confirm whether any connection is configured to "localhost" or to the empty hostname. Although the HMI tag itself rarely points to localhost, the internal health-check connection in ServiceBL always uses the local loopback.

If the trace count is approximately 15 over 30 s, the IPv6 loopback is present, and the location metadata matches the table above, the diagnosis is confirmed and the corrective action below applies.

Resolution: Apply the V19 Update

Siemens has published a consolidated update for SIMATIC WinCC Unified PC Runtime V19 that corrects the PHMI parser. Install the latest V19 update rollup on every PC Runtime station that exhibits the symptom. The update is delivered as a self-extracting installer that updates the runtime binaries in place and preserves the existing project configuration.

1. Close the WinCC Unified Runtime on the target station. Use the system tray icon or the Stop Runtime entry in the WinCC Unified Configuration tool.
2. Stop the WinCC Unified service: open services.msc, locate Siemens WinCC Unified Runtime, and stop it. Also stop the auxiliary SIMATIC WinCC Unified Collaboration service if it is running. The collaboration service participates in the HMI server handshake and must be down before the DLLs are replaced.
3. Download the latest "Updates for SIMATIC WinCC Unified PC Runtime V19" package from the Siemens Industry Online Support portal. Locate the entry under the product tree for SIMATIC WinCC Unified V19. Verify the live link on the Siemens Support page before downloading, as entry identifiers are revised when new rollups are released.
4. Run the downloaded executable with administrative privileges. Accept the license agreement. The installer pauses the HMI runtime services automatically; no manual stop is required if the installer version is dated 2024 or later. Earlier installers may require the user to stop the services before installation begins.
5. Reboot the station. The installer does not always require a reboot for the parser change, but the runtime services do not pick up the new DLL until the host process is restarted. A full host reboot is the most reliable way to guarantee that the in-process state is rebuilt.
6. Start the runtime and confirm the build number in the About dialog. The build number should be V19.0.0.3 or later. If the build number is unchanged, the installer did not run with administrative privileges and the binaries on disk are the same as before the install attempt.

Verification Steps

After the update and reboot, run the following verification sequence to confirm the trace is silent.

1. Open Trace Viewer and apply the same filter that was used for diagnosis (Subsystem == PHMI).
2. Start a 60-second observation window. Use a stopwatch or a system clock so the measurement is independent of the trace timestamps.
3. Confirm that zero entries are written that match ::1 or that contain the hex code 0x8006E010.
4. Confirm that the MyWinCC Unified interface no longer cycles. The interface should remain stable for the full observation window.
5. Open the project in the TIA Portal on the engineering station and re-compile the runtime. Although the parser fix does not require re-compilation, a full re-compile produces a known-good image for future deployments and validates that the project is compatible with the new build.
6. Capture a screenshot of the empty PHMI filter view and attach it to the change record for the station. Save the Trace Viewer export as a .csv file alongside the screenshot so the change record is self-contained.

If entries continue to appear, run the diagnostic procedure again. If the loopback resolver is now IPv4-first but the trace persists, raise a Siemens support request with the Trace Viewer export, the project archive, the build number from step 6 of the resolution procedure, and the version of Windows installed on the station.

Alternative Workarounds (Pre-Update Mitigation)

If a station cannot be updated immediately, two pre-update mitigations are available. Apply one or both only as a temporary measure; the V19 update is the supported resolution.

Disable IPv6 on the loopback adapter

1. Open ncpa.cpl and right-click the active network adapter.
2. Open Properties and clear the check box for Internet Protocol Version 6 (TCP/IPv6).
3. Reboot the station.
4. Confirm with nslookup localhost that only the A record for 127.0.0.1 is returned.

This change makes the resolver IPv4-first and the parser no longer receives "::1". The trade-off is that the station can no longer reach IPv6-only devices on the plant network. Apply this workaround only on isolated engineering stations, not on production HMI panels that must reach IPv6 infrastructure.

Force IPv4 in the hosts file

1. Edit C:\Windows\System32\drivers\etc\hosts with administrative rights.
2. Insert the line 127.0.0.1 localhost above any existing entry.
3. Save the file. Flush the resolver cache with ipconfig /flushdns.
4. Reboot the runtime services (not necessarily the host).

The hosts file entry takes precedence over the resolver and forces localhost to 127.0.0.1. This is the least invasive workaround and does not disable IPv6 on the station. The trade-off is that any application that resolves "localhost" expecting "::1" will now receive "127.0.0.1" instead, which is normally desirable for WinCC Unified but may affect third-party tools that are coded against the IPv6 loopback.

Switch the resolver family hint at the application level

For stations running custom HMI scripts that call the PHMI parser directly, the resolver hint can be set in the script. Wrap the resolver call in a conditional that supplies AF_INET instead of AF_UNSPEC. The change is local to the script and does not require a reboot. The trade-off is that every script on the station must be reviewed and patched, which is impractical in large fleets. Prefer the V19 update or the hosts-file workaround for fleet-wide mitigation.

Trace Viewer Filter Configuration

Engineers triaging the symptom in a multi-station environment should set up named filters to isolate the PHMI subsystem quickly. The Trace Viewer is a separate application that runs independently of TIA Portal but can be opened from TIA Portal as an external tool. Reference the Siemens Industry Online Support document 109777593 - Using Trace Viewer with WinCC Unified for the canonical procedure.

Filters persist per user profile under %AppData%\Siemens\WinCCUnified\TraceViewer\filters.xml. Copy the file to a shared location to distribute the filter set to other engineering workstations. Group Policy preferences can place the file at the per-user path on logon so every workstation reports the same filtered view.

For Industrial Edge deployments that forward traces from WinCC Unified, navigate to Configuration > Tracing > Forwarding in the Industrial Operations X documentation set to enable trace forwarding to a central collector. The canonical path is described in the Trace Viewer - SIMATIC WinCC Unified Runtime page.

For V20 and later, the dedicated RTIL Trace Viewer (RT Unified) supersedes the V19 trace viewer and provides a richer filter expression language. Engineers planning a V20 migration can preview the new filter syntax on a non-production station to prepare migration scripts.

Log Analysis Methodology

The trace log is the primary source of evidence for this defect. Apply the following methodology to read it efficiently:

1. Open the Trace Viewer and export the active filter view to .csv. The export includes the timestamp, severity, application, subsystem, module, hex code, and message columns.
2. Group the export by the Message column and count occurrences. The two defect messages should account for 30 entries per minute on a station running the 2-second loop.
3. Compute the inter-arrival time delta for consecutive entries with the same Message. The median delta should be 2,000 ms. A bimodal distribution suggests that another subsystem is also emitting the same string, in which case the diagnosis is not isolated to ServiceBL.
4. Cross-reference the timestamp with the connection manager log. A "no connection to server" entry should appear within 5 seconds of every burst of PHMI errors. The lag indicates the connection manager timeout setting.
5. Save the export and the analysis as part of the change record. The artefacts support a future regression check and provide a baseline for other stations on the same project.

Project-Level Mitigations in TIA Portal

For stations that cannot be updated immediately and that host custom HMI projects, a project-level mitigation is available. Edit the HMI connection table so that the in-process server connection points to the explicit IPv4 address 127.0.0.1 instead of relying on the resolver. The change is project-local and does not require a host reboot.

1. Open the project in TIA Portal V19.
2. Navigate to HMI tags > Connections.
3. Locate the connection used by the in-process HMI server. If the connection is configured with the hostname "localhost" or left blank, edit the address field to 127.0.0.1.
4. Compile the project and download the new runtime image to the station.
5. Restart the runtime and observe the trace for 60 seconds.

This mitigation works because the explicit IPv4 address bypasses the resolver. The PHMI parser receives a valid IPv4 string and does not raise PHMI_E_INCONSISTENT_CONFIG. The mitigation is local to the project and does not affect other connections in the same project. It is a stop-gap until the V19 update is applied.

Prevention and Maintenance

Adopt the following habits to keep the symptom from recurring and to shorten mean time to repair on similar trace issues.

• Subscribe to the Siemens Industry Online Support notification service for the entry "SIMATIC WinCC Unified PC Runtime V19". New updates are published under the same family identifier and the notification service emails a digest on release. The subscription is free and is the most reliable way to learn about future V19 rollups.
• Run the latest V19 update rollup in a test cell for at least 72 hours before rolling it into production. The 2-second period of the original symptom means a 30-minute observation is sufficient to confirm the fix, but extended operation is needed to catch interaction effects with custom HMI scripts and third-party OPC clients.
• Include the Trace Viewer filter set in the engineering workstation image. Distribute filters.xml via Group Policy or a configuration management tool so every workstation reports the same filtered view. Standardize the filter names so engineers across sites share a common diagnostic vocabulary.
• Capture a baseline of expected trace volume for every production station during commissioning. A drift from baseline is the earliest signal that an update has changed parser behaviour. Store the baseline alongside the project archive so the comparison is repeatable.
• Avoid configuring HMI connections to "localhost" by name. Always use the explicit IP address 127.0.0.1 in the connection table. Explicit addresses are not subject to the resolver order and are immune to the IPv6-first behaviour that triggers this defect. Review the project for any hostname that resolves to a loopback and replace it with the explicit address.
• Document the hex codes for known PHMI errors in the plant's HMI support runbook. The next PHMI error to surface will be triaged faster if the lower 16 bits are already mapped to symbolic names.

Troubleshooting Matrix

FAQ