How to list and manage drivers from PowerShell in Windows

In Windows environments, monitoring which drivers are installed and their versions is crucial for maintaining system stability, troubleshooting blue screens, and preparing for migrations. PowerShell has become an extremely convenient tool for performing this type of inventory without having to manually check each driver in Device Manager.

In the following lines you will see how to list drivers from PowerShell in several ways, how to export them to files for further analysis, what the differences are with other commands such as driverquery or graphical tools, and even how to handle more advanced scenarios such as offline images or dynamically loaded drivers.

What is a driver and why would you want to list it from PowerShell?

In Windows, a driver is a small piece of software that acts as an intermediary between the operating system and a hardware component (graphics card, chipset, storage , USB peripherals , etc.). Although the code they occupy is not enormous, their impact on system stability is huge.

When a critical driver (for example, storage, network, graphics, or chipset ) malfunctions, it can cause crashes, performance issues, and even blue screens of death ( BSODs ) . That's why having a clear list of installed drivers and their versions is so useful when you're troubleshooting or preparing for a major update.

Before you rush to change, uninstall, or roll back drivers, it's a good idea to minimize risks by creating a system restore point . This way, you can revert to the previous state if a driver update goes wrong and your computer starts behaving strangely or won't even boot correctly.

In addition to the restore point, it's advisable to back up important data (documents, photos, work projects, etc.), especially if you're going to modify storage drivers, as a mistake can prevent the system from mounting the drives correctly or corrupt information.

Basic command in PowerShell to list installed drivers

The most direct way to obtain a controller inventory from PowerShell is to use WMI . One of the most commonly used commands is:

Get-WmiObject Win32_PnPSignedDriver | Select DeviceName, DriverVersion

With this cmdlet, PowerShell queries the WMI Win32_PnPSignedDriver class and returns a list of signed PnP drivers, along with the device name and the driver version that the system currently has associated with it.

If you want a little more context about each driver, you can add fields such as the friendly name, the release date, or the manufacturer . For example:

Get-WmiObject Win32_PnPSignedDriver | Select DeviceName, FriendlyName, Manufacturer, DriverVersion, DriverDate

With this query, you will obtain much more complete information for each entry , allowing you to detect old versions, specific manufacturers, or drivers that have not been updated for years.

How to export the driver list to a file (TXT or CSV)

In real-world environments, simply viewing the list on screen is rarely sufficient. The most convenient approach is to export the results to a file for analysis in Excel, share them with the team, or keep them as a snapshot of the system's state before making any changes, such as removing outdated drivers.

If you only need a quick plain text listing, you can redirect the output to a file:

Get-WmiObject Win32_PnPSignedDriver | Select DeviceName, DriverVersion > C:\drivers.txt

This command creates a C:\drivers.txt file with a simple list of devices and versions. Ideal for quick reference or for attaching to a report without overcomplicating things.

When you're looking for something more manageable for filtering and sorting, CSV and the Export-CSV cmdlet are the way to go . A very common example would be:

Get-WmiObject Win32_PnPSignedDriver | Select DeviceName, FriendlyName, DriverVersion, DriverDate | Export-CSV -Path "./MisDrivers.csv" -NoTypeInformation

With this command, a file called MisDrivers.csv will appear in the current directory, which you can open in Excel or any spreadsheet program to sort by version, filter by driver date, search for specific manufacturers , etc.

Although you might sometimes read that PowerShell "doesn't allow exporting" the driver list, you can actually export it perfectly well using output redirection or Export-CSV, as you just saw. Then you can copy, paste, or work with that information wherever you want.

Filter drivers by manufacturer, name, or specific text

Typically, you won't want to see all drivers at once, but rather focus on a specific manufacturer or device type. To do this, you can chain filters using Where-Object on the properties of each driver.

For example, if you're interested in keeping only the Intel drivers , you could do something as simple as:

Get-WmiObject Win32_PnPSignedDriver | Select DeviceName, DriverVersion | Where-Object { $_.DeviceName -like "*Intel*" }

This command iterates through all entries returned by WMI and keeps only those whose device name contains the string "Intel" . Using the asterisk as a wildcard allows you to search for partial matches anywhere in the text.

The same idea applies to locating drivers related to a specific application or type of hardware, for example, to update USB drivers . If you know part of the name, the manufacturer, or some pattern in the path, you can adapt the filter to the most convenient property in each case.

View drivers from Device Manager and other Windows tools

Although PowerShell is very powerful for automating and exporting lists, Windows still offers classic graphical tools for managing drivers that are worth knowing and combining with the command-line approach.

