Slipstream Drivers into a Windows ISO: Make Setup “Just Work”

February 23, 2026 • February 23, 2026 • Read: 23 min • Views: 1

Was this helpful?

You boot the Windows installer. You click “Install now.” And then the punchline lands: no disks found, no network,
sometimes not even a keyboard on newer platforms. This is the moment where teams either look like professionals or
start rummaging through random driver ZIPs like it’s a yard sale.

Slipstreaming drivers—injecting them into the installer image—turns that chaos into a boring, repeatable outcome.
Setup sees storage. WinPE sees the NIC. Imaging tools behave. Your midnight maintenance window stays boring, which is
the highest form of success in operations.

What slipstreaming really means (and what it doesn’t)

Slipstreaming is offline servicing: you mount Windows image files (WIM), inject drivers (typically via .inf
packages), commit the changes, and rebuild the ISO so Windows Setup loads those drivers without you clicking “Load driver.”
You’re not “installing drivers” in the running OS. You’re baking them into the installer environment (WinPE) and/or the
installed OS image.

There are two main images that matter:

boot.wim: the Windows Preinstallation Environment (WinPE) used by Setup. If Setup can’t
see disks or network, this is usually where you inject.
install.wim (or install.esd): the actual Windows edition images that get applied
to disk. If Windows installs but then blue-screens on first boot or has no NIC after install, you inject here too.

Slipstreaming is not magic. If you inject the wrong architecture (x86 vs x64), the wrong driver model (a legacy installer
EXE instead of an INF-based package), or a driver that requires a co-installer not supported in WinPE, you’ll still lose.
You just lose earlier and more deterministically—which is honestly an improvement.

One operational truth: treat installer media like code. Version it. Label it. Test it. If someone says “I made a new ISO,
it should be fine,” that’s not a process; that’s a superstition with a zip file attached.

Facts and context you can use in meetings

A few concrete facts and historical context points that make this topic less mystical and more predictable:

The term “slipstreaming” became popular in the Windows XP era when admins merged service packs into
installation media to avoid patching immediately after install.
WIM images are file-based, not sector-based. That’s why DISM can mount them, manipulate contents, and
deduplicate files across editions.
WinPE is minimal by design. It doesn’t ship with every storage and NIC driver known to humankind,
because the point is small footprint and broad-but-not-infinite compatibility.
UEFI adoption changed the installer story. Modern platforms lean on UEFI, GPT, Secure Boot, and newer
storage abstractions (NVMe, VMD, RAID-on-CPU) that require vendor drivers earlier in the boot/install pipeline.
NVMe support in Windows evolved significantly over time; older Windows versions required hotfixes or
vendor drivers, while newer releases include broad NVMe support—but not every platform controller mode.
Intel RST/VMD and similar storage “acceleration” stacks often hide physical NVMe drives behind a
controller abstraction, so the generic Windows NVMe driver won’t see the disks until the vendor driver is loaded.
install.esd vs install.wim: ESD is a more compressed format. It’s great for distribution, annoying for
servicing. Many workflows convert ESD to WIM to inject drivers reliably.
Windows Setup uses two indices in boot.wim on typical media: one for WinPE and one for the Setup
environment. If you inject into the wrong index, nothing changes and you’ll swear DISM is lying.

Decide what to inject: storage, network, and the two WIMs

If you’re here because “no disks found,” start with storage drivers in boot.wim. If you’re here because the
installer can’t reach your deployment share, start with NIC drivers in boot.wim. If Windows installs and
then can’t boot or can’t see network on first boot, inject into install.wim too.

Storage: the usual suspects

Intel RST / VMD on modern laptops and some servers.
Broadcom/LSI MegaRAID on enterprise servers.
HPE Smart Array, Dell PERC in their various generations.
Marvell/JMicron oddities on whitebox boards and appliances.

Network: it’s never “just DHCP”

Without NIC drivers in WinPE, you can’t pull an answer file, drivers, packages, or an image from the network. You can’t
join to a deployment system. You also can’t easily troubleshoot because half your tools live on the other side of the
network.

Deciding where the driver must land

Use this decision rule:

Setup can’t see disks/NIC → inject into boot.wim (Setup environment).
Setup works but first boot fails → inject into install.wim (installed OS image).
Both happen → inject into both. Don’t negotiate with physics.

Driver hygiene: picking the right INF and avoiding driver soup

Vendors love giving you a single download called something like “Storage Driver Package” that contains:
an MSI, a setup EXE, three different INF folders, and a PDF that assumes you’re deploying with a tool you don’t have.
Your job is to locate the .inf files for the exact hardware and OS architecture.

Operationally, you want:

Signed drivers (especially with Secure Boot). Unsigned in WinPE is a time bomb.
Minimal set: only the storage/NIC drivers you need for this platform family.
Traceability: record vendor version, release date, and the hardware model(s) it targets.

Don’t inject “every driver we’ve ever used” into your ISO. It feels safe. It is not safe. It increases boot.wim size,
increases load time, increases the chance of driver conflicts, and makes troubleshooting ambiguous.

Joke #1: Injecting every driver you can find is like bringing your entire garage to change a tire. You’ll still lose the 10mm socket.

A practical lab layout (folders, tools, expectations)

You can do this on a Windows admin workstation, a build VM, or a CI runner. You can also do parts from Linux (mounting ISOs,
extracting files), but DISM servicing is easiest and most supported on Windows.

A simple structure:

C:\ISO\src — extracted Windows ISO contents
C:\ISO\mount\boot — mount point for boot.wim
C:\ISO\mount\install — mount point for install.wim
C:\ISO\drivers\storage — storage drivers, INF-based
C:\ISO\drivers\nic — NIC drivers, INF-based
C:\ISO\out — rebuilt ISO staging output

Tools you’ll typically use:

DISM (built into Windows) for mount/add-driver/commit/export
oscdimg (Windows ADK) to rebuild a bootable ISO properly
Get-FileHash / signtool (optional) for integrity and signature checks

Practical tasks with commands: the real work

The tasks below are written like you’re running a production build: you check state, you confirm assumptions, and you make
a decision based on output. I’m using a bash-style wrapper prompt per requirements; the commands are Windows-native and
runnable in PowerShell or CMD.

Task 1: Confirm you’re servicing the right ISO build (version sanity check)

cr0x@server:~$ dism /Get-WimInfo /WimFile:C:\ISO\src\sources\install.wim
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Details for image : C:\ISO\src\sources\install.wim

Index : 1
Name : Windows 11 Pro
Description : Windows 11 Pro
Size : 16,123,456,789 bytes

Index : 2
Name : Windows 11 Pro N
Description : Windows 11 Pro N
Size : 15,987,654,321 bytes

The operation completed successfully.

What it means: You’ve got a WIM with multiple indices (editions). Injecting into only one index means only
that edition gets the driver.

Decision: Identify which index you deploy. If you use multiple editions, plan to inject into each index
you might install.

Task 2: Inspect boot.wim indices (the “wrong index” trap)

cr0x@server:~$ dism /Get-WimInfo /WimFile:C:\ISO\src\sources\boot.wim
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Details for image : C:\ISO\src\sources\boot.wim

Index : 1
Name : Microsoft Windows PE (x64)
Description : Microsoft Windows PE (x64)

Index : 2
Name : Microsoft Windows Setup (x64)
Description : Microsoft Windows Setup (x64)

The operation completed successfully.

What it means: Index 2 is typically the Setup environment that actually enumerates storage during the UI.

Decision: Inject storage/NIC drivers into index 2 at minimum. For safety, many shops inject into both.

Task 3: Mount boot.wim index 2 (Setup) read-write

cr0x@server:~$ dism /Mount-Wim /WimFile:C:\ISO\src\sources\boot.wim /Index:2 /MountDir:C:\ISO\mount\boot
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Mounting image
[==========================100.0%==========================]
The operation completed successfully.

What it means: You now have an offline Windows image at C:\ISO\mount\boot.

Decision: If mount fails with “Access is denied” or “The directory is not empty,” stop and clean up before
proceeding. Don’t stack bad state.

Task 4: List existing third-party drivers in WinPE before you add more

