DISM Driver Export: Offline Windows Reinstall Recovery Kit

Cloud Rebuild is not the answer for a no-internet reinstall. The Windows Insider Experimental feature can recover a non-booting PC without USB media by downloading Windows and drivers from Windows Update, but it requires an internet connection. If connectivity is unavailable—or if you simply want an offline fallback—the usable procedure is to export the working PC’s installed third-party driver packages before failure and restore matching packages after reinstalling Windows.
Run these commands from an elevated PowerShell window:

mkdir C:\DriverExport
dism /online /export-driver /destination:C:\DriverExport
pnputil /add-driver C:\DriverExport\*.inf /subdirs /install

The first two commands are run before reinstalling Windows. The third is run afterward, once the exported folder is available again. Before erasing or formatting the Windows partition, copy C:\DriverExport to a USB drive, protected secondary drive, or another location that the reinstall will not remove.
This procedure preserves third-party driver packages currently installed on the PC. It does not preserve Windows, applications, or personal files, and it should not be treated as a complete backup. It also may not reproduce every optional utility or management component originally supplied by the PC or hardware manufacturer.
For WindowsForum readers, the practical value is straightforward: the export becomes a pre-failure, offline bootstrap kit. It gives a clean Windows installation a local source for drivers matching the PC’s hardware, including the packages that may be needed before the machine can get back online and obtain anything else.
Quick walkthrough

Cloud Rebuild Offers Convenience, but It Still Requires Connectivity​

Cloud Rebuild is being evaluated as an Experimental feature in Windows Insider builds. The supplied description establishes a focused set of capabilities: it can work from a non-booting PC, it does not require USB installation media, and it downloads Windows and device drivers from Windows Update.
That combination could make recovery more convenient when the affected PC has internet access. Instead of preparing installation media on another computer and then locating drivers separately, the recovery process can retrieve both Windows and hardware support through Windows Update.
Its boundary is just as important as its benefit. Cloud Rebuild requires internet access, so it cannot serve as the offline answer when connectivity is unavailable. That does not make the feature ineffective; it simply means it belongs to one recovery path rather than replacing every other path.
The offline driver-export method addresses a narrower but common problem. It does not reinstall Windows by itself. Instead, it preserves the installed third-party driver packages that can help a conventional clean installation recognize and operate the machine’s existing hardware.
The two approaches are therefore complementary:

Recovery path	What it supplies	Internet required for the recovery step?	Main limitation
Cloud Rebuild	Windows and drivers downloaded from Windows Update	Yes	Not usable as a no-internet reinstall path
DISM export and PnPUtil import	Third-party driver packages exported from the existing installation	No	Does not reinstall Windows or preserve applications and files
Windows installation media plus exported drivers	A conventional Windows reinstall with a local driver source	No, if both are already prepared	Requires advance preparation and safe storage

The useful distinction is simple. Cloud Rebuild can reduce the need to prepare local media when internet access is available. An exported driver archive provides continuity when an administrator or home user needs to proceed offline.
There is no need to turn that distinction into a contest between cloud and local recovery. A prepared PC can have both options: Cloud Rebuild for an eligible, connected recovery and installation media plus exported drivers for an offline fallback.

The Existing Driver Store Can Become a Recovery Asset​

As Neowin highlighted in its walkthrough, Windows includes built-in command-line tools that can turn a working installation’s third-party driver collection into a portable recovery resource.
DISM, short for Deployment Image Servicing and Management, performs the export. With the /online option, the command operates on the currently running Windows installation. The /export-driver operation copies its installed third-party driver packages to the chosen destination.
PnPUtil performs the post-installation import. Pointed at the exported INF files, it adds drivers from the archive and installs those matching the current hardware.
This is valuable because a clean Windows installation and a fully functional PC are not always the same thing. Windows may boot successfully while one or more components still need an appropriate driver package. An offline archive gives the rebuilt installation a local collection drawn from the PC’s previously working configuration.
The archive is hardware-oriented rather than a replacement for a system image. It does not contain the operating system, installed programs, account configuration, documents, browser data, or other personal content. Those items require their own backup or restoration plan.
It is also important to describe the export accurately. The procedure preserves third-party driver packages currently installed in Windows. It should not be represented as a complete copy of everything an OEM installation may have included. Optional applications, control interfaces, support tools, or other manufacturer additions may need to be installed separately if they are required after recovery.
That narrower scope is still useful. During an offline reinstall, the immediate goal is often to restore enough hardware functionality to make the PC usable and, where possible, reconnect it to the normal update and support channels. A local driver archive is designed for that stage of recovery.

Export the Drivers While the PC Is Healthy​

