Fix SIMATIC PC Adapter USB Driver Errors on Windows 7 64-bit

Problem Overview

Engineers maintaining legacy S7-400 fleets reach for the SIMATIC PC Adapter USB when an Ethernet port on the CPU is not available, is blocked by a firewall, or is simply not yet commissioned. On a Windows 7 64-bit SP1 workstation running STEP 7 V5.5 (referred to as "Simatic basic 5.5" in the original fault report) and WinCC flexible 2008, the adapter typically enumerates cleanly in Device Manager while the PLC is idle. The moment an online function is launched — Accessible Nodes, project download, block upload, Monitor/Modify, or a WinCC tag poll — Device Manager marks the same node with a yellow exclamation mark and the MPI/PROFIBUS session either hangs or drops immediately. Reinstalling the supplied PC Adapter USB driver does not resolve the issue, because the failure is rarely a missing driver file. It is how Windows 7 x64 enumerates, powers, and assigns resources to the adapter once the Siemens protocol stack attaches to it.

This article walks through the field-proven recovery procedure published in Siemens Knowledge Base entry 109476315, then layers in the four secondary root causes (IRQ conflict, non-original hardware, USB cable integrity, USB power management) that the KB notes must be ruled out before the driver update is considered. The procedure applies equally to STEP 5 V5.5, STEP 7 V5.5, WinCC flexible 2008, and any TIA Portal install that overwrote the legacy driver.

Affected Hardware and Software Stack

STEP / TIA / WinCC Compatibility Matrix

Install order matters. If STEP 7 V5.5 was installed first and TIA Portal was added later, the TIA INF may have replaced the legacy INF and triggered exactly the fault described in the original report. The reverse order (TIA Portal first, STEP 7 V5.5 second) usually works because STEP 7 V5.5 is permissive about pre-existing INF packages. In mixed installs, install STEP 7 V5.5 → WinCC flexible 2008 → TIA Portal, and never re-run the TIA "PC Adapter USB driver update" afterwards.

PC Adapter USB Architecture and Protocol Stack

The PC Adapter USB is a two-bridge device. On the PC side it exposes a USB 2.0 high-speed HID class endpoint plus a virtual COM port. On the field side it drives the MPI/PROFIBUS-DP physical layer at 1.5 Mbit/s, 12 Mbit/s, 45.45 kbit/s, or 187.5 kbit/s depending on the network profile detected at startup. The data path through the stack is:

1. STEP 7 V5.5 / WinCC flexible 2008 user-mode application
2. S7 communications DLLs: s7otbxdx.dll (S7Online), s7wnasmx.dll (S7 WAN), wssock32.dll (WinCC flexible transport)
3. USB device driver: s7usbpcadapter.sys (Siemens-signed, Windows 7 x64 compatible)
4. USB hub driver: usbhub.sys (Microsoft in-box driver)
5. USB host controller driver: usbehci.sys (USB 2.0 EHCI) or usbxhci.sys (USB 3.0 xHCI)
6. PC Adapter USB hardware (FTDI-based controller + RS-485 MPI/PROFIBUS transceiver)
7. S7-400 MPI or PROFIBUS-DP interface

Windows 7 x64 driver-signing enforcement means every layer from step 3 down must be signed by a trusted publisher. Siemens signs s7usbpcadapter.sys with a VeriSign / Symantec code-signing certificate; a clone adapter that ships an unsigned or third-party-signed INF is rejected by ci.dll and surfaces as Code 52 in Device Manager. The Windows 7 kernel enforces this signature check at DriverEntry time, before any user-mode application can open the device handle, which is why a wrong-driver install manifests as the entire adapter vanishing the moment STEP 7 tries to attach.

Symptoms Reported in Device Manager

The yellow exclamation mark that appears over the SIMATIC PC Adapter USB node during active data transfer maps to one of the standard Windows Device Manager error codes. Capture the exact code and "Device status" text before you begin recovery — the code drives which branch of the procedure you take.

Right-click the flagged node, choose Properties → General, and copy the exact code and status text into the service ticket. If the status text contains STATUS_DEVICE_POWER_FAILURE or STATUS_NOT_SUPPORTED, jump directly to the USB power section — the driver is fine and re-installing it will not help.

