Resolving STEP 7 MicroWIN Install Stuck at 90% on Windows XP VM

Resolving STEP 7 MicroWIN V4.0 SP8/SP9 Installation Stuck at 90% on Windows XP SP3 Virtual Machines

1. Problem Statement

STEP 7 MicroWIN is the legacy programming environment for the SIMATIC S7-200 family of micro-PLCs. Although Siemens formally retired the S7-200 in favor of the S7-200 SMART and the S7-1200 lines, a large installed base still requires MicroWIN V4.0 SP8 or SP9 for service, firmware updates, and migration of existing projects. Engineers maintaining older S7-200 CPUs (CPU 212, 214, 215, 216, 221, 222, 224, 224XP, 226) routinely need to keep a working MicroWIN environment available, frequently inside a Windows XP SP3 virtual machine for two reasons:

1. Driver compatibility: The PC/PPI cable (USB or RS-232) drivers and the CP 5611 / CP 5512 MPI adapters shipped with MicroWIN V4.0 are signed and tested for Windows XP. Modern Windows releases often require manual driver signing, compatibility-mode flags, or replacement by NETLINK USB drivers.
2. Project archival: Long-lived S7-200 projects contain proprietary .mwp project files and TP177 / TD200 / TD400C text-display configurations that open reliably only on the original toolchain.

The failure mode is consistent and reproducible:

2. Root Cause Analysis

When the MicroWIN installer reaches the device-driver stage, it spawns three subordinate Windows services whose executables are unpacked into %TEMP% and then registered as auto-start services. The drivers in question are part of the S7-Online interface and the S7 trace/logging subsystem that MicroWIN shares with STEP 7 V5.x:

