/
/

How to Add Drivers to WinPE so Windows Setup and Recovery See Your Hardware

by Miguelito Balba, IT Editorial Expert
How to Add Drivers to WinPE so Windows Setup and Recovery See Your Hardware blog banner image

Instant Summary

This NinjaOne blog post offers a comprehensive basic CMD commands list and deep dive into Windows commands with over 70 essential cmd commands for both beginners and advanced users. It explains practical command prompt commands for file management, directory navigation, network troubleshooting, disk operations, and automation with real examples to improve productivity. Whether you’re learning foundational cmd commands or mastering advanced Windows CLI tools, this guide helps you use the Command Prompt more effectively.

Key Points

  • Ensuring Windows Setup and Recovery can see your hardware requires a structured and repeatable approach to adding drivers to WinPE.
  • Best Practices in Adding Drivers to WinPE:
    • Prepare drivers and workspace.
    • Inject drivers into boot.wim with DISM.
    • Load drivers at runtime inside WinPE.
    • Add drivers to the offline Windows image when needed.
    • Use an unattend unattended setup file to preload drivers during Windows Setup (Optional).
    • Validate disk and network in WinPE.
    • Version, store, and reuse.
  • Potential Issues: The setup is still unable to see the disk; the driver is loading, but devices are failing on UEFI; autounattend is not picking up drivers; unsigned or blocked drivers.
  • Follow the best practices in adding drivers to WinPE to enable installations and repairs to proceed smoothly.

When Windows Setup or recovery tools fail to detect your disk, the issue is most often caused by missing or incorrect storage controller drivers within WinPE. The fastest and most reliable fix is to add drivers to WinPE. This can be done by injecting signed INF driver packages into the boot.wim using tools like Deployment Image Servicing and Management (DISM) and loading drivers on the fly for quick validation.

In this guide, we will walk you through a clean, repeatable workflow that helps administrators and MSPs ensure both Windows Setup and recovery environments can consistently detect hardware.

At a glance

Task

Purpose and value

Task 1: Prepare drivers and workspaceImplements a structured approach that promotes clean injection, easier audits, and faster troubleshooting later.
Task 2: Inject drivers into boot.wim with DISMEnsures consistent behavior across devices by updating both boot image indexes.
Task 3: Load drivers at runtime inside WinPEProvides fast iteration without rebuilding your USB every time.
Task 4: Add drivers to the offline Windows image when neededProvides complete driver coverage by servicing both WinPE and the offline Windows image.
Task 5: Use an unattend unattended setup file to preload drivers during Windows Setup (Optional)Allows you to scale to diverse fleets without manually rebuilding boot.wim every time.
Task 6: Validate disk and network in WinPEConfirms the state of USB’s essential components before deployment.
Task 7: Version, store, and reuseGuarantees predictable outcomes, easy rollbacks, and faster builds in the future.

Prerequisites

Before proceeding with the steps, check first that you have the following:

  • WinPE media created from your existing process
  • Driver INF packages for target hardware (storage, USB, touchpad, NIC)
  • Tech PC with administrator rights and DISM, preferably via Windows ADK

Task 1: Prepare drivers and workspace

Start by establishing a clean workspace and organizing your driver sets. Do the following actions:

  • Create a ‘Root Drivers’ folder on the technician’s PC. Inside it, collect signed driver packages in a folder tree, one subfolder per device or model.
  • Since they directly impact disk visibility in WinPE, it is recommended to use vendor-supplied storage and USB controllers. You can follow the input and NIC.
  • Verify architecture matches your WinPE (x64).

Task 2: Inject drivers into boot.wim with DISM

To ensure full coverage, mount the boot.wim index 1 and index 2 in turn. You can then add drivers recursively. Follow this workflow:

  1. Mount Index 1:

dism /Mount-Wim /WimFile:X:\sources\boot.wim /index:1 /MountDir:C:\Mount\PE1

NOTE: Replace ‘X:’ with the drive letter assigned to your Windows installation USB.

  1. Add all drivers recursively:

dism /Image:C:\Mount\PE1 /Add-Driver /Driver:C:\Drivers /Recurse

NOTE: Replace C:\Drivers with the path to the extracted INF driver folder.

  1. Commit changes:

dism /Unmount-Wim /MountDir:C:\Mount\PE1 /Commit

NOTE: Replace C:\Drivers with the path to the extracted INF driver folder.

  1. Repeat the same mount, driver injection, and commit steps for boot.wim index 2. This index is used by Windows Setup and must also contain the required drivers for disk and hardware detection during installation.

Task 3: Load drivers at runtime inside WinPE

NOTE: wpeinit is automatically executed in most WinPE environments. Re-running it is safe and can be useful for validation or troubleshooting.