The best time to create the archive is before the machine fails. Waiting until a PC is unstable, unbootable, or already being erased turns a simple preventive step into a much more difficult recovery task.
Begin with a system whose essential hardware is functioning as expected. If the machine is already experiencing a suspected driver fault, treat any export from that installation as a troubleshooting resource rather than an automatically trusted baseline.
Open PowerShell with administrator rights. One quick method is to open Start, type powershell, and press Ctrl+Shift+Enter. Accept the User Account Control prompt.
Create the destination folder:
mkdir C:\DriverExport
Then export the installed third-party driver packages:
dism /online /export-driver /destination:C:\DriverExport
The /online option identifies the currently running Windows installation as the source. The destination identifies the folder that will receive the exported packages.
Once DISM finishes, inspect C:\DriverExport and confirm that it contains exported folders and files. Do not stop at that point. The folder is still on the Windows partition, which means it remains inside the area that may be erased during a clean installation.
Copy the complete DriverExport folder to one of the following:

• A USB flash drive
• A USB hard drive or SSD
• A protected secondary internal drive that will not be formatted
• A trusted network location while the PC is still connected
• Another backup destination that will remain accessible after reinstalling Windows

For the simplest offline recovery kit, place the driver archive on the same external drive used to hold Windows installation media, provided there is enough space and the files are kept in a clearly labeled folder.
Before beginning the reinstall, disconnect and reconnect the external drive or browse the protected destination to verify that the copied archive is actually present. Confirm that the destination contains the exported files rather than an empty folder, a shortcut, or only the original path on C:.
This verification step matters more than the elegance of the command. An export left exclusively on the partition being erased is not a backup.

Label the Archive for the Machine It Supports​

A driver folder is most useful when the person handling recovery can identify it quickly. A generic directory named DriverExport may be sufficient for one household PC, but it becomes ambiguous when several computers are involved.
Consider storing the folder under a descriptive name such as:

DriverArchives\
  Office-Laptop_2026-03\
  Workshop-PC_2026-03\
  Family-Desktop_2026-03\

The label can include the device name, manufacturer and model, asset tag, or export date. Avoid relying only on a person’s name if device ownership may change.
A small text file stored beside the archive can record:

• The device or asset name
• The PC manufacturer and model
• The date of export
• The Windows edition in use when the export was created
• Whether essential hardware was tested at the time
• Any known driver-related issue that should affect restoration decisions

These notes do not alter the packages, but they make the archive more understandable months later. They are particularly useful if a technician other than the person who created the export performs the recovery.
This is also where practical caution is appropriate. Two PCs with similar names or outward appearances do not necessarily have identical internal components. Do not assume that an archive from one machine should automatically be bulk-imported into another merely because both belong to the same product line.
For a single PC, a device-specific archive is the clearest option. For several PCs, administrators may choose to organize tested archives by device or verified hardware configuration. That is an operational choice rather than a guarantee about interchangeability, so archives should be labeled according to what has actually been checked.

Restore Matching Drivers After Windows Is Reinstalled​

After completing the Windows installation, reconnect the drive containing the archive. You can run PnPUtil directly against that location or copy the folder back to C:\DriverExport.
Open an elevated PowerShell window and run:
pnputil /add-driver C:\DriverExport\*.inf /subdirs /install
If the archive is still on an external drive, change the path accordingly. For example, if the folder is at E:\DriverExport, use:
pnputil /add-driver E:\DriverExport\*.inf /subdirs /install
The wildcard tells PnPUtil to process INF files. The /subdirs option includes INF files stored in the archive’s nested directories. The /install option imports and installs drivers matching the current hardware.
The supported point here is intentionally limited: the command imports drivers from the archive that match hardware in the current PC. It is not necessary to make broader claims about driver-ranking behavior or how every package will interact with drivers already supplied by Windows.
Once the command finishes, restart the computer if Windows requests it. Even when no restart prompt appears, a planned restart can provide a clear point at which to begin verification.
Then test the hardware that matters on that PC:

• Wired and wireless networking
• Display output and expected resolutions
• Keyboard, mouse, touchpad, and touch input
• Audio playback and recording
• Bluetooth
• Cameras
• Card readers
• USB ports
• Docks and external displays
• Printers or specialized peripherals
• Sleep, wake, and other routinely used device functions

Open Device Manager and look for warning icons or devices that are not operating as expected. Do not interpret completion of the PnPUtil command as proof that every hardware feature has been restored. The archive provides matching third-party driver packages that were present in the source installation; verification remains a separate recovery step.
If internet access is available after the import, run Windows Update and check the PC manufacturer’s support process for any additional components you actually need. The exported archive is an offline starting point, not a reason to avoid later maintenance.

Do Not Confuse Driver Restoration With Full-PC Restoration​

The procedure is deliberately focused. It protects one layer of a Windows installation: the installed third-party driver packages.
It does not preserve:

• The Windows installation itself
• Installed desktop applications
• Microsoft Store application state
• Personal documents and media
• User profiles
• Browser data that has not been synchronized or backed up
• Application settings
• Product keys or subscription credentials that require separate records
• A complete copy of an OEM factory environment

That means a proper recovery plan still needs a file backup and, when appropriate, Windows installation media. Users should also retain installers, licenses, account-recovery information, encryption recovery keys, and any specialized application data required to resume work.
Optional OEM software deserves qualified treatment. A manufacturer may provide utilities or supporting components in addition to core drivers. Because the DISM operation is a third-party driver-package export, users should not assume that every optional manufacturer feature will return through the archive. If a particular utility is important, preserve its installer separately or document where it can be obtained.
The same principle applies to specialized peripherals. If a device relies on a larger software package, configuration database, plug-in, or application, preserving its driver may restore basic recognition without recreating the full workflow. Back up those additional materials according to the vendor’s instructions.
This limitation does not reduce the value of the driver archive. It defines that value correctly. The archive helps bridge the gap between a newly installed copy of Windows and a PC whose hardware is ready for normal use.

A Driver Archive Is a Snapshot, Not a Quality Guarantee​

DISM exports packages that are installed. It does not determine whether each package is the best possible choice for a future installation.
If the source system contains a problematic third-party driver, the archive may preserve that package along with the drivers that are working correctly. The method is therefore most dependable when the export is created from a stable configuration rather than in the middle of investigating crashes, device resets, display corruption, audio failures, or connectivity problems.
When the reinstall is unrelated to driver stability, a bulk import may be a convenient way to restore hardware support. When a driver is among the suspected causes of the incident, use the archive more cautiously.
A practical troubleshooting approach is:

1. Complete the Windows installation.
2. Observe which hardware functions without importing the old archive.
3. If connectivity works, allow the normal Windows update process to establish a baseline.

4. Use the archive for hardware that remains unsupported or does not function correctly.
5. Test after each significant change if a particular driver category is under suspicion.
That selective approach can take longer than importing the entire archive at once, but it gives the troubleshooter more information about which restored package affects the system.
The archive also cannot supply a package that was not installed when the export was created. If a device was already unsupported or incorrectly configured, exporting the current driver store does not guarantee that the missing solution will appear later. The archive preserves what was present; it does not manufacture absent support.
For that reason, perform the initial export after confirming that the machine’s essential hardware works. If a feature is already missing, resolve it before treating the archive as a known-good recovery kit—or record the limitation clearly in the notes stored with it.

Keep the Comparison Short and Practical​

Cloud Rebuild and offline driver export solve different parts of recovery.
Cloud Rebuild can download Windows and drivers from Windows Update on a non-booting PC without requiring USB installation media. It requires internet access and is being evaluated as an Insider Experimental feature.
DISM and PnPUtil do not replace the Windows installation process. They let a user preserve installed third-party driver packages in advance and make matching packages available locally afterward.
The practical order is therefore:

• If Cloud Rebuild is available for the machine and internet access is working, it may provide the more direct recovery path.
• If an offline reinstall is required, use prepared Windows installation media.
• After that reinstall, use the exported driver archive to restore matching third-party driver packages.
• Once the PC is functional and connected, complete updates and install any additional manufacturer components that are actually needed.

The strongest plan keeps more than one path available. Cloud recovery is convenient when connectivity exists. Offline installation media and a verified driver archive remain useful when it does not.

A Concise Tested Recovery Workflow​

The commands are easy to copy, but a useful recovery kit must be prepared, stored, and tested. WindowsForum readers can use the following workflow without turning driver backup into a larger imaging project.

Before failure​

1. Confirm that the PC’s essential hardware is working.
2. Open PowerShell as administrator.
3. Create the export folder:
   mkdir C:\DriverExport
4. Export the installed third-party driver packages:
   dism /online /export-driver /destination:C:\DriverExport
5. Inspect the export and verify that files were created.
6. Copy the complete folder away from the Windows partition.

7. Label the archive with the device and export date.
8. Keep Windows installation media available if offline recovery is part of the plan.
9. Maintain a separate backup of personal files and other required data.

During recovery​

1. If Cloud Rebuild is available and the PC has internet access, decide whether that connected recovery path fits the situation.
2. If the reinstall must be performed without internet, use prepared Windows installation media.
3. Do not erase the only copy of the driver archive.
4. Complete Windows Setup.
5. Reconnect the protected drive containing DriverExport.
6. Open PowerShell as administrator.
7. Import matching drivers:
   pnputil /add-driver E:\DriverExport\*.inf /subdirs /install
8. Replace E: with the actual drive letter.
9. Restart if required.
10. Test networking, input, display, audio, Bluetooth, ports, and any essential peripherals.
11. Review Device Manager for warnings or unexpected behavior.
12. After connectivity is restored, run Windows Update and obtain any additional required manufacturer software.

If the original problem may have involved a driver​

1. Complete Windows Setup without immediately importing the entire archive.
2. Record which devices already work.
3. Restore only the drivers needed for missing or malfunctioning hardware.
4. Test between changes.
5. Avoid treating the old snapshot as automatically preferable merely because it came from the previous installation.

This workflow keeps the purpose of the archive clear. It is not a complete system backup and not a promise that every optional feature will return. It is a local collection of installed third-party driver packages that can make an offline rebuild faster and more controlled.

Action Checklist for WindowsForum Administrators​

• [ ] Confirm the source PC is stable enough to serve as a recovery baseline.
• [ ] Run the DISM export while Windows is still operational.
• [ ] Verify that C:\DriverExport contains exported packages.
• [ ] Copy the archive off the Windows partition before formatting or erasing it.
• [ ] Label the archive with the correct device, model, asset tag, or validated configuration.
• [ ] Store the archive with or near the appropriate Windows installation media.
• [ ] Maintain personal-file and application-data backups separately.
• [ ] Record any known driver problem present at the time of export.
• [ ] Test the PnPUtil command and essential hardware where practical.
• [ ] Check Device Manager and real device functionality after restoration.
• [ ] Use Windows Update after connectivity returns.
• [ ] Preserve separate installers for optional utilities or specialized software that the driver export may not contain.
• [ ] Keep Cloud Rebuild as a connected recovery option rather than treating it as the no-internet fallback.

The Best Recovery Kit Is Created Before It Is Needed​

Cloud Rebuild points toward a convenient recovery path for eligible Windows Insider test systems that can reach Windows Update. Its ability to operate from a non-booting PC without USB media is significant, but the internet requirement defines where it can help.
For a no-internet reinstall, the immediate answer is still local preparation: Windows installation media, a separate backup of important data, and an exported collection of the PC’s installed third-party drivers.
The three-command procedure is simple enough to perform now:

mkdir C:\DriverExport
dism /online /export-driver /destination:C:\DriverExport
pnputil /add-driver C:\DriverExport\*.inf /subdirs /install

Only the first two commands belong to the pre-failure export stage, and the folder must be copied somewhere safe before the Windows partition is erased. The final command belongs to the post-installation stage and imports drivers from the restored archive that match the current hardware.
The enduring WindowsForum lesson is not that one recovery method defeats another. It is that a working PC already contains material that may be difficult to obtain during an offline failure. Exporting that material while the machine is healthy turns it into a compact bootstrap kit—one that can help a fresh Windows installation restore hardware support first and reconnect to the wider update process afterward.

---

References​

1. Primary source: Neowin
   Published: 2026-07-12T20:00:01+00:00
   
   

   How to keep your drivers when reinstalling Windows (no internet connection needed) | Neowin

   If you're reinstalling Windows, and you don't want to go through the hassle of bringing all your drivers back, check out how to keep them with a few simple commands.

   www.neowin.net
2. Related coverage: windowscentral.com
   
   

   Windows 11 will soon be able to reinstall itself and your drivers without a USB drive via new 'Cloud Rebuild' recovery method | Windows Central

   A new recovery option coming to Windows 11 will let you reinstall the OS and your drivers using the internet without a USB key, even when Windows itself is unbootable.

   www.windowscentral.com
3. Related coverage: techradar.com
   
   

   Microsoft's new tool will let you rebuild a dead PC without a physical copy of Windows | TechRadar

   Cloud Rebuild lets you download Windows without a bootable USB

   www.techradar.com
4. Official source: learn.microsoft.com
   
   

   Cloud rebuild (Preview) | Microsoft Learn

   IT Pro documentation for the Cloud rebuild feature in Windows 11

   learn.microsoft.com
5. Related coverage: cincodias.elpais.com
   
   

   Windows 11 pronto permitirá recuperar tu PC desde la nube, incluyendo los controladores | Lifestyle | SmartLife | Cinco Días

   El proceso será extremadamente sencillo, ya que los pasos a realizar estarán completamente automatizados en el sistema operativo.

   cincodias.elpais.com