Root Cause Analysis

Five failure modes are documented in this Windows 7 x64 pattern. Treat them in the order listed — Siemens KB 109476315 assumes the first two are already eliminated before the driver update is attempted.

1. Driver installation order / version mismatch. STEP 7 V5.5, STEP 5 V5.5, WinCC flexible 2008, and TIA Portal each ship their own PC Adapter USB INF package. Installing TIA Portal after STEP 7 V5.5 can overwrite the legacy driver with a build that expects a different hardware revision (PC Adapter USB A2 vs. the older A1). The legacy STEP 7 V5.5 application then attaches to an INF that no longer matches the device's hardware ID string, and Windows returns Code 28.
2. Non-original PC Adapter. Third-party adapters, frequently labelled "China clone", use a Prolific or FTDI derivative whose x64 driver is either unsigned or does not expose the Siemens hardware IDs USB\VID_0640&PID_0B15 and USB\VID_0640&PID_0B16. They may enumerate once with the Microsoft in-box HID driver and fail as soon as the Siemens protocol stack attempts to claim the interface, because the stack opens the device by hardware ID and the device no longer responds to that ID.
3. IRQ conflict. On Win 7 x64, several USB controllers, the SMBus controller, the HD audio codec, and the NIC often share IRQ 16, 17, or 18. A shared interrupt is normally tolerated, but when the Siemens driver opens the adapter for high-rate MPI polling it can collide with another device's ISR and stall the USB endpoint. The endpoint times out, the USB hub reports a stall, and Windows marks the device Code 43.
4. USB cable integrity. MPI/PROFIBUS-DP work above 1.5 Mbit/s; USB signal-integrity loss beyond 3 m of low-quality cable mimics a power or driver fault. The original Siemens USB cable is shielded and certified; clones are not. The damaged or unshielded cable lets MPI bus noise couple into the USB data pair, which the controller interprets as a CRC error and resets the endpoint.
5. USB power management. Windows 7 enables USB selective suspend by default. When the MPI driver idles for a few hundred milliseconds, the host may suspend the port; the next MPI request fails to wake the port cleanly and Windows marks the device Code 43. Front-panel headers that share a 5 V rail with neighbouring USB ports are especially susceptible because the suspend/resume cycle drops the rail below 4.75 V for one or two milliseconds.

Pre-Diagnostic Checklist

1. Read the PC Adapter USB label and record the MLFB. A Siemens original carries 6ES7972-0CB20-0XA0 on a CE-marked housing. Anything printed only in Chinese without an MLFB number is almost certainly a clone — replace it before continuing.
2. Open Device Manager → Universal Serial Bus controllers and confirm whether the SIMATIC PC Adapter USB node is present at all before connecting the PLC to MPI/PROFIBUS.
3. Launch STEP 7 V5.5, open the project, then PLC → Accessible Nodes while watching Device Manager. Capture the exact Code and "Device status" string the moment the yellow mark appears.
4. Open Device Manager → View → Resources by type → Interrupt request (IRQ) and check whether the SIMATIC PC Adapter USB shares an IRQ with another active USB controller, HD audio, or NIC.
5. Swap the USB cable for the original Siemens A-B shielded cable (≤5 m). Test both a rear-panel USB 2.0 port and a front-panel header.
6. Note whether the PC Adapter has an external 24 V feed. The basic 6ES7972-0CB20-0XA0 is bus-powered and does not need external power; only the A2 service variant carries a 24 V terminal.
7. Run msinfo32 from the Run prompt and export Components → USB and Hardware Resources → IRQs as a reference file.
8. Confirm in Programs and Features the exact order in which STEP 7 V5.5, WinCC flexible 2008, and TIA Portal were installed. A TIA install after STEP 7 V5.5 is the single most common trigger of this fault pattern.

Driver Update Procedure (Siemens KB 109476315)

The Siemens Knowledge Base article 109476315 — How do you update the driver software for the PC Adapter USB if you cannot establish an online connection after installing STEP 7 (TIA Portal)? provides the authoritative recovery sequence for the driver-class failures (Codes 10, 28, 52). The procedure is summarised below; always read the KB entry for the latest pre-conditions before applying the fix on a production workstation.

1. Disconnect the PC Adapter from the USB port.
2. In Control Panel → Programs and Features, uninstall every entry that contains "SIMATIC PC Adapter", "S7DOS", "S7EASY" or "SIMATIC USB PC-Adapter". Do not reboot yet.
3. Open Device Manager → View → Show hidden devices and delete the greyed-out SIMATIC PC Adapter USB nodes from Universal Serial Bus controllers and from Ports (COM & LPT).
4. Open %ProgramFiles%\Siemens\Automation\Simatic_Mgr\drivers (or the equivalent STEP 7 V5.5 / WinCC flexible 2008 install path) and confirm that s7usbpcadapter.inf and the signed .sys driver are present and dated later than the TIA Portal install. Expected file size is in the 60–90 KB range for the INF and 30–45 KB for the SYS.
5. Re-boot. Plug the PC Adapter in only after Windows has finished the desktop build and the USB enumeration animation has settled.
6. Let Windows discover the new device, choose Browse my computer for driver software → Let me pick from a list of device drivers on my computer, and select the STEP 7 V5.5 / WinCC flexible 2008 INF path explicitly. Do not let Windows Update search for a driver.
7. Verify that the node appears as SIMATIC PC Adapter USB without a yellow mark in Device Manager → Universal Serial Bus controllers.
8. Launch STEP 7 V5.5, open PLC → Accessible Nodes and confirm that the S7-400 MPI address (default 2) is reported within 3 seconds. Then trigger an upload or download to reproduce the original fault condition.

If the yellow mark returns only during a heavy transfer, the failure is not driver-related — proceed to the IRQ, cable, and power sections.

IRQ Conflict Resolution

The PC Adapter USB exposes a USB HID endpoint and a virtual COM port. On Windows 7 x64 the host controller driver is usbhub.sys and the device driver is the Siemens-supplied s7usbpcadapter.sys. Both stack on the USB host controller's MSI or line-based IRQ. If another high-traffic device (USB 3.0 xHCI controller on the same PCIe bus, HD audio codec, NIC teaming, Intel MEI) shares the IRQ, the USB endpoint can fail to deliver an MPI response in time, which surfaces as Code 43 during heavy polling.

1. In BIOS/UEFI, set the USB ports the adapter uses to USB 2.0 mode only (disable xHCI hand-off if not needed). xHCI controllers on Win 7 x64 frequently steal IRQs from EHCI when the BIOS hands them off.
2. Disable Bluetooth and any virtual COM ports created by Bluetooth stacks — these frequently claim the same IRQ group as the PC Adapter USB.
3. In Device Manager → USB Root Hub → Power Management, clear Allow the computer to turn off this device to save power for every USB hub on the path to the adapter.
4. In Power Options → Change plan settings → Change advanced power settings → USB settings → USB selective suspend setting, set the value to Disabled.
5. Re-run msinfo32 and confirm the PC Adapter USB sits on an isolated IRQ, or shares with at most one low-traffic device (e.g., the PS/2 keyboard controller). Target IRQs 16, 17, 18, 19 are the most contested on Win 7 x64 workstations; an isolated IRQ 21–23 is the cleanest position.
6. Open an elevated command prompt and run set /a _irqlist=(0x46c) & wmic irqtable get name, irq to enumerate the IRQ sharing table directly.

USB Cable, Port, and Power Verification

The PC Adapter USB upstream is a USB 2.0 high-speed (480 Mbit/s) type-A plug. The MPI/PROFIBUS side runs at 1.5 Mbit/s, 12 Mbit/s, 45.45 kbit/s or 187.5 kbit/s depending on the network profile. MPI/PROFIBUS timing is intolerant of USB re-enumeration; a marginal cable or weak port manifests as Code 43 during the first heavy transfer and then "self-heals" as Windows retries.

