Windows apps, drivers and Device Manager

A user needs an app, a laptop has lost its Wi-Fi after an update, and a stranger has emailed a setup file marked urgent. Three everyday tickets, and each one turns on the same three skills: where software comes from, how Windows runs it, and what to do when a device stops working. A wrong choice is expensive here: an x64 driver copied to a new Arm laptop will not load at all, and one unchecked installer can reach every PC behind the first.

The sections below walk that path in order. You will pick an install source on purpose, see why a 64-bit app can run on an Arm laptop while its driver cannot, turn a Device Manager problem code into a plan, work the driver fix ladder from its safest step, and test an unknown installer in a throwaway desktop before it touches a real PC.

Install sources, and why the managed one wins

A user asks for a PDF editor. You can put it on their PC from four places, and the place decides who keeps it updated and whether you can remove it cleanly later. The Microsoft Store and your organisation’s company portal are managed sources: the Store updates its apps on its own, and the portal lets an administrator push, update and remove an app across every PC at once. WinGetwinget: The Windows Package Manager command-line tool. Running winget upgrade lists installed apps that have a newer version, and winget upgrade --all installs them. More in “Updates, patches and drivers without surprises” is the command line for the same job on one PC or, in a script, across many: winget search finds an app, winget install adds it, winget list shows what is installed and whether an upgrade is available, winget upgrade updates it and winget uninstall removes it. A vendor installer — an MSI, an MSIXMSIX package: A modern Windows app package format that installs and uninstalls cleanly and can update through a store or a managed source, unlike a plain setup EXE. package or a plain setup .exe you download — leaves every update and removal to you.

Prefer a managed source when you have the choice. An app that arrived through the Store, the portal or WinGet can be updated and removed the same way later; an app from a setup .exe is known only to the PC it landed on, so it drifts out of date and has to be hunted down by hand when the user leaves. The question below turns four sources into one decision from three facts about the ticket.

In short: a managed PC takes the app from the portal or the Store so the organisation keeps control; WinGet is the quick, scriptable choice when an app is not in either; and a vendor installer is the last resort, for software that lives nowhere else.

What runs on x64, and what Arm64 must emulate

A desk now hands out two kinds of laptop: the familiar Intel and AMD machines, whose processors use the x86 and x64The processor family of Intel and AMD chips, built in 32-bit (x86) and 64-bit (x64) forms. Software built only for it needs translation to run on Arm chips. instruction set, and newer Windows on Arm laptops, whose processors use Arm64Arm64: The 64-bit Arm processor family of Apple silicon Macs, Windows on Arm laptops, phones and many servers. Software built only for x86-64 needs translation to run on it. More in “Inside a computer: CPU, RAM, board and GPU”. The same app behaves differently on each, and the rules are worth knowing exactly.

On a 64-bit x64 PC, 64-bit apps run as they are, and 32-bit x86 apps run through WOW64WOW64 is the subsystem Microsoft describes as the x86 emulator that lets 32-bit Windows applications run on 64-bit Windows, kept apart from 64-bit code., which Microsoft calls “the x86 emulator that allows 32-bit Windows-based applications to run seamlessly on 64-bit Windows”. On a Windows on Arm PC, Arm64 apps run natively, and both x86 and x64 apps run under PrismPrism: The emulator in Windows 11, version 24H2 that runs x86 and x64 apps on Windows on Arm by translating their instructions to Arm64 as they run., the emulator introduced in Windows 11, version 24H2, which translates their instructions to Arm64 as they run. The catch sits in one sentence of Microsoft’s page: emulation “only supports user mode code and doesn’t support drivers”, and “any kernel mode components must be compiled as Arm64”. A device driverdevice driver: The software that lets Windows talk to a piece of hardware. Kernel-mode drivers run inside the operating system, so a faulty one can stop the device or the whole PC. runs in kernel modekernel mode: The privileged processor state the operating system core and device drivers run in, with direct access to hardware; a fault here can crash the whole PC., not user modeuser mode: The restricted processor state that ordinary applications run in, kept away from hardware and the operating system core; emulation on Windows on Arm covers only this code., so an x64 driver that works perfectly on an x64 laptop will not load on an Arm64 one. Step through where each thing lands:

The sample below places five pieces of software — three apps and two drivers — on an x64 PC and on an Arm64 PC, and prints the rule behind each verdict. It is a small decision engine, not a capture from a machine.

r"""Decide where sample apps and drivers run on an x64 PC and on an Arm64 PC.

The rules are exactly as Microsoft's pages state them:
- "WOW64 is the x86 emulator that allows 32-bit Windows-based applications to
  run seamlessly on 64-bit Windows" ("Running 32-bit Applications").
- Windows 11 on Arm runs Arm64 apps natively and emulates x86 and x64 apps;
  the 24H2 emulator is named Prism. "Emulation only supports user mode code
  and doesn't support drivers. Any kernel mode components must be compiled as
  Arm64" ("How emulation works on Arm").
Each verdict prints the rule it used, so nothing is a bare label.
"""

# (name, built-for architecture, kind): the sample software to place.
SAMPLES = [
    ("Spreadsheet app", "x86", "app"),
    ("Video editor", "x64", "app"),
    ("Arm-native browser", "arm64", "app"),
    ("Printer driver", "x64", "driver"),
    ("Touchpad driver", "arm64", "driver"),
]


def on_x64(arch, kind):
    """Verdict on x64 (Intel or AMD) Windows."""
    if arch == "x64":
        verb = "Runs natively" if kind == "app" else "Loads natively"
        return verb, "x64 Windows runs 64-bit x64 code natively"
    if arch == "x86":
        if kind == "app":
            return "Runs through WOW64", "x64 Windows runs 32-bit x86 apps through WOW64"
        return "Does not load", "a kernel-mode driver on x64 Windows must be 64-bit"
    verb = "Does not run" if kind == "app" else "Does not load"
    return verb, "x64 Windows has no Arm emulation"


def on_arm64(arch, kind):
    """Verdict on Windows 11 on Arm, version 24H2 (Prism)."""
    if arch == "arm64":
        verb = "Runs natively" if kind == "app" else "Loads natively"
        return verb, "Windows on Arm runs Arm64 code natively"
    if kind == "driver":
        return "Does not load", "emulation is user-mode only, so a driver must be Arm64"
    if arch == "x86":
        return "Runs under emulation", "Windows on Arm emulates x86 apps (the WOW64 x86 layer)"
    return "Runs under Prism emulation", "Windows 11 24H2 emulates x64 apps with Prism"


def main():
    for name, arch, kind in SAMPLES:
        print(f"{name} ({arch} {kind})")
        for label, decide in (("x64 PC  ", on_x64), ("Arm64 PC", on_arm64)):
            verdict, rule = decide(arch, kind)
            print(f"  {label}: {verdict}")
            print(f"            rule: {rule}")
        print()


if __name__ == "__main__":
    main()

Spreadsheet app (x86 app)
  x64 PC  : Runs through WOW64
            rule: x64 Windows runs 32-bit x86 apps through WOW64
  Arm64 PC: Runs under emulation
            rule: Windows on Arm emulates x86 apps (the WOW64 x86 layer)

Video editor (x64 app)
  x64 PC  : Runs natively
            rule: x64 Windows runs 64-bit x64 code natively
  Arm64 PC: Runs under Prism emulation
            rule: Windows 11 24H2 emulates x64 apps with Prism

Arm-native browser (arm64 app)
  x64 PC  : Does not run
            rule: x64 Windows has no Arm emulation
  Arm64 PC: Runs natively
            rule: Windows on Arm runs Arm64 code natively

Printer driver (x64 driver)
  x64 PC  : Loads natively
            rule: x64 Windows runs 64-bit x64 code natively
  Arm64 PC: Does not load
            rule: emulation is user-mode only, so a driver must be Arm64

Touchpad driver (arm64 driver)
  x64 PC  : Does not load
            rule: x64 Windows has no Arm emulation
  Arm64 PC: Loads natively
            rule: Windows on Arm runs Arm64 code natively

