Fix TIA Portal V14 SP1 "No Accessible Devices" on Windows 10 1703 (.NET 4.7 Conflict)

Problem Overview

After upgrading a host PC to Windows 10 version 1703 (Creators Update, OS build 15063.x), engineers running TIA Portal V14 SP1 Update 6 inside a VMware Workstation 10 or 15 virtual machine with a Windows 7 64-bit guest and .NET Framework 4.7 installed experience a complete loss of PROFINET device discovery. The "Accessible devices" and "Found devices" dialogs return an empty result, even though:

• The PLC and HMI IP addresses respond to ping from both the host and the guest.
• Network adapters are bridged and replicated between host and VM.
• The same project on a peer workstation still discovers all nodes normally.

The root cause is a binary incompatibility introduced when Windows 10 1703 ships .NET Framework 4.7 as an in-box component. TIA Portal V14 SP1 was tested against .NET 4.6.2; the 4.7 runtime alters WCF, network discovery, and assembly probing behavior in ways that prevent the S7ONLINE access point and the PROFINET discovery service from enumerating nodes correctly.

Affected Configurations

Root Cause Analysis

Siemens documents this exact incompatibility matrix in their official Windows/WinCC compatibility note. The behavior is reproducible when three conditions are simultaneously true:

1. The Windows 10 host carries the Creators Update (build 15063) with the in-box .NET 4.7 runtime.
2. TIA Portal V14 SP1 attempts PROFINET device discovery (DCP multicast / LLDP / S7 routing).
3. The discovery service traverses a VMware bridged virtual NIC.

The .NET 4.7 runtime changes default transport behavior in System.ServiceModel.Channels and modifies how the CLR probes for native dependencies. TIA Portal V14 SP1's S7DOShelp.dll and SIMATIC hardware support packages rely on legacy TLS/SSL handshake patterns and on a specific Winsock catalog ordering that .NET 4.7 does not preserve. The result: the discovery service starts, sends DCP multicast frames, but the response handler fails silently, returning "No accessible devices".

The official Siemens statement is available at the Siemens support article 109749283 - Incompatibilities between Windows and WinCC (TIA Portal).

Why One Workstation Worked and the Other Did Not

In the reported case, the peer computer carried both .NET 4.6.2 and the in-box 4.7 runtime side-by-side, while the problem host had only 4.7. The presence of 4.6.2 lets TIA Portal's executable binding redirect resolve to the older runtime, which preserves the legacy Winsock catalog order. A host with 4.7 only has no fallback, and the discovery service fails. Microsoft does not permit uninstalling 4.7 once 1703 is installed, so the only supported recovery is OS-level restoration.

Diagnostic Procedure

Before applying the rollback, confirm the diagnosis with the following field-proven checks:

Step 1: Verify the .NET Runtime Inventory

Open an elevated PowerShell on the host:

Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP' -Recurse |
  Get-ItemProperty -Name Version,Release -ErrorAction SilentlyContinue |
  Where-Object { $_.PSChildName -match '^(?!S)\p{L}' } |
  Select-Object PSChildName, Version, Release | Format-Table -AutoSize

Expected output on a 1703 host:

PSChildName      Version    Release
-----------      -------    ------
v2.0.50727       2.0.50727  0
v3.0             3.0.4506   0
v3.5             3.5.21022  0
v4\Client        4.7.02053  460798
v4\Full          4.7.02053  460798

If v4\Full shows 4.7.x and you cannot see a 4.6.2 entry, the host is in the affected state.

Step 2: Verify PROFINET Reachability from the Guest VM

From inside the VMware Windows 7 guest:

ping -n 4 <PLC_IP>
ping -n 4 <HMI_IP>
arp -a

If ping succeeds but TIA Portal still reports "No accessible devices", the network path is intact and the failure is at the discovery/application layer.

Step 3: Capture a PROFINET Discovery Trace

Enable TIA Portal logging before re-running discovery:

1. Close TIA Portal.
2. Open C:\Program Files\Siemens\Automation\Portal V14\Data\Logger.config.
3. Set level="DEBUG" for namespace Siemens.Automation.Portal.FrameWork.Hwcn.
4. Restart Portal, reproduce the scan, then inspect %LOCALAPPDATA%\Siemens\AutomationLog\<timestamp>\Siemens.Automation.Portal.exe.log.

Look for entries containing S7DOS, DCP_IDENTIFY, or no accessible nodes within the first 800 ms after scan start.

VMware Network Adapter Configuration

Bridged adapter behavior is a known contributor. Apply the following settings even before the OS rollback to rule out a parallel fault:

1. In VMware Workstation, choose VM > Settings > Network Adapter.
2. Set Network connection to Bridged and tick Replicate physical network connection state.
3. From the host Device Manager, disable and re-enable the physical NIC to flush stale bindings.
4. Inside the guest, run ipconfig /release && ipconfig /renew.
5. Reboot the guest, then re-launch TIA Portal.

If discovery still fails, assign the VM a dedicated USB-to-Ethernet adapter (e.g. Realtek RTL8153 based dongles) and configure VMware to Connect directly to the physical network on that adapter only. This isolates control-network traffic from corporate VPN/management VLANs and removes any bridged-NIC edge case.