• Use only the original Siemens USB cable (yellow or black, 5 m, double-shielded). Lengths above 5 m require an active USB 2.0 hub in-line; passive extensions are not supported.
• Prefer a rear-panel port wired directly to the chipset; avoid front-panel headers and un-powered hubs.
• Plug the cable into the same physical port every time. Windows retains port-specific power policies per hub-port and re-applies selective suspend if you switch ports.
• Check the cable for kinks, crushed sections, and strain near the moulded ferrite. A damaged ferrite removes common-mode rejection and lets noise from the MPI bus couple back into the USB data pair.
• Open Device Manager → USB Root Hub → Power tab and verify the hub supplies the full 500 mA the PC Adapter USB draws under load. A front-panel header that drops below 4.75 V under load is the most common cause of intermittent Code 43 on a Windows 7 x64 workstation.

The basic 6ES7972-0CB20-0XA0 is bus-powered. USB 2.0 delivers 5 V at 500 mA on a high-power port; the adapter draws roughly 100 mA during enumeration and up to 200 mA during active MPI traffic, well within budget. If the PC Adapter is the variant with an external 24 V DC terminal (the PC Adapter USB A2 service pack), connect a clean 24 V supply from the same cabinet feeding the S7-400 PS so the USB section does not brown-out when the S7-400 back-plane is loaded.

To confirm power integrity, open Device Manager → USB Root Hub → Power and read the per-port power consumption. If the port shows < 100 mA but the adapter is actively transferring, the hub is throttling the port — replace the front-panel header with a rear-panel chipset port.

Registry and Driver Store Cleanup

If KB 109476315 does not resolve the fault on the first pass, stale driver store entries are usually the cause. Windows 7 keeps a copy of every installed driver in %SystemRoot%\System32\DriverStore\FileRepository and the matching hardware map in the registry at HKLM\SYSTEM\CurrentControlSet\Enum\USB. When a TIA Portal install overwrites the legacy INF, the DriverStore retains the new build and assigns it the next time the device enumerates, regardless of which INF you point pnputil at.

1. Open an elevated command prompt and run pnputil /enum-drivers. Identify every entry whose OriginalName matches s7usbpcadapter.inf or oem*.inf with a Provider string containing "Siemens". Note the published name (oem<NN>.inf) of each.
2. Force-delete the offending packages: pnputil /delete-driver oem<NN>.inf /uninstall /force for each stale entry, leaving only the build that matches the STEP 7 V5.5 / WinCC flexible 2008 install date. Use the most recent build that predates any TIA Portal install on the system.
3. Remove orphaned upper-filter and lower-filter entries under HKLM\SYSTEM\CurrentControlSet\Enum\USB\VID_0640&PID_0B15 and VID_0640&PID_0B16. Typical filter entries that appear after a TIA overwrite include SiemensPCAdapterUpperFilter and SiemensPCAdapterLowerFilter.
4. Delete the device node from Device Manager → Show hidden devices and reboot. Re-install the driver manually from the STEP 7 V5.5 install path using the procedure in the previous section.
5. Confirm with pnputil /enum-drivers | findstr /I siemens that only the desired package remains. The expected output is exactly one OEM INF line referencing s7usbpcadapter.inf.
6. If the registry path is empty after step 4, plug the adapter in and let Windows re-enumerate, then immediately point it at the STEP 7 V5.5 INF path before any auto-install fires.

Verification and Functional Test

1. Open STEP 7 V5.5. Choose File → Open → Online → Accessible Nodes. The S7-400 MPI address (default 2) must appear within 3 seconds.
2. Right-click the node and choose Download / Upload / Monitor. Verify that Device Manager shows no yellow exclamation mark during the entire transfer.
3. Open WinCC flexible 2008, start a runtime test against the same project and confirm tag polling at the configured acquisition cycle does not interrupt. The default acquisition cycle is 1 s; poll faster to stress the USB endpoint.
4. Pull a Process Monitor (procmon) trace filtered on s7usbpcadapter.sys while the transfer runs. Look for IRP_MJ_INTERNAL_DEVICE_CONTROL failures, STATUS_UNSUCCESSFUL (0xC0000001), or repeated USBD_STATUS_DEVICE_GONE (0xC000000E) returns — any of these confirm a remaining driver or IRQ issue.
5. Reboot the PG/PC and re-test. The fix is only stable if the adapter still survives a cold start.
6. Stress-test with a 5-minute continuous upload while watching Task Manager → Performance → USB for resets or errors. A clean session should report zero error increments and zero endpoint stalls.

Diagnostic Decision Flow

Frequently Asked Questions