The x64 app runs natively on the x64 PC and under Prism emulation on the Arm64 one; the x64 printer driver loads on the x64 PC but not on the Arm64 PC, where it reports “Does not load” because a driver must be built for Arm64. Change the SAMPLES list and run it again to test a case from your own fleet.

Device Manager shows a code for every stuck device

When Windows cannot use a device, Device Manager marks it with a yellow exclamation point and, in the device’s Properties, shows a short message with a problem codeproblem code: The number Device Manager shows for a device it cannot use, such as Code 28, each mapped to a message and a cause in Microsoft's documentation.. The code is the fastest way to tell a dead device from a disabled or undriven one. Four codes cover most tickets, and Microsoft gives each an exact message:

You do not always have the screen in front of you. Over a remote session, pnputil /enum-devices /problem lists every device with a problem from the command line, and pnputil /enum-devices /problem 28 lists only those with a chosen code. PnPUtil is in every Windows install and needs an administrator prompt. The sample below is written as Label: value lines with the fields a technician reads: Instance ID, Device Description, Status and the problem code. Microsoft’s PnPUtil page documents the command and its filters but shows no sample of this output, so the program reads only the labels it knows and ignores the rest. It reads three devices and prints each code’s message:

r"""Map Device Manager problem codes to the messages Windows shows.

The SAMPLE below is written in the key: value layout that
`pnputil /enum-devices /problem` prints, using the field names Microsoft
documents (Instance ID, Device Description, Status) with the problem code the
/problem filter adds. It is a sample written in that layout, not a capture
from any PC.
"""

# The message each problem code shows, quoted from Microsoft's
# "Error codes in Device Manager in Windows".
MESSAGES = {
    10: "This device cannot start. (Code 10)",
    22: "This device is disabled. (Code 22)",
    28: "The drivers for this device are not installed. (Code 28)",
    43: "Windows has stopped this device because it has reported problems. (Code 43)",
}

SAMPLE = r"""
Instance ID:        USB\VID_045E&PID_00DB\5&2B3F1A09&0&2
Device Description: USB Audio Device
Class Name:         MEDIA
Status:             Disabled
Problem Code:       22

Instance ID:        PCI\VEN_8086&DEV_1502\3&11583659&0&C8
Device Description: Ethernet Controller
Class Name:         Net
Status:             Error
Problem Code:       28

Instance ID:        USB\VID_0781&PID_5581\0401A1B2C3D4
Device Description: USB Mass Storage Device
Class Name:         USBSTOR
Status:             Error
Problem Code:       43
"""


def records(text):
    """Split the listing into devices (blank-line separated), each a dict of fields."""
    for block in text.strip().split("\n\n"):
        fields = {}
        for line in block.splitlines():
            if ":" in line:
                key, value = line.split(":", 1)
                fields[key.strip()] = value.strip()
        if fields:
            yield fields


def main():
    for dev in records(SAMPLE):
        code = int(dev["Problem Code"])
        meaning = MESSAGES.get(code, f"Problem code {code}")
        print(f'{dev["Device Description"]}  [{dev["Status"]}]')
        print(f'  {dev["Instance ID"]}')
        print(f"  Code {code}: {meaning}")
        print()


if __name__ == "__main__":
    main()

USB Audio Device  [Disabled]
  USB\VID_045E&PID_00DB\5&2B3F1A09&0&2
  Code 22: This device is disabled. (Code 22)

Ethernet Controller  [Error]
  PCI\VEN_8086&DEV_1502\3&11583659&0&C8
  Code 28: The drivers for this device are not installed. (Code 28)

USB Mass Storage Device  [Error]
  USB\VID_0781&PID_5581\0401A1B2C3D4
  Code 43: Windows has stopped this device because it has reported problems. (Code 43)

The run shows a disabled audio device (Code 22), a network adapter with no driver (Code 28) and a mass-storage device Windows stopped (Code 43) — exactly the three a technician would triage first. Each line carries the instance id you would hand to pnputil or to a driver tool.

A driver is fixed from the safest rung up