There may be instances where you need to confirm a single driver before committing it to your media. WinPE supports runtime testing using drvload. Here are the actions you can take:

  1. Boot from your WinPE USB.
  2. Press Shift + F10 to open Command Prompt.
  3. Load a driver manually for temporary validation:

drvload X:\Drivers\Storage\iaStorAC.inf

NOTE: Replace “X:” with the drive letter assigned to the USB or media containing the driver INF.

  1. Re-scan disks using disk utilities or relaunch Windows Setup.
  2. Once confirmed, rebuild the final media by injecting only the working driver set back into boot.wim.

Task 4: Add drivers to the offline Windows image when needed

If Windows is installed but a required driver is missing before the first boot, or if Windows cannot boot correctly, mount the offline Windows image and add the same driver using DISM. Do it using:

dism /Image:D:\ /Add-Driver /Driver:C:\Drivers\Storage /Recurse

NOTE: Replace D:\ with the drive letter where the offline Windows installation is mounted.

Use this in conjunction with WinPE injection for comprehensive coverage.

Task 5: Use an unattend unattended setup file to preload drivers during Windows Setup (Optional)

If you support multiple hardware models, automation becomes essential. The PnpCustomizationsWinPE component in autounattend.xml allows Setup to automatically load drivers during the Windows PE phase from a location on your USB drive.

  1. In your autounattend file, point the DriverPaths element to a folder such as \Drivers on the root of the USB.
  2. Ensure the configuration is placed in the WindowsPE pass, as other passes will not load drivers during Setup.
  3. Validate pathing by booting the USB and confirming driver pickup during Setup.

Task 6: Validate disk and network in WinPE

NOTE: wpeinit is automatically executed in most WinPE environments. Re-running it is safe and can be useful for validation or troubleshooting.

Before deploying your USB at scale, verify essential components:

  1. Boot the USB and allow WinPE to initialize.
  2. Run:

wpeinit

  1. And then run:

wpeutil InitializeNetwork

  1. Test networking: for example, by pinging the gateway or initiating a minimal network operation.

Task 7: Version, store, and reuse

To make the steps repeatable and scalable, apply good documentation and versioning by:

  • Saving the driver set and the exact DISM commands used with dates and model notes.
  • Keeping a minimal, signed INF catalog for each hardware family to speed rebuilds.

Troubleshooting

You may encounter several bottlenecks when adding drivers to WinPE. Here are some of the most common issues:

IssuePossible solution
Set up still can’t see the disk.Verify you serviced both boot.wim indexes. Try runtime drvload to confirm the exact INF, then re-inject.
Driver loads, but devices fail on UEFI.Ensure the driver matches the WinPE architecture and is compatible with the system’s firmware and storage mode when booting in UEFI.
Autounattend doesn’t pick up drivers.Confirm that the component pass is WinPE and that the path exists at boot time.
Drivers fail to load due to signature enforcement.Use signed INF drivers whenever possible. Test signing should be enabled only in controlled lab environments and never used in production.

Ensuring Windows Setup and Recovery can see your hardware

It can create pushbacks when WinPE can’t recognize the essential components of your computer, such as the hard drive, USB ports, or network. This makes even simple tasks impossible until the right drivers are added and validated. You can mitigate this by adding drivers to WinPE, primarily by injecting signed INF driver packages into the boot.wim.

Key Takeaways

  • Inject signed INF drivers into boot.wim indexes 1 and 2
  • Validate quickly inside WinPE with drvload
  •  Stage drivers via autounattend for multi-model media
  •  Initialize networking and verify both storage and NICs
  •  Keep a vetted, versioned driver repo for reuse

Following the outlined steps should ensure the hardware’s visibility during both WinPE and Windows Setup and Recovery.

Related topics:

FAQs

While technically possible in environments where Secure Boot is disabled, unsigned drivers will not load when Secure Boot is enabled. Always prefer signed INF drivers, and test unsigned drivers only in controlled lab scenarios with Secure Boot turned off.

Boot WinPE and verify whether storage devices are visible. Use drvload to test storage controller drivers at runtime; if the disk appears after loading the driver, the correct storage driver was missing.

Yes. Organize drivers by model or device type in subfolders and optionally stage them using autounattend.xml for hands-off deployment during Windows Setup.

No. WinPE drivers only affect the preinstallation or recovery environment. If a device is still missing after installation, add the same driver to the offline Windows image using the DISM command.

Update drivers whenever you have new hardware or Windows updates that require newer drivers. Maintaining a versioned, per-model driver repository ensures reliability across deployments.

You might also like

Ready to simplify the hardest parts of IT?