Inside a VMware virtual NIC, the WinPcap/NPF Ethernet hook used by s7epatsx.exe is initialized against a virtual AMD PCnet or VMXnet3 adapter. The init call requests promiscuous-mode packet reception; on a physical NIC this call completes in tens of milliseconds. On a VMware Workstation NAT or bridged VMXnet3 adapter, the call enters a non-cancellable wait inside npf.sys (the WinPcap kernel driver shipped in MicroWIN's redistributable) when the underlying virtual switch has not yet bound a port with a learned MAC address. The installer process then blocks on WaitForSingleObject indefinitely, producing the 90% hang with no error dialog.

The root cause is therefore a WinPcap/NPF driver deadlock against the VMware virtual NIC, surfaced indirectly through the s7epatsx.exe and S7TraceServiceX.exe initialization paths. The installer has already registered the services and is waiting for the EPAT initialization IPC to return. Removing only the visible installer is not enough; the three background services must be terminated so the installer's "next-stage" install window can proceed.

3. Pre-Flight Checklist

Before applying the fix, capture the following so the result is reproducible and so the install can be cleaned up if it partially completed:

1. Confirm the VM topology: Record the VMware version, guest OS build (run winver), vCPU count, RAM, and the virtual NIC type (PCnet-PCI II, PCnet-FAST III, VMXnet3, or E1000). The driver behavior above is most common on VMXnet3 and E1000 with NAT networking; bridged mode with PCnet-FAST III occasionally completes without intervention.
2. Take a snapshot: In VMware Workstation choose VM → Snapshot → Take Snapshot. If any step below leaves the registry in an inconsistent state, revert.
3. Clean prior partial installs: Open regedit and delete the following keys if they exist:
   • HKEY_LOCAL_MACHINE\SOFTWARE\Siemens\AUTSW\STEP7 MicroWin
   • HKEY_CURRENT_USER\SOFTWARE\Siemens\AUTSW\STEP7 MicroWin
   • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\S7TraceServiceX
   • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\S7oiehsx
   • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\s7epatsx
   • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\npf
4. Remove residual drivers: In Control Panel → Add or Remove Programs, uninstall any leftover S7-Online, WinPcap, or MicroWIN entries. Manually delete the EXE files in C:\WINDOWS\system32\ if they survive.
5. Disable the Windows Firewall and any third-party AV during the install — MicroWIN's installer opens a Windows Installer service child that some AV engines will quarantine mid-write.

4. Resolution Procedure

The fix is performed while the installer is still running and stalled at 90%. Do not close the installer.

1. Right-click the Windows taskbar and select Task Manager (or press Ctrl+Shift+Esc). Switch to the Processes tab.
2. Locate the three offending processes:
   • S7TraceServiceX.exe
   • S7oiehsx.exe
   • s7epatsx.exe
3. Right-click each process in turn and select End Process Tree. Do not touch the Setup.exe or InstMSI.exe (the parent MicroWIN installer). Do not attempt to End Process Tree on a parent Microsoft Installer process.
4. Observe the installer window. Within a few seconds, a second setup dialog will appear (typically titled Setup is performing a requested operation or InstallShield), and the progress bar will jump from 90% to 100% and complete the install.
5. If the install still stalls after killing only the first two processes, repeat the procedure and additionally kill s7epatsx.exe. This third process is the one most frequently implicated in VMware NPF deadlocks and must be removed in the majority of cases.
6. Click Finish when the installer reports successful completion and reboot the VM.

5. Verification

Confirm a clean, working install with the following checks before connecting to a real S7-200 CPU:

1. Program launch: Open Start → Programs → SIMATIC → STEP 7 MicroWIN V4.0. The IDE should appear within 3 seconds. On a broken install you will see a hang on the splash screen or a missing-DLL error.
2. Communications path check: From the MicroWIN menu, choose Set PG/PC Interface. Verify the following access points are present and bound:
   • PC/PPI cable (PPI) → bound to the USB or COM port
   • CP5611 (MPI) — only if a CP 5611 MPI card is in use
   • TCP/IP → S7ONLINE — for Ethernet-CP243-1/CP243-1 IT modules
3. Live CPU test: Connect a PC/PPI cable to a known-good S7-200 CPU 224XP and click the Communications toolbar button. The CPU type and firmware version should be read in < 5 s. A failure here usually indicates that npf.sys is still missing; reinstall WinPcap 4.1.3 from the MicroWIN redistributable folder.
4. Service persistence check: Run services.msc and verify the three services installed and are set to Manual start (not disabled, not auto-start): S7TraceServiceX, S7oiehsx, and s7epatsx. npf should be set to Manual and started by the S7-Online interface on demand.
5. Project round-trip: Open an existing .mwp file from backup storage. Compile with PLC → Compile (Shift+F9). The build should complete without "Error 33: Out of memory" messages that indicate a corrupted MicroWIN install.

6. Reference VM Configuration

The following configuration is known to install MicroWIN V4.0 SP8/SP9 successfully after the process-kill workaround. Use it as a baseline when the issue recurs on different hosts:

7. Alternate Fix Paths

If the Task Manager workaround fails (rare, but reported when s7epatsx.exe respawns under a service host), try the following in order of preference:

1. Boot-time driver exclusion: From the Recovery Console, edit C:\boot.ini and add /noguiboot /bootlog. Boot, then add the following registry value to disable NPF:

   HKLM\SYSTEM\CurrentControlSet\Services\npf
   Start = REG_DWORD 0x4  (disabled, but installable)

2. Replace VMXnet3 with PCnet-FAST III: Power off the VM, edit .vmx and change ethernet0.virtualDev = "vmxnet3" to ethernet0.virtualDev = "vlance". The legacy PCnet driver does not implement promiscuous-mode the same way, and the NPF deadlock does not occur. After MicroWIN is installed, the NIC type can be reverted to VMXnet3 for normal use; NPF will re-initialize cleanly because the post-install state of the registry is consistent.
3. Install the V4.0 SP7 baseline first: Some legacy SP7 installers (still distributed on the Siemens China support portal at http://www.ad.siemens.com.cn/download/docMessage.aspx?Id=5102) do not ship the EPAT WinPcap layer. Install SP7, reboot, then upgrade to SP8 or SP9 in place. The intermediate state of the registry avoids the deadlock-triggering race condition.
4. Pre-install WinPcap 4.1.3 manually: Download the WinPcap 4.1.3 installer from the official WinPcap project page (https://www.winpcap.org/install/default.htm), run it to completion, and reboot. With npf.sys already registered, the MicroWIN installer skips the NPF install stage and the 90% stall does not occur.

8. Error Code / Behavior Matrix

9. Common Pitfalls

• Closing the installer. Closing the installer at the 90% mark leaves a partial registry and a registered but never-started s7epatsx service. Re-running the installer will reproduce the hang with a different process set. Always clean per the checklist in §3 before retry.
• Killing the parent installer process. If you select the wrong row in Task Manager and end setup.exe, the install is rolled back and the next launch of the installer will continue to fail until the registry is cleaned.
• Disabling the npf service permanently. If the NPF service is set to Disabled post-install, MicroWIN can compile and edit offline projects, but any online operation (download, upload, run/stop, status table) will fail with a misleading "Cable not connected" error. Keep it at Manual.
• Snapshotting after the failed install. If the snapshot is taken while the EPAT service is in a half-registered state, every subsequent revert will reproduce the hang. Always revert, clean, and re-attempt from a known-good snapshot taken before the first install attempt.
• Installing on Windows XP SP2. The MicroWIN SP8/SP9 redistributable requires XP SP3 for the kernel signing chain used by npf.sys. On SP2, the install will fail much earlier in the MSI validation step. Update to SP3 or use the SP7 build.

10. Field-Commissioning Notes

For shop-floor engineers standing up a fresh S7-200 service laptop from a virtual template, the following sequence is reproducible and minimizes time-to-online:

1. Build the VM from a known-good Windows XP SP3 template (sysprepped, VMware Tools installed, vCPUs = 2, RAM = 2 GB, NIC = VMXnet3).
2. Apply Windows XP SP3 updates up to and including KB3033929 (April 2014 root-certificate update). Do not install the post-2019 SHA-2 patch chain — XP cannot service SHA-2-signed updates.
3. Disable Windows Firewall and the Security Center alerts.
4. Mount the MicroWIN V4.0 SP9 ISO. Run Setup.exe.
5. At the 90% stall, open Task Manager, end s7epatsx.exe, S7TraceServiceX.exe, and S7oiehsx.exe in that order.
6. Click Finish, reboot, attach the PC/PPI cable, and run Communications → Set PG/PC Interface → Test.
7. Once online, immediately back up the working VM as a clean image and lock it against further writes — use Independent – Non-persistent mode and snapshot after each programming session.

11. Summary

The 90% stall of STEP 7 MicroWIN V4.0 SP8/SP9 on Windows XP SP3 VMware VMs is a WinPcap/NPF deadlock inside s7epatsx.exe, surfaced through the S7-Online trace and OLE handler services. Killing the three processes S7TraceServiceX.exe, S7oiehsx.exe, and (in the majority of cases) s7epatsx.exe in Task Manager releases the wait and lets the installer complete. For repeatability, the fix should be paired with a clean pre-install (registry + driver cleanup) and a post-install verification of the npf service state and the Set PG/PC Interface bindings. In persistent cases, switch the virtual NIC to PCnet-FAST III, pre-install WinPcap 4.1.3 manually, or fall back to the SP7 baseline before upgrading in place.

12. Frequently Asked Questions