cr0x@server:~$ dism /Image:C:\ISO\mount\boot /Get-Drivers /Format:Table
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Published Name      Original File Name  Inbox  Class Name
oem1.inf            e1d68x64.inf         No     Net
oem2.inf            iaStorVD.inf         No     SCSIAdapter

The operation completed successfully.

What it means: “Inbox: No” indicates added drivers. You can see what’s already in the image.

Decision: If the driver you need is already present, your issue is likely not “missing driver” but “wrong
controller mode,” “Secure Boot blocking unsigned,” or “wrong index.”

Task 5: Add storage drivers recursively (INF-based)

cr0x@server:~$ dism /Image:C:\ISO\mount\boot /Add-Driver /Driver:C:\ISO\drivers\storage /Recurse
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Searching for driver packages to install...
Found 3 driver package(s) to install.
Installing 1 of 3 - C:\ISO\drivers\storage\iaStorVD.inf: The driver package was successfully installed.
Installing 2 of 3 - C:\ISO\drivers\storage\iaStorAC.inf: The driver package was successfully installed.
Installing 3 of 3 - C:\ISO\drivers\storage\iaVMD.inf: The driver package was successfully installed.
The operation completed successfully.

What it means: DISM found INF packages and injected them into the offline image driver store.

Decision: If DISM reports “No driver packages were found,” you’re pointing at the wrong folder (likely an
EXE/MSI bundle) or the INF isn’t for this architecture.

Task 6: Add NIC drivers (so WinPE can reach your deployment systems)

cr0x@server:~$ dism /Image:C:\ISO\mount\boot /Add-Driver /Driver:C:\ISO\drivers\nic /Recurse
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Searching for driver packages to install...
Found 1 driver package(s) to install.
Installing 1 of 1 - C:\ISO\drivers\nic\rt68x64.inf: The driver package was successfully installed.
The operation completed successfully.

What it means: WinPE will now attempt to load these drivers on boot, enabling network earlier.

Decision: If your deployment depends on SMB shares, PXE, or pulling answer files, NIC drivers in boot.wim
are mandatory. Don’t “we’ll plug in a USB later” your way into a production rollout.

Task 7: Verify the drivers are present after injection (trust, but verify)

cr0x@server:~$ dism /Image:C:\ISO\mount\boot /Get-Drivers /Format:Table
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Published Name      Original File Name  Inbox  Class Name
oem1.inf            e1d68x64.inf         No     Net
oem2.inf            iaStorVD.inf         No     SCSIAdapter
oem3.inf            iaStorAC.inf         No     SCSIAdapter
oem4.inf            iaVMD.inf            No     SCSIAdapter
oem5.inf            rt68x64.inf          No     Net

The operation completed successfully.

What it means: You have confirmation the image has the driver packages staged.

Decision: If the drivers appear but hardware still isn’t detected in Setup, you’re likely missing a related
dependency, injecting the wrong storage stack, or dealing with BIOS settings.

Task 8: Commit and unmount boot.wim

cr0x@server:~$ dism /Unmount-Wim /MountDir:C:\ISO\mount\boot /Commit
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Saving image
[==========================100.0%==========================]
Unmounting image
[==========================100.0%==========================]
The operation completed successfully.

What it means: Your changes are written back into boot.wim.

Decision: If DISM warns about pending operations or errors on unmount, do not proceed to ISO rebuild. Fix
the image state first, or you’ll ship a corrupted installer and become a cautionary tale.

Task 9: Mount install.wim for the edition you deploy and inject the same drivers

cr0x@server:~$ dism /Mount-Wim /WimFile:C:\ISO\src\sources\install.wim /Index:1 /MountDir:C:\ISO\mount\install
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Mounting image
[==========================100.0%==========================]
The operation completed successfully.

What it means: You’re editing the actual OS image that ends up installed.

Decision: If you deploy multiple indices, repeat for each. Yes, it’s tedious. No, you can’t skip it and
hope your task sequence always chooses the same edition forever.

Task 10: Add drivers to install.wim (storage + NIC)

cr0x@server:~$ dism /Image:C:\ISO\mount\install /Add-Driver /Driver:C:\ISO\drivers\storage /Recurse
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Searching for driver packages to install...
Found 3 driver package(s) to install.
Installing 1 of 3 - C:\ISO\drivers\storage\iaStorVD.inf: The driver package was successfully installed.
Installing 2 of 3 - C:\ISO\drivers\storage\iaStorAC.inf: The driver package was successfully installed.
Installing 3 of 3 - C:\ISO\drivers\storage\iaVMD.inf: The driver package was successfully installed.
The operation completed successfully.

cr0x@server:~$ dism /Image:C:\ISO\mount\install /Add-Driver /Driver:C:\ISO\drivers\nic /Recurse
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Searching for driver packages to install...
Found 1 driver package(s) to install.
Installing 1 of 1 - C:\ISO\drivers\nic\rt68x64.inf: The driver package was successfully installed.
The operation completed successfully.

What it means: The installed OS will have those drivers available at first boot.

Decision: If your first boot previously died with INACCESSIBLE_BOOT_DEVICE, this is the
primary mitigation: ensure the storage controller driver is in the OS image before it tries to boot.

Task 11: Validate driver signature state (don’t ship unsigned surprises)

cr0x@server:~$ pnputil /enum-drivers
Published Name: oem10.inf
Original Name: iaVMD.inf
Provider Name: Intel
Class Name: SCSIAdapter
Driver Version: 07/18/2024 20.0.0.1038
Signer Name: Microsoft Windows Hardware Compatibility Publisher

What it means: A reputable signer name typically indicates a properly signed package. Unsigned packages
are a gamble with Secure Boot and modern Windows policies.

Decision: If the signer is blank or “Unknown,” stop and find a signed release. If you must use unsigned
for a lab, treat it as a lab-only artifact.

Task 12: Commit and unmount install.wim

cr0x@server:~$ dism /Unmount-Wim /MountDir:C:\ISO\mount\install /Commit
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Saving image
[==========================100.0%==========================]
Unmounting image
[==========================100.0%==========================]
The operation completed successfully.

What it means: The installed OS image is now updated.

Decision: If the WIM file ballooned and you care about distribution size, plan an export/recompress step
(next task). But don’t get cute until you have a working installer.

Task 13: Re-export install.wim to clean up and optionally compress

cr0x@server:~$ dism /Export-Image /SourceImageFile:C:\ISO\src\sources\install.wim /SourceIndex:1 /DestinationImageFile:C:\ISO\src\sources\install.new.wim /Compress:max /CheckIntegrity
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Exporting image
[==========================100.0%==========================]
The operation completed successfully.

What it means: Exporting rewrites the image cleanly and can reduce fragmentation and size.

Decision: If you have multiple indices, export each and rebuild a consolidated WIM; otherwise you’ll ship a
media set where only one edition is fixed.

Task 14: Replace the old install.wim safely

cr0x@server:~$ move C:\ISO\src\sources\install.wim C:\ISO\src\sources\install.bak.wim
        1 file(s) moved.

cr0x@server:~$ move C:\ISO\src\sources\install.new.wim C:\ISO\src\sources\install.wim
        1 file(s) moved.

What it means: You keep a rollback copy. Always.

Decision: If you’re doing this as part of a release process, store the .bak outside the build
tree. Local rollbacks don’t help when someone “cleans up” the folder.

Task 15: Verify WIM health and integrity before you rebuild the ISO

cr0x@server:~$ dism /Cleanup-Wim
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

No mounted WIM images found.
The operation completed successfully.

What it means: No leftover mounts. This is good. Leftover mounts are how you ship half-written images.

Decision: If it reports mounted images you didn’t expect, investigate and clean up. Don’t rebuild the ISO
while DISM still thinks a mount is active.

Task 16: Build the bootable ISO with oscdimg (ADK)

cr0x@server:~$ oscdimg -m -o -u2 -udfver102 -bootdata:2#p0,e,bC:\ISO\src\boot\etfsboot.com#pEF,e,bC:\ISO\src\efi\microsoft\boot\efisys.bin C:\ISO\src C:\ISO\out\Win-Setup-Drivers.iso
OSCDIMG 2.56 CD-ROM and DVD-ROM Premastering Utility
Scanning source tree (100 files in 20 directories)
Computing directory information complete
Writing 100 files in 20 directories to disc
100% complete
Final image file is 5,123,456,000 bytes
Done.