Workarounds and Solutions

Solution A (Authoritative): Restore Windows 10 to OS Build 15063.483

The reproducer's working configuration after recovery:

• Windows 10 version 1703, OS build 15063.483.
• .NET Framework 4.7 (in-box, retained).
• VMware Workstation 10 (peer) / 15 (host) with updated tools.
• TIA Portal V14 SP1 Update 6, fully functional.

Procedure:

1. Open Settings > Update & Security > Recovery.
2. Select Go back to the previous version of Windows 10.
3. Confirm and wait for the rollback to complete (typical duration 20-40 minutes).
4. After rollback, block the Creators Update by setting the registry key:

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v TargetReleaseVersion /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v TargetReleaseVersionInfo /t REG_SZ /d "1703" /f

Reboot and verify build with winver. The reported working build is 15063.483; do not advance past this build until Siemens releases a V14 SP1 update that explicitly certifies .NET 4.7 compatibility.

Solution B: Upgrade TIA Portal

If a rollback is operationally unacceptable (loss of recently installed corporate software, certificates, or VPN profiles), upgrade TIA Portal to a release that explicitly supports .NET 4.7. The compatibility threshold is:

Verify the target version's readme via the TIA Portal V14 SP1 installation readme reference entry, then cross-check on the Siemens Online Support portal.

Solution C: Add a Dedicated USB Ethernet Adapter

Use a USB-to-Ethernet adapter exclusively captured by the VM. This isolates TIA Portal traffic from the host's primary NIC (which carries the failing .NET 4.7 stack) and removes the bridged-NIC ambiguity. Recommended adapters:

• AnyRTL8153/RTL8152 chipset based USB 3.0 GbE dongle.
• Intel I210 / I211 based USB-C adapters for S7-1500 and ET200SP environments that require high PROFINET frame rates.

Assign the adapter a static IP in the same subnet as the PLC/HMI, set VMware to Connect directly to the physical network, and disable the bridged primary NIC inside the VM configuration.

Step-by-Step Recovery Procedure

1. Snapshot the VM. Shut down the Windows 7 guest and create a VMware snapshot named pre-rollback.
2. Export the TIA Portal project. File > Archive > Project, save the .zap14 archive to a network share.
3. Capture installed licenses. Run Siemens Automation License Manager and back up the License Key archive (.zip) to external media.
4. Document the host state. Run winver, systeminfo, and Get-NetAdapter from PowerShell, save outputs.
5. Roll back the host. Settings > Recovery > Go back to Windows 10 1703 build 15063.x.
6. Block the Creators Update. Apply the registry keys shown in Solution A.
7. Verify build. Confirm winver reports build 15063.483.
8. Re-bridge the VM NIC. Re-enable bridged mode, restore static IP, ping PLC/HMI.
9. Reinstall VMware Tools. Match the version to VMware Workstation 15 (latest 15.5.x).
10. Repair TIA Portal. Control Panel > Programs > Siemens TIA Portal V14 SP1 > Repair.
11. Restore the project. Open the .zap14 archive in TIA Portal.
12. Run discovery. Online > Accessible devices. Expected result: PLC and HMI appear within 5-8 seconds.

Verification Checklist

Preventive Measures

• Pin the OS build using TargetReleaseVersionInfo=1703 registry key or Group Policy to prevent silent feature upgrades from breaking the TIA Portal runtime.
• Maintain a VMware snapshot of every engineering workstation before applying Windows or VMware updates.
• Subscribe to Siemens Product Safety and Security Advisories at support.industry.siemens.com and review the Incompatibilities between Windows and WinCC (TIA Portal) article (109749283) quarterly.
• Maintain a dedicated control-network VLAN with no host bridging to corporate networks.
• Document the active Windows build number in the maintenance log so any future regression can be correlated with an OS change.

Alternative Discovery Methods

If a rollback is not immediately possible, the following methods bypass the broken in-VM discovery:

1. PRONETA: Siemens' free PROFINET analysis tool (PRONETA.exe) uses raw Ethernet LLDP/DCP and does not depend on the .NET 4.7 stack. It can enumerate devices even when TIA Portal cannot.
2. Primary Setup Tool: For older S7-300/400 and ET200 stations, the legacy Primary Setup Tool (PST) performs discovery via its own Winsock path.
3. Wireshark PROFINET filter: Apply dcp filter on the bridged NIC capture to confirm that the host is sending DCP identify requests and whether the PLC is replying. This isolates whether the fault is transmit-side or receive-side.
4. Direct S7 routing through SINEC NCM: Configure a known station manually using its IP and rack/slot, then attempt a download. Successful download confirms routing works and isolates the failure to discovery only.

Related Siemens Resources

Engineers should cross-reference the official Siemens documentation set when planning a recovery:

• 109749283 - Incompatibilities between Windows and WinCC (TIA Portal)
• TIA Portal V14 SP1 installation readme (system requirements)
• Siemens Industry Online Support portal

FAQ