WinPE ADK 26100+ / 28000: CM_PROB_REINSTALL on all injected drivers — ROOT\KDNIC proves PnP regression, confirmed workaround

Question

WinPE ADK 26100+ / 28000: CM_PROB_REINSTALL on all injected drivers — ROOT\KDNIC proves PnP regression, confirmed workaround

Daniel Sharp 20

Environment:

ADK 10.1.26100.1, 26100.2454, 28000.1 / Windows 11 24H2 host Hardware tested: Intel gaming laptop (Realtek RTL8125), AMD desktop (Aquantia AQC107, Intel I211)

PROBLEM

All injected drivers in WinPE from ADK 26100+ are stuck with: Problem Code: 18 (CM_PROB_REINSTALL) Problem Status: 0xC0000493 (STATUS_PNP_REBOOT_REQUIRED)

WinPE never reboots, so the flag is never cleared. Devices are permanently non-functional. Network-based OS deployment fails completely.

KEY EVIDENCE — ROOT\KDNIC ROOT\KDNIC (Microsoft's own kernel debugger virtual NIC, pure inbox driver, no injection required) shows the identical CM_PROB_REINSTALL / 0xC0000493 on every affected machine. This conclusively proves the regression is in the WinPE PnP subsystem, not in any injected driver or injection methodology.

SCOPE ADK 25398.1 (Server OS 22H2 kernel) — works correctly ADK 26100.1 / 26100.2454 / 28000.1 (24H2 kernel) — all broken. The regression correlates precisely with the 22H2 to 24H2 kernel transition.

CONFIRMED WORKAROUND (production-tested) In startnet.cmd, after

wpeinit:

pnputil /enum-devices /problem 18 /format csv > %TEMP%\prob18.txt

for /f "usebackq skip=1 tokens=1 delims=," %%i in ("%TEMP%\prob18.txt") do

( pnputil /remove-device "%%i" )

pnputil /scan-devices

Note: /remove-device destroys the broken node entirely; scan-devices creates a fresh node without the flag. Note: CSV format required — standard pnputil text output has leading whitespace that causes the instance ID to be rejected.

REQUESTED FIX The PnP manager should detect the WinPE environment (via MiniNT registry key) and suppress STATUS_PNP_REBOOT_REQUIRED during device installation, since WinPE has no reboot cycle to resolve it. Full root cause analysis with diagnostic outputs, confidence assessments, and recommended fixes is available on request.

0 comments

2 answers

Your answer

Answer 1

Pauline Mbabu 1,840 Microsoft Employee

Hello @Daniel Sharp ,
This is a follow-up on the response above. If it helped answer your question, kindly mark it as Accepted Answer.

If you need more help, please share additional details in the comments.

Thanks!

Daniel Sharp 20 Reputation points

2026-06-05T02:50:36.5966667+00:00

My workaround runs under WinPE and restores network in that environment, so on my factory floor I can fully boot and connect to my network shares to apply my images through dism. I've always followed microsoft ADK documentation for injected drivers in both WinPE boot.wim and Install.wim, but starting with the versions I mentioned, after I boot in WinPE I have no network access, but still works in install.wim. Newest drivers, trusted previously working driver sets, it happens with all tested NIC drivers. All work in live full windows 11, but not in WinPE. All online chatter I found, pointed to sticking with Older ADK versions, since network is broken for apparently everyone in the newer versions under WinPE/ADK boot.wim. I spent a couple days with AI assisted troubleshooting which led me to a workable solution. So now I run on the latest ADK version and have full network connectivity in WinPE I've been accustomed to. I wasn't sure where to bring this working fix to the product teams, so I shared it with the community to hopefully help others having the issue while also reached out to the Microsoft teams I have bumped into at Microsoft through work. Anyway, hopefully newer ADK's will get proper network connectivity as documented inthe process through dism injecting alone, for the meantime I'll continue using my working solution. Hopefully it helps others in the same situation. Attaching full RCA if anyone is interested. Also working on posting it other places more visible to teams involved with ADK/WinPE. Feedback hub etc.. Thanks.

Answer 2

The described WinPE 24H2 PnP regression and the specific CM_PROB_REINSTALL / STATUS_PNP_REBOOT_REQUIRED behavior for injected drivers and ROOT\KDNIC are not documented in the provided context, and no official fix or design note for ADK 26100+/28000 WinPE is available there.

The context only covers:

Supported and recommended methods for injecting drivers into WinPE and install.wim (DISM, $WinPEDriver$, Drvload, unattend, scripts).
General guidance and limitations around $WinPEDriver$ and driver versioning.
How PnP status and problem codes are represented and retrieved.
How to permanently remove drivers and devices using Device Manager and pnputil.

Within that scope, the only supported, documented mechanisms that are relevant to the workaround pattern are:

PnP status / problem codes
- Device status and problem codes are exposed via the unified device property model and CM__Get_DevNode_Status, and in newer Windows also via a problem status property that carries an NTSTATUS value such as STATUS_PNP_REBOOT_REQUIRED.
- This matches the pattern being observed (Problem Code 18 with a problem status NTSTATUS), but the context does not document any WinPE-specific behavior or suppression of STATUS_PNP_REBOOT_REQUIRED.
Removing driver packages and devices with pnputil
- Official guidance for permanent removal of a driver package is to use pnputil /delete-driver <Published Name> /uninstall, which updates devices to another driver or leaves them without a driver if none is available. This is the supported way to ensure a driver is not automatically reinstalled.
- The context also documents pnputil /disable-device and /enable-device for manipulating devices, but does not document /remove-device or /scan-devices, nor any WinPE-specific usage patterns.
Driver injection into WinPE
- For WinPE, the documented and supported approach is to inject drivers into boot.wim using DISM, or to use $WinPEDriver$ or Drvload in WinPE, with the key constraint that driver versions must be consistent across boot.wim and install.wim.
- The article explicitly warns that mixing driver versions or loading conflicting drivers during the WinPE phase can cause drivers to be marked as “Bad” and not selected by PnP later.
- However, there is no mention of CM_PROB_REINSTALL, STATUS_PNP_REBOOT_REQUIRED, or a requirement to reboot in WinPE.

Given the available documentation, the only fully supported guidance that aligns with the scenario is:

Use the documented driver injection methods (DISM into boot.wim, $WinPEDriver$, or Drvload) and ensure driver versions are consistent between WinPE and the target OS image.
Use pnputil only as documented (for example, /delete-driver to remove driver packages, /disable-device and /enable-device to control devices).
For device status and problem codes, rely on the unified device property model or CM__Get_DevNode_Status for diagnostics, but there is no documented way in the context to change PnP’s STATUS_PNP_REBOOT_REQUIRED behavior in WinPE.

The requested change—having the PnP manager detect WinPE (MiniNT) and suppress STATUS_PNP_REBOOT_REQUIRED—is not covered in the provided documentation, and no official fix or configuration knob is documented there. The workaround using pnputil /remove-device and /scan-devices is not described in the context and therefore cannot be validated or recommended based on it.

For an official fix or design change to WinPE/ADK behavior, the appropriate path is to file feedback or a support case with Microsoft so the product team can investigate the regression and consider the requested behavior change.

References: