How to list and manage drivers from PowerShell in Windows

In Windows environments, control which drivers are installed and what version each one has It's key to maintaining system stability, troubleshooting blue screens, or preparing for migrations. PowerShell has become an incredibly convenient tool for performing this type of inventory without having to go through Device Manager one by one.

In the following lines you will see How to list controllers from PowerShell in various ways, and how to export them to files to analyze them calmly, what differences there are with others commands , the 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 controller or driver is a small block of software that acts as an intermediary between the operating system and a component of hardware (graphics card, chipset, storageperipherals USBetc.). Although the code they occupy is not enormous, their impact on system stability is gigantic.

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

Before you rush to change, uninstall, or roll back drivers, it's a good idea minimize risks with a system restore pointThis way you can revert if a driver update goes wrong and the computer starts behaving strangely or doesn't even boot correctly.

In addition to the restaurant, it is advisable back up important data (documents, photos, work projects, etc.), especially if you are going to touch storage drivers, since a mistake can cause the system to not mount 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 rely on WMIOne of the most commonly used commands is:

Get-WmiObject Win32_PnPSignedDriver | Select DeviceName, DriverVersion

With this cmdlet, PowerShell queries the Win32_PnPSignedDriver WMI class and returns a list of the 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 like the friendly name, publication date, or manufacturer. For example: uterine

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

With this consultation, you will obtain Much more complete information for each entryThis allows you to detect older versions, specific manufacturers, or drivers that haven't been updated in years.

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

In real-world settings, simply viewing the list on screen is rarely sufficient. The most convenient approach is... save the result to a file to analyze it in Excel, share it with the team, or keep it as a snapshot of the system's state before making any changes, for example, before delete old 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

That command creates a file C:\drivers.txt with a simple device and version listing. Ideal for quick reference or attaching to a report without too much hassle.

When you're looking for something more manageable for filtering and sorting, the best option is to use CSV and the Export-CSV cmdletA 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 named MyDrivers.csv which you can open in Excel or any spreadsheet program to sort by version, filter by driver date, search for specific manufacturers, etc.

Although it is sometimes said that PowerShell "does not allow exporting" the driver list, in reality Yes, it can be exported perfectly. 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

Normally, you won't want to see all the drivers at once, but rather focus on a specific manufacturer or device type. For that, you can chaining filters with Where-Object about the properties of each driver.

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

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

This command iterates through all the entries returned by WMI and It only maintains 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 can be used to locate drivers related to a specific application or type of hardware, for example for update USB driversIf you know part of the name, the manufacturer, or some pattern of the route, you can adapt the filter to the most comfortable 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 controllers which should be known and combined with the command path.

The first reference point is the Device administratorThis can be accessed by right-clicking on "This PC" and choosing "Manage," or more quickly using the context menu of the Start button (Windows + X). There you will see a tree with all the hardware categories installed on the system.

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

Within that tab you will 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 new versions, revert to a previous version, disable the device without removing it, or completely remove the driver from the system.

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 View different views of the driver statusFor 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-CSVIf you generate the output in CSV format and pipe it, 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

With this you combine The power of driverquery with PowerShell data manipulationSelecting only the columns you're interested in: 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 should be noted that both driverquery and certain standard WMI queries focus primarily on drivers registered in the system, many of them loaded into the Boot 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 Windows offline images (for example, mounted WIMs), the cmdlet is very useful Get-WindowsDriver, which is part of the DISM tools accessible from PowerShell.

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.

In the offline image mounted in a folderThe general form would be:

Get-WindowsDriver -Path "C:\offline"

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

Get-WindowsDriver -Online

Without additional parameters, Get-WindowsDriver returns the list of third-party drivers present in the image. If you add the modifier -AllYou'll also see default drivers included by default in Windows.

Key parameters of Get-WindowsDriver

One of the most important parameters is -Driverwhich allows you to specify a specific .inf file or a folder of .inf files To obtain detailed information about those drivers. If you point to a folder, .inf files that are not valid driver packages are automatically ignored.

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

Parameter -SystemDrive It 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 serves to specify 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 parameter -Scratch Directory This is 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 They are automatically removed to leave no residue.

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 direct way to see which packages are installed without using WMI or Device Manager.

If you are working with a image mounted in C:\offline And if you 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 which you can pipe to Select-Object, Where-Object or Export-CSV to filter, sort or export the information to the format that best suits you.

PowerShell and SCCM: Get-CMDriver for driver catalogs

When you manage 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 that context, the cmdlet comes into play. Get-CMDriver, That works for Retrieve information from device drivers managed by Configuration ManagerThis 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 controllers.

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 modifier -Fast It reduces the amount of information retrieved and speeds up the query, which is quite noticeable in large catalogs. Then, with Select-Object, You only keep the columns that are useful to you 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 it to you all controllers associated with that category, something 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 in the suite. Sysinternals (for example, Process Explorer or handle.exe)which dynamically inject drivers into the kernel when they are executed, 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 driversSo if you're debugging BSODs or anomalous behavior caused by third-party tools that load their own drivers, you may have to resort to other methods.

Among those alternatives are to examine memory dumps of the kernel with tools like WinDbg, or use utilities like verifier.exeThe driver verifier allows you to select drivers you want 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 a general inventory and for most administrative needs, PowerShell, WMI, and Get-WindowsDriver cover the bases very well.However, 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 for update sound driversOne commonly used method is through the PSWindowsUpdate module, which extends the standard update cmdlets.

The usual flow passes through temporarily enable the execution of signed scriptsInstall the module and then request 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, You check what updates are available. And finally, you request that they be installed 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 way of working is especially practical in large team parksThis is where you want to standardize driver versions without going one by one. However, it's always advisable to combine this with a good prior inventory of drivers and, in critical environments, test in a pilot group before deploying to the entire organization.