Once a code points at a driver, fix it from the safest rung up, undoing as little as possible. If the trouble began right after a driver update, a driver rollbackdriver rollback: Replacing a device's current driver with the version installed just before it, from the device's Properties in Device Manager, to undo a bad driver update. is first: the device’s Properties in Device Manager keep the previous driver and can put it back in one step, with nothing downloaded. If there was no recent update, or rollback is greyed out, update the driver from Windows Update or the maker’s own tool. If updating does not help, uninstall the device and scan for hardware changes so Windows detects it fresh and reinstalls its driver. Only when the device still shows a code after all three — a sign of failed hardware or a deeper fault — do you escalate, with the code and every step attached.

Each rung is more disruptive than the one before, which is why the order matters: a rollback touches one driver, while an uninstall-and-rescan briefly removes the device. Work one change at a time and re-check the code after each, so you know which step fixed it.

The one order to resist is the tempting shortcut of removing a device the instant it misbehaves.

Check an unknown installer before it runs

A user forwards a setup file “from the vendor”, or a download that a browser flagged. Before it runs anywhere near a real PC, confirm two things in order: that it is really from the publisher it claims, and that it is the exact file the vendor published. Right-click the file, open Properties and read the Digital Signatures tab: an unsigned installer, or one whose listed publisher you do not recognise, is reason enough to stop. Then compare its hash. Get-FileHash computes a file’s hash and, as Microsoft’s documentation states, “uses the SHA256 algorithm” by default; a single changed byte changes the whole value, so a hash that matches the vendor’s published SHA-256 proves the file arrived intact.

Even a signed file with a matching hash can misbehave on first run. That is what Windows SandboxWindows Sandbox: A disposable, isolated Windows desktop on the Pro, Enterprise and Education editions; everything inside it is discarded when it closes, so an unknown installer leaves no trace. is for: a disposable desktop on Windows Pro, Enterprise and Education that, in Microsoft’s words, is “as clean as a brand-new installation of Windows” and discards “everything” when it closes. Install the app there, watch what it does, and nothing reaches the host. It needs virtualization enabled in the BIOS and modest resources — Microsoft lists at least 4 GB of RAM, 1 GB of spare disk space and two CPU cores.

MySmartCoPilot’s hash generator computes a file’s SHA-256 so you can compare it with the vendor’s value, and the file safety inspector reads what a file declares about itself. Both check the file; only the Sandbox shows how it behaves.

Practise: list the stuck devices

Every driver ticket starts the same way: read a pnputil /enum-devices /problem report and pull out the devices that need attention. Write problem_devices(pnputil_text) so that it returns each problem device as a tuple of its instance id, description, code and Windows’ message, skipping the healthy ones. The sample tests cover the four common codes, a healthy device that must be left out, and an unknown code. Then check yourself on the whole lesson.

def problem_devices(pnputil_text):
    """Return (instance_id, description, code, meaning) for each device with a problem.

    Devices appear one after another, separated by a blank line, as
    `Label: value` lines. Keep the order they appear in.
    """
    return []

from problem_devices import problem_devices

THREE = r"""
Instance ID:        HID\VID_413C&PID_2113\6&1A2B3C4D&0&0000
Device Description: HID Keyboard Device
Class Name:         Keyboard
Status:             Started

Instance ID:        USB\VID_045E&PID_00DB\5&2B3F1A09&0&2
Device Description: USB Audio Device
Class Name:         MEDIA
Status:             Disabled
Problem Code:       22

Instance ID:        PCI\VEN_8086&DEV_1502\3&11583659&0&C8
Device Description: Ethernet Controller
Class Name:         Net
Status:             Error
Problem Code:       28
"""


def test_skips_healthy_device():
    """a Started device with no problem code is left out"""
    result = problem_devices(THREE)
    assert len(result) == 2
    assert all(descr != "HID Keyboard Device" for _, descr, _, _ in result)


def test_keeps_report_order():
    """the devices come back in the order they appear"""
    result = problem_devices(THREE)
    assert result[0][1] == "USB Audio Device"
    assert result[1][1] == "Ethernet Controller"