The first place to look is Device Manager , accessible by right-clicking on "This PC" and choosing "Manage," or more quickly via the Start button's context menu (Windows + X). There you'll see a tree with all the hardware categories installed on the system.

Devices that have installation or operational problems usually appear with a yellow warning icon . Double-clicking on any of them opens the properties window, where you can check the device status and access the "Driver" tab.

Within that tab, you'll find options such as "Driver Details," "Update Driver," "Roll Back Driver," "Disable," or "Uninstall ." These actions allow you to view the driver files, search for newer versions, revert to a previous version, disable the device without removing it, or completely remove the driver from the system, respectively.

In addition to these tools, Windows includes the command driverquery to use from the symbol of the system (CMD). Running driverquery You will get a list of all installed drivers, and with driverquery /v You'll see more detailed information, such as memory usage, build date, or status.

driverquery and its relationship with PowerShell

The `driverquery` command is very flexible and allows you to view different aspects of driver status . For example, if you want to list only signed drivers in more detail, you can run:

driverquery /si

This mode shows signed drivers with additional useful information for security audits or integrity checks. And you can always consult driverquery /? to see all available parameters and adjust the output to your needs.

One of the advantages of driverquery is that you can integrate it with PowerShell using ConvertFrom-CSV . If you generate the output in CSV format and pipe it through the command line, you'll obtain objects that can be manipulated from PowerShell. A classic example would be:

driverquery.exe /v /fo csv | ConvertFrom-CSV | Select-Object "Display Name", "Start Mode", "Paged Pool(bytes)", Path

This combines the power of driverquery with PowerShell's data manipulation capabilities , allowing you to select only the columns you need: display name, startup mode, paged memory, and driver path on disk. This is useful when you want to filter by specific types, such as graphics drivers.

It's important to note that both `driverquery` and certain standard WMI queries primarily focus on drivers registered with the system , many of which are loaded at startup or managed through the registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services. Some drivers that are dynamically injected at runtime may not appear in these lists.

List drivers from PowerShell with Get-WindowsDriver

For more advanced scenarios, especially when working with offline Windows images (mounted WIMs, for example), the Get-WindowsDriver cmdlet , which is part of the DISM tools accessible from PowerShell, is very useful.

This cmdlet allows you to display information about driver packages for both the running Windows installation and an image mounted in a folder. The main syntax is divided into two main modes of use: offline and online.

For an offline image mounted in a folder , the general format would be:

Get-WindowsDriver -Path "C:\offline"

And to work against the running system, you would use the -Online parameter :

Get-WindowsDriver -Online

Without any additional parameters, Get-WindowsDriver returns a list of third-party drivers present in the image. If you add the -All switch , you will also see default drivers included by default in Windows.

Key parameters of Get-WindowsDriver

One of the most important parameters is `-Driver` , which lets you specify a particular .inf file or folder of .inf files to get detailed information about those drivers. If you specify a folder, .inf files that are not valid driver packages are automatically ignored.

When working with an offline image, the -Path parameter specifies the root path of the mounted image. If the Windows folder isn't at that root level, you can use -WindowsDirectory to specify the relative subfolder where it's located.

The -SystemDrive parameter is used in more specific scenarios, such as when working from Windows PE and the boot manager is on a different partition. In these cases, it specifies the drive containing the BootMgr files that should be served.

Regarding the activity log, the parameter -LogPath It lets you define the full path to the log file. If you don't adjust it, the default path is used. %WINDIR%\Logs\Dism\dism.logor in Windows PE, the scratch space in RAM. Meanwhile, -LogLevel determines the verbosity of the log, with values ​​ranging from just errors to including debugging information.

Finally, the -ScratchDirectory parameter specifies the temporary folder where files are extracted during service operations. It must be a local path, and once the operation is complete, the temporary files are automatically deleted to avoid leaving any traces.

Practical examples with Get-WindowsDriver

To quickly see all the drivers for your current Windows installation, you can run:

Get-WindowsDriver -Online -All

This command will display all drivers (both system and third-party) present in the running image. It's a very straightforward way to see which packages are installed without using WMI or Device Manager.

If you're working with an image mounted in C:\offline and only want to check third-party drivers, you could do the following:

Get-WindowsDriver -Path "C:\offline"

If you want a detailed report of a specific OEM driver within that image, simply specify the .inf file:

Get-WindowsDriver -Path "C:\offline" -Driver "OEM1.inf"

You can even access an .inf file located in a specific driver path, for example:

Get-WindowsDriver -Path "C:\offline" -Driver "C:\drivers\Usb\Usb.inf"

In all these cases, Get-WindowsDriver returns objects that you can pipe to Select-Object, Where-Object, or Export-CSV to filter, sort, or export the information to the format that best suits your needs.

PowerShell and SCCM: Get-CMDriver for driver catalogs

When managing a corporate environment with Configuration Manager (SCCM) , you're not only interested in the drivers on each computer, but also in the centralized catalog of drivers that SCCM maintains for deploying images and packages.

In this context, the Get-CMDriver cmdlet comes into play , which is used to retrieve information about device drivers managed by Configuration Manager . This cmdlet has several signatures depending on what you want to query: by name, by numeric identifier, by driver package, or by administrative category.

The basic syntax includes variants such as:

Get-CMDriver

Get-CMDriver -DriverPackageId <String>

Get-CMDriver -DriverPackageName <String>

Get-CMDriver -Id <Int32>

Get-CMDriver -InputObject <IResultObject>

With these parameters you can direct your queries to the SCCM catalog, filtering by driver name, identifier, associated packages or administrative categories that you have defined to organize your drivers.

Examples with Get-CMDriver

If you know the name of a specific driver, for example "Surface Serial Hub Driver", you can obtain its details with:

Get-CMDriver -Name "Surface Serial Hub Driver"

When you need to check several drivers that share the same prefix in their name (like the entire Surface driver family) and you only want to see some relevant properties, you can use something like:

Get-CMDriver -Fast -Name "Surface*" | Select-Object LocalizedDisplayName, DriverVersion, DriverDate

The -Fast modifier reduces the amount of information retrieved and speeds up the query, which is quite noticeable in large catalogs. Then, with Select-Object, you keep only the columns that are useful for your analysis.

If you manage administrative categories (for example, a "Surface" category where you group all those controllers), you can chain category and driver retrieval like this:

$category = Get-CMCategory -Name "Surface"
Get-CMDriver -Fast -AdministrativeCategory $category

In this case, you first store the category in a variable and then ask Get-CMDriver to return all the controllers associated with that category , which is very useful for maintaining logical views of your controllers in SCCM.

Limitations when listing dynamically loaded drivers

Not all drivers behave the same. There are tools, such as some from the Sysinternals suite (for example, Process Explorer or handle.exe) , that dynamically inject drivers into the kernel when they run, without registering them as traditional services loaded at startup.

A typical example is the driver procexp152.sys (or earlier versions such as procexp113.sys), associated with Process Explorer. This type of driver may not appear in standard queries of Get-WmiObject Win32_SystemDriversince these queries rely on information from registry services (CurrentControlSet\Services) and usually reflect mainly drivers that are loaded with the system.

Similarly, driverquery may not list all dynamically injected drivers , so if you're debugging BSODs or anomalous behavior caused by third-party tools that load their own drivers, you may need to resort to other methods.

These alternatives include examining kernel memory dumps with tools like WinDbg, or using utilities like verifier.exe . The driver verifier lets you select drivers to monitor and detect unstable behavior, but the graphical interface offers more enumeration options than the command-line version, which focuses on querying and configuring verification.

In short, for general inventory and most administrative needs, PowerShell, WMI, and Get-WindowsDriver cover the bases very well , but in extreme cases of debugging hot-loaded drivers, you will need to supplement with kernel analysis tools.

Update drivers with PowerShell using PSWindowsUpdate

In addition to listing drivers, many administrators use PowerShell to automate driver updates via Windows Update and also to update sound drivers . One common method is through the PSWindowsUpdate module, which extends the standard update cmdlets.

The usual process involves temporarily enabling the execution of signed scripts , installing the module, and then requesting driver updates directly from Microsoft servers.

A typical set of commands might be:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
Install-Module PSWindowsUpdate
Import-Module PSWindowsUpdate
Get-WindowsUpdate
Get-WindowsUpdate -MicrosoftUpdate -Category Driver -Install -AutoReboot

This sequence enables script execution for the current session, installs and imports the PSWindowsUpdate module, checks for available updates , and finally requests installation from the "Driver" category via Microsoft Update, allowing the system to restart automatically if necessary.

You can also broaden the scope by using a command that installs all updates detected from Microsoft Update and restarts without intervention, for example:

Get-WindowsUpdate -MicrosoftUpdate -Install -AutoReboot

This approach is especially practical in large fleets of equipment , where you want to standardize driver versions without going one by one. However, it's always advisable to combine it with a thorough prior inventory of drivers and, in critical environments, test in a pilot group before deploying to the entire organization.