What it means: You created a dual-boot (BIOS + UEFI) ISO with proper boot sectors.

Decision: If you only boot UEFI, you can simplify, but don’t unless you’re certain about fleet firmware.
“Certain” means asset data, not vibes.

Task 17: Quick validation—list drivers inside boot.wim without mounting (spot-check)

cr0x@server:~$ dism /Get-Drivers /Image:C:\ISO\mount\boot
Error: 2

The system cannot find the file specified.

What it means: This fails because the image is not mounted. That’s expected and it’s a reminder: DISM
queries require a mounted image path or a /WimFile + /Index workflow.

Decision: If you want a spot-check, mount read-only or mount again and verify. Don’t assume the last build
step did what you think it did.

Fast diagnosis playbook

When Windows Setup doesn’t “just work,” you need a deterministic triage order. Not because you’re impatient (you are),
but because the failure modes overlap and the wrong guess wastes the most time.

First: decide if it’s a storage enumeration failure or a controller-mode mismatch

Check BIOS/UEFI storage mode: AHCI vs RAID vs VMD. If VMD is enabled and you don’t have the VMD driver
in WinPE, Setup won’t see disks. If you switch modes after installing, Windows may not boot.
Check what hardware is present: NVMe behind VMD looks different than raw NVMe.

Second: confirm you injected into the correct WIM and index

Disk missing in Setup UI? That’s boot.wim index 2 nine times out of ten.
Disk visible during Setup but first boot fails? That’s install.wim.

Third: validate driver packaging and signature

Do you have INF-based drivers, not a setup executable?
Are they x64 for modern Windows builds?
Are they signed in a way that survives Secure Boot policies?

Fourth: watch for “media driver missing” red herrings

The dreaded “A media driver your computer needs is missing” often has nothing to do with USB drivers. It can be storage,
it can be a broken install.wim, it can be an ISO written badly to USB, and it can be Setup failing to read the source.

Fifth: reduce variables

Try a different USB stick.
Try a different USB port (USB-C hubs are chaos).
Try booting the ISO in a VM to confirm the media isn’t corrupt.

Quote (paraphrased idea): John Allspaw’s reliability message is that resilience comes from learning and adaptation, not from pretending failure won’t happen.

Common mistakes: symptoms → root cause → fix

These are the failures that keep showing up because they’re easy to do and annoying to spot.

1) Symptom: “No drives were found. Click Load driver…”

Root cause: Storage controller mode requires vendor driver (RST/VMD/RAID) not present in boot.wim index 2.
Fix: Inject the correct storage INF into boot.wim index 2 (and usually index 1 too). Verify with /Get-Drivers. Confirm BIOS mode didn’t change.

2) Symptom: Setup sees the disk, but Windows blue-screens on first boot (INACCESSIBLE_BOOT_DEVICE)

Root cause: Driver exists in WinPE (boot.wim) but not in the installed OS image (install.wim), or BIOS storage mode changed post-install.
Fix: Inject storage driver into the right install.wim index. Keep storage mode consistent from install through first boot.

3) Symptom: “A media driver your computer needs is missing” early in Setup

Root cause: Bad USB creation method, ISO corruption, missing storage driver, or Setup can’t read its own source due to flaky port/hub.
Fix: Recreate USB with a reliable tool, try another port, verify ISO hash, and inject storage drivers if the platform uses VMD/RAID.

4) Symptom: DISM says “No driver packages were found”

Root cause: You pointed DISM at a folder without .inf, or the driver is the wrong architecture.
Fix: Extract the driver package until you have the INF + SYS + CAT set. Confirm x64 drivers for x64 WinPE.

5) Symptom: Setup works, but no network in WinPE (can’t reach deployment share)

Root cause: NIC driver missing in boot.wim, or NIC is newer than the inbox drivers.
Fix: Inject NIC drivers into boot.wim index 2. Validate by booting and running ipconfig in WinPE if you can access a shell.

6) Symptom: Driver injects fine, but hardware still not detected