def test_maps_each_message():
    """every documented code maps to Windows' own message"""
    text = (
        "Instance ID:        A1\n"
        "Device Description: Graphics\n"
        "Status:             Error\n"
        "Problem Code:       10\n\n"
        "Instance ID:        A2\n"
        "Device Description: Sound\n"
        "Status:             Disabled\n"
        "Problem Code:       22\n\n"
        "Instance ID:        A3\n"
        "Device Description: Wi-Fi\n"
        "Status:             Error\n"
        "Problem Code:       28\n\n"
        "Instance ID:        A4\n"
        "Device Description: Storage\n"
        "Status:             Error\n"
        "Problem Code:       43\n"
    )
    result = problem_devices(text)
    meanings = {code: meaning for _, _, code, meaning in result}
    assert meanings[10] == "This device cannot start. (Code 10)"
    assert meanings[22] == "This device is disabled. (Code 22)"
    assert meanings[28] == "The drivers for this device are not installed. (Code 28)"
    assert meanings[43] == "Windows has stopped this device because it has reported problems. (Code 43)"


def test_code_is_an_integer_and_fields_trimmed():
    """the code is an int and the trailing spaces after the colon are gone"""
    text = (
        "Instance ID:        SWD\\X\n"
        "Device Description: Smart Card\n"
        "Status:             Error\n"
        "Problem Code:       43\n"
    )
    instance_id, description, code, meaning = problem_devices(text)[0]
    assert instance_id == "SWD\\X"
    assert description == "Smart Card"
    assert code == 43
    assert isinstance(code, int)


def test_unknown_code_gets_a_fallback():
    """a code without a documented message still names its number"""
    text = (
        "Instance ID:        B1\n"
        "Device Description: Card Reader\n"
        "Status:             Error\n"
        "Problem Code:       31\n"
    )
    result = problem_devices(text)
    assert result == [("B1", "Card Reader", 31, "Unknown problem code (Code 31)")]


def test_empty_report_is_empty():
    """no devices means no tuples"""
    assert problem_devices("") == []
    assert problem_devices("\n\n") == []


def test_problem_code_line_alone_marks_a_device():
    """a Problem Code line is enough, whatever word the Status line uses"""
    text = (
        "Instance ID:        C1\n"
        "Device Description: USB Camera\n"
        "Status:             Problem\n"
        "Problem Code:       43\n"
    )
    assert problem_devices(text) == [
        ("C1", "USB Camera", 43, "Windows has stopped this device because it has reported problems. (Code 43)")
    ]

Interview questions

Warm-up (fresher): a device shows Code 28 in Device Manager — what does that tell you, and what is your first move?

Code 28 is Windows’ message “The drivers for this device are not installed”: the hardware is present and detected, but no working driver is loaded for it, so the device does nothing. It is not a dead device and not a disabled one, so you do not reseat or enable it first. Your first move is to get it a driver: let Windows Update search for one, or install the maker’s driver package for that exact model, then scan for hardware changes. If a driver was there before and vanished, check whether a recent update or a cleanup removed it. Note the device’s instance id from Device Manager or pnputil /enum-devices /problem so you install the driver for the right hardware, especially when several similar devices are listed.

Two harder questions follow, on cases the plain rules do not settle. For each, decide your very first action, then compare it with the first step shown under the question:

Key takeaways

• Choose the most managed install source an app offers — the company portal, the Store, then WinGet — so updates and clean removal stay possible; a vendor MSI, MSIX or .exe is the last resort.
• An x64 PC runs 64-bit apps natively and 32-bit x86 apps through WOW64; a Windows on Arm PC runs Arm64 apps natively and emulates x86 and x64 apps with Prism from version 24H2.
• Emulation covers user-mode code only, so a driver must be built for Arm64: an x64 driver that works on an Intel laptop will not load on a Windows on Arm one.
• Device Manager shows a problem code for a stuck device — 10 cannot start, 22 disabled, 28 no driver, 43 Windows stopped it — and pnputil /enum-devices /problem lists them from the command line.
• Fix a driver from the safest step up: roll back a bad update, then update the driver, then uninstall and rescan, and escalate only if the code remains.
• Before an unknown installer runs, confirm its publisher signature and match its SHA-256 with Get-FileHash, then try it in Windows Sandbox, which discards everything when it closes.