Running a BMW EWS Key Programmer on Windows XP in UTM on Apple Silicon

I had a piece of BMW diagnostic hardware — an AK-90 in-circuit programmer for reading and writing EWS (the Electronic immobilizer, “Elektronische Wegfahrsperre”) modules and keys — and exactly one way to run it: an ancient Windows-only application from around 1997. No Mac build. No modern Windows build. Just a CD with an InstallShield installer and an XP-era driver.

The obvious plan was a Windows XP virtual machine. The non-obvious part was that this isn’t a “run some old software” problem — it’s a “make real USB hardware talk through an emulated 32-bit guest on an ARM Mac” problem. That’s where all the interesting failures live.

Here’s the whole thing, start to finish, including every wall I hit.

The Challenge

Three things had to line up:

1. Windows XP had to boot under emulation on Apple Silicon. XP is 32-bit x86, so on an ARM Mac it must be fully emulated (via QEMU), not virtualized. Emulation is finicky about the virtual chipset you hand it.
2. The AK-90 software had to install and run. Easy in principle — it’s a tiny late-‘90s app — but it wanted a serial number and had no obvious one.
3. The USB hardware had to pass through from macOS, into the emulated guest, and show up as a COM port the software would accept. This was 90% of the work.

I used UTM (the QEMU front-end for macOS) as the VM host.

Getting XP to Boot: the ACPI Blue Screen

First attempt booted straight into a blue screen:

STOP: 0x000000A5 (0x00000002, ...)
The BIOS in this system is not fully ACPI compliant.

0xA5 is XP setup rejecting the ACPI (Advanced Configuration and Power Interface) tables the virtual machine presents. The cause turned out to be the virtual machine type. When you create the VM, UTM offers a few “Machine” options, and the modern-sounding one — Intel ICH9 based PC (q35) — is the trap. XP has no drivers for the q35/ICH9 chipset. You have to pick the ancient one:

Setting	Value	Why
Machine	Intel i440FX + PIIX (1996)	XP has no q35/ICH9 drivers → 0xA5 BSOD
Architecture	i386 (x86)	XP is 32-bit
Memory	512 MB	XP’s sweet spot; huge RAM confuses it
UEFI boot	Off	XP can’t boot UEFI
Disk / CD interface	IDE	XP setup can’t see VirtIO/NVMe

Switching the machine type to i440FX fixed the blue screen outright.

There’s a second fix worth knowing if a particular ISO still trips the ACPI check even on i440FX: at the very start of text-mode setup, when the bottom of the screen says “Press F6 if you need to install a third-party SCSI or RAID driver,” press F7 instead. F7 silently swaps in the non-ACPI “Standard PC” hardware abstraction layer. On a Mac keyboard you’ll need fn+F7, and click into the VM window first so it has keyboard focus. (Same story for the EULA — it wants fn+F8 to accept, and the prompt is usually cut off at the bottom.)

Getting the Software In

XP can’t reach modern websites — its TLS is far too old — and there’s no shared-folder support without extra guest tooling. So the reliable way to move the AK-90 software into the VM is to rip the physical CD to an ISO on the Mac and mount that as the VM’s virtual CD:

# With the tool CD mounted on the Mac at /Volumes/AK90:
hdiutil makehybrid -iso -joliet -o ~/vms/ak90.iso /Volumes/AK90

Then point the VM’s CD/DVD drive at ak90.iso in UTM, and it shows up as the D: drive in XP. As a bonus, you now have a permanent backup of a decades-old, hard-to-replace disc.

One snag at install time: the “User Information” screen demanded a serial number, and there was none printed on the disc or anywhere in its files. It turns out these old InstallShield installers use a standard registration dialog (SdRegisterUserEx) that only checks the field is non-empty — it doesn’t validate the value. Typing any string (1111111) lit up the Next button and it installed fine.

The Real Work: USB Passthrough

The AK-90 hardware presents itself as a Silicon Labs CP2102 USB-to-UART bridge (USB vendor ID 0x10C4, product ID 0xEA60). In other words, the software talks to it over a virtual serial (COM) port, and the CP2102 needs a driver to expose that port. The driver shipped on the CD (DRIVER_CP210x_VCP_Win_XP...exe), so I installed that first.

Then I plugged in the hardware, UTM popped its “Would you like to connect ‘CP2102 USB to UART Bridge’ to this virtual machine?” prompt, I clicked Confirm… and nothing appeared in XP. No COM port. Not even a yellow “unknown device” in Device Manager.

That last detail is the key diagnostic. A device that’s present but undriven shows up with a yellow flag; nothing at all means the guest never enumerated the device electrically. So I worked through the possibilities:

• Was it an xHCI / USB 3.0 problem? (XP has no USB 3.0 driver, so a device on an xHCI controller is invisible to it.) No — Device Manager already showed a “Standard Enhanced PCI to USB Host Controller” (EHCI = USB 2.0) plus USB 1.1 controllers. XP’s USB stack was healthy.
• Was macOS hogging the device? macOS ships its own CP210x serial driver, and if it claims the device, QEMU can’t pass it through. I checked from the Mac side:

# Is the device visible to macOS, and what are its IDs?
ioreg -p IOUSB -l -w 0 | grep -iE '"USB Product Name"|"idVendor"|"idProduct"'
#   -> "CP2102 USB to UART Bridge Controller" / idVendor 4292 (0x10C4) / idProduct 60000 (0xEA60)

# Did macOS grab it as a serial port? If a device node shows here, macOS is competing for it:
ls -la /dev/cu.* /dev/tty.* | grep -iE 'usb|slab|uart|serial'
#   -> (no output) — macOS did NOT claim it. Good: it's free for passthrough.

The device was visible and free. So the passthrough should work — it just wasn’t.

The fix: attach order matters

The thing that finally worked was the order of operations. Attaching the USB device during boot, or while a driver install was in flight, doesn’t reliably enumerate under emulation. The sequence that works every time:

1. Detach the device in UTM’s USB menu.
2. Fully shut down XP (not restart — all the way off).
3. Leave the hardware plugged into the Mac.
4. Boot XP to the desktop.
5. Now attach the device via UTM’s USB-plug menu.
6. Watch the system tray for “Found New Hardware,” and press F5 in Device Manager.

The moment I attached it against an idle desktop, the CP210x enumerated and Windows bound the driver: Ports (COM & LPT) → Silicon Labs CP210x USB to UART Bridge.

The COM number gotcha

Connecting still failed — this time with “Invalid port number.” The AK-90 software has no manual port picker; it auto-scans and only accepts a low COM number. Mine had landed on COM3. The fix is to renumber it:

Device Manager → right-click the CP210x port → Properties → Port Settings → Advanced → set COM Port Number to COM1 → detach and re-attach the device so it re-enumerates on the new number.

If the software threw the error once before the renumber finished, it caches that bad state — so close and reopen the app, then Connect. That did it. The connection came up clean.

Operating Safely Over Emulated USB

One caveat worth stating loudly: every byte to and from this hardware crosses an emulated USB bus, which is inherently less reliable than bare metal. For a tool that writes to an immobilizer module or a car key, that matters:

• Back up before writing. Read the module and save the dump (twice) before touching any write operation. That backup is your undo button.
• Reads are cheap, writes are dangerous. Do a few clean, consistent reads first to prove the link is stable. Only then attempt a write.
• Never interrupt a write. Don’t unplug, don’t touch the USB menu, and don’t let the Mac sleep mid-operation — a dropped connection during a write can corrupt a key or the module’s EEPROM.
• Keep the Mac awake the whole time you’re connected; a sleep event drops the passthrough.

Key Takeaways

• Pick the i440FX machine type for XP, never q35/ICH9. That single choice is the difference between booting and the 0x000000A5 ACPI blue screen.
• F7 (fn+F7) at text-mode setup disables ACPI as a fallback if a specific ISO still won’t boot.
• Move files in via a ripped ISO (hdiutil makehybrid), since XP can’t browse the modern web and shared folders need guest tooling.
• Old InstallShield serials are usually just non-empty checks — any string works.
• For USB passthrough, attach the device after the guest is idle at the desktop, not during boot or driver install.
• Diagnose with ioreg and /dev/cu.* on the Mac side: if the device shows in ioreg and has no /dev/cu.* node, macOS isn’t holding it and it’s free to pass through.
• Serial tools want a low COM number — renumber to COM1 in Device Manager if auto-detection fails.
• Treat writes over emulated USB as fragile: back up first, keep the connection stable, and never interrupt it.

The whole stack — emulated XP, USB passthrough, a CP2102 on COM1, and a 1997 immobilizer tool talking to real BMW hardware — runs happily on an Apple Silicon Mac. It just takes knowing which of the dozen plausible-looking settings is the one that actually matters.