Root cause: Wrong driver variant (similar model, different PCI IDs), or BIOS hides device behind different controller mode.
Fix: Confirm PCI hardware IDs in a running OS or vendor inventory tooling; match them to the INF. Confirm firmware settings (VMD on/off, RAID on/off).

7) Symptom: Mount/unmount errors, “The image is in use,” or commits don’t stick

Root cause: Stale mounts, antivirus scanning mount paths, or interrupted DISM operations.
Fix: Run dism /Cleanup-Wim, use a clean mount directory, temporarily exclude mount paths from AV in a controlled build environment.

Three corporate mini-stories from the trenches

Mini-story 1: The incident caused by a wrong assumption

A company rolled out a batch of new laptops for engineers. The IT build team had a “known good” Windows ISO that had worked
for years on the previous hardware generation. They assumed NVMe is NVMe, Windows is Windows, and Setup would see the disk.

On day one, the helpdesk queue filled with the same screenshot: no disks. Someone suggested the USB sticks were bad, so they
re-imaged the sticks. Same failure. Someone else blamed Secure Boot and started toggling firmware settings like they were
trying to tune a radio.

The root cause was mundane: the OEM shipped the fleet with VMD enabled by default. That hid the NVMe devices behind a controller
layer that required Intel’s driver in WinPE. The “known good” ISO had no such driver because the old fleet didn’t need it.

The fix was to inject the correct VMD/RST drivers into boot.wim index 2 and rebuild the media, then standardize
the BIOS setting across the fleet. The postmortem takeaway was sharper: assumptions about “generic NVMe support” don’t survive
vendor controller abstraction. Hardware vendors are creative.

They ended up adding a preflight checklist: confirm storage mode, confirm PCI IDs, and confirm WinPE driver coverage. It wasn’t
glamorous. It stopped the bleeding.

Mini-story 2: The optimization that backfired

Another org wanted faster deployment. Someone had the bright idea to build a “universal installer ISO” with every driver pack
they’d ever used: chipset, GPU, audio, Wi‑Fi, storage, NICs, printers—yes, printers. Their thinking was: more drivers means
fewer surprises, and fewer surprises means faster installs.

In practice, the ISO grew fat. Boot.wim got so large that WinPE boot times increased noticeably, especially on older USB media.
Worse, some storage driver stacks overlapped. On a subset of servers, Setup intermittently loaded the “wrong” miniport first,
causing disks to appear and disappear across reboots. Intermittent failures are where your calendar goes to die.

Then came the compliance angle: they had no clean record of which drivers were inside, which versions, and which were still
supported. When a security team asked for provenance, the answer was basically “a folder of stuff.” That is not an answer.

The rollback wasn’t a rollback; it was a detox. They rebuilt media per hardware family: one ISO for the laptop line, one for
a specific server generation, one for a niche appliance. Smaller, targeted, verifiable. Deployment speed went up because
troubleshooting time went down.

Joke #2: A “universal driver ISO” is like a universal remote—great until it controls the wrong TV and you mute your own meeting.

Mini-story 3: The boring but correct practice that saved the day

A financial services team had a habit that looked tedious: every quarter they rebuilt their Windows deployment media in a clean
VM, injected only the storage and NIC drivers required for each platform class, and test-installed on one representative
machine per class. They kept a small changelog: driver version updated, reason, tested hardware model, and the date.

During a data center refresh, they received servers with a slightly different RAID controller revision than expected. The vendor
paperwork was ambiguous. It looked the same. It wasn’t.

Their first test install caught it immediately: no disks in Setup. Instead of discovering this in a midnight cutover window,
they discovered it on a Tuesday afternoon with coffee available and nobody paging anyone.

Because they had a controlled build process, the fix was straightforward: add the updated controller driver to the server ISO,
rebuild, rerun the test. The change was documented and easy to justify.

The boring practice—repeatable builds, minimal driver sets, and one sacrificial test install—saved the rollout. Nothing heroic.
No war room. Just fewer surprises.

Checklists / step-by-step plan

Checklist A: Before you touch DISM

Identify target hardware models and controller modes (AHCI/RAID/VMD).
Download driver packages that contain INF files for x64.
Separate drivers into storage and nic folders.
Extract packages until you can point DISM at folders containing .inf.
Decide which Windows edition index you deploy (install.wim index).

Checklist B: Injection steps you should actually follow

Extract ISO contents to C:\ISO\src.
Run dism /Get-WimInfo on boot.wim and install.wim.
Mount boot.wim index 2 to C:\ISO\mount\boot.
Add storage and NIC drivers with /Add-Driver /Recurse.
Verify with /Get-Drivers.
Commit/unmount.
Mount install.wim for the index you deploy.
Add the same drivers (at minimum the storage controller driver; usually NIC too).
Commit/unmount.
Optionally export/recompress the WIM.
Rebuild ISO with oscdimg.
Test boot and disk detection on representative hardware.

Checklist C: Acceptance tests (don’t skip these)

Setup sees the target disk without clicking “Load driver.”
Setup can see network if you depend on it (deployment share or answer file retrieval).
Windows completes first boot without storage-related BSOD.
Device Manager in the installed OS shows no unknown storage controller devices.
The ISO boots in UEFI on your newest platform and in legacy mode where required.

FAQ

1) Do I really need to inject drivers into both boot.wim and install.wim?

If you want Setup to see disks and also want the installed OS to boot reliably, yes—inject into both. Boot.wim gets you
through installation; install.wim gets you through first boot and beyond.

2) Which boot.wim index do I inject into?

Usually index 2 (Windows Setup). Many teams inject into both index 1 and 2 because it costs little and avoids surprises in
alternate boot paths.

3) I only have a vendor EXE. Can DISM inject that?

No. DISM injects driver packages via INF. Extract the EXE (often it’s just a wrapper) until you have .inf,
.sys, and .cat files.

4) Why does Setup say a “media driver is missing” when I’m clearly booting from USB fine?

That error message is vague. It can mean storage driver missing, source media unreadable, USB creation issues, or Setup failing
to access install.wim. Treat it as “Setup can’t read something it needs,” then narrow it down.

5) Can I just switch BIOS from RAID/VMD to AHCI and avoid drivers?

Sometimes, yes. But switching modes can break existing installs and might not match your organization’s standard. If this is a
fleet, standardize the firmware setting and build media accordingly. Random per-machine toggles don’t scale.

6) How do I handle install.esd instead of install.wim?

Convert or export it to WIM for servicing, inject drivers, then optionally compress back to ESD if you have a reason. If you
don’t have a reason, stick with WIM—it’s operationally friendlier.

7) Will Secure Boot block my injected drivers?

It can. Unsigned or improperly signed drivers may fail to load depending on policy and platform. Favor WHQL-signed packages
and validate signature metadata before shipping.

8) Should I inject chipset, GPU, audio, and all the “nice to have” drivers too?

Not into Setup media unless you have a specific WinPE need. For installation success, storage and NIC are the priority.
Everything else can be handled post-install via management tooling, driver deployment, or OEM packages.

9) How do I keep this maintainable across multiple hardware models?

Build per hardware family and keep driver sets minimal. Version your ISO artifacts, keep a changelog, and test on one
representative machine per family before promoting media to production use.

10) My injected driver is present in /Get-Drivers, but disks still don’t show. Now what?

Confirm you injected into the right index. Confirm firmware controller mode. Confirm the INF matches the hardware IDs. And
confirm the driver is compatible with the Windows build. At that point, you’re debugging platform reality, not DISM.

Next steps that keep you out of trouble

If you want Setup to “just work,” stop treating installation media as a one-off artifact and start treating it like a small,
controlled release. Inject the right drivers into boot.wim (Setup) and install.wim (installed OS),
rebuild with a proper toolchain, and test on real hardware.

Practical next steps:

Create a clean build VM and standard folder layout for ISO servicing.
Build a minimal driver pack per hardware family (storage + NIC first).
Automate the DISM mount/inject/commit workflow in a script and log every run.
Maintain a small changelog: what driver changed, why, and what you tested.
Run a quarterly test install on representative hardware to catch vendor “same model, different controller” surprises.

The goal isn’t to become a Windows image artisan. The goal is to stop discovering driver issues in front of an executive,
a customer, or a maintenance window timer.