Detecting Hardware

Determining what hardware is available on a computer

This section details ways to get information from the hardware. Specific solutions may have details about finding out whether the hardware is supported by the operating system (or some similar task, such as displaying a list of all hardware which is detected but which is not currently being supported by any actively running drivers for the operating system).

Note that this is mostly a section about generalized approaches to successfully find out what hardware is available. These sorts of approaches may also be useful in finding out specific details about the hardware, such as whether a detected piece of equipment supports a specific feature. Starting out with these generalized approaches will often work suitably and so may be the best approach/habit to be using over the long run. More specific details, about specific types of hardware, may be provided in the other areas of the section discussing hardware.

This activity may sometimes be called “system profiling” (and so the software that does this may be called a “system profiler” or a “system profiling tool”).


Note: The process of detecting hardware has, at least historically, been a fairly risky procedure. The risk could very often be that a computer could hang/lock up. There might even be the possibility of hardware damage. (Note the technology warnings. The risks could be similar to the risks of hardware damage that may be common when testing systems.)

For pre-PnP computers (which are now considered to be very old), there often was not really a safe way to reliably use software to communicate with hardware in order to perform a hardware detection procecure. This problem got better over time, especially after “PnP” technology started to become more commonplace.

Information from the drivers
Knowing what driver is loaded may help. This may or may not provide much useful information: generic drivers may be less likely to provide as many useful details. When the executable code of a driver is run, many drivers may report something when they are loaded. This text may or may not be visible on the screen. Text might be recorded in the boot logs, perhaps by the driver (writing to a file directly) or perhaps by the operating system (if the OS does something like logging the results of loading the driver, and/or standardized communications that the driver makes with the OS). For more details, see the section about boot logging of detected hardware.)
[#hwbtlogs]: Boot logging (logs that show detected hardware)
This may be moved to System Startup area and/or troubleshooting info, and one or more relevant hyperlinks put here.
Unix boot logs

Typically drivers that are loaded will show up during the system start messages. Many versions will show these messages when the system starts up. Also, these same messages can be viewed later by running dmesg. The system buffer shown by the dmesg command may be modified (by being appended to) over time. A copy of the file created when the system is started might (depending on the Unix variation) be stored in a /var/run/dmesg.boot file.

OpenBSD boot logs
Checking for unsupported hardware

See if there was any hardware that was detected but not supported. To do this, run:

dmesg | grep "not configured"

OpenBSD FAQ 12: section about unsupported hardware (FAQ 12.1.3) describes dealing with such hardware. In short:

  • one option is to use a different kernel. If this is encountered when the system was booted off of installation media, see if other (perhaps specialized) installation media is offered for the same OpenBSD platform.
  • Other options of handling the situation involve other methods of using a different kernel, or updating to a different (newer) driver. However, none of those options are particularly quick and easy.
Reporting success

OpenBSD FAQ 4: when an installation is finished requests some information. Such information may include notes about the hardware. OpenBSD FAQ 4: section on sending dmesg (FAQ section 4.10) quotes some of the E-Mail sent to root when the operating system is installed.

OpenBSD FAQ 4: section on sending dmesg (FAQ section 4.10) says, “Make sure you send email from an account that is able to also receive email so developers can contact you if they have something they want you to test or change in order to get your setup working. It's not important at all to send the email from the same machine that is running OpenBSD, so if that machine is unable to receive email, just” send the mail to an account that you will check. Then forwarding the E-Mail (with a nice subject) to the public E-Mail address. (Using another E-Mail address could be done if the mail command fails, and if such a failure is acceptable. For example, if the system cannot directly communicate to the Internet, then the mail command might not successfully send the E-Mail. Depending on what the computer is intended to be used for, that might, or might not, be a big deal. If the data can be transferred another way to another computer, and the information can be sent form another E-Mail address, that's fine. Just get the data transferred somehow.)

To do this, run the following commands (adjusting the E-Mail address as appropriate):

dmesg > ~/hwdet.txt
sysctl hw.sensors >> ~/hwdet.txt
cat ~/hwdet.txt | mail -s "Brief system description and already-tested/known results"

(Further details for the last command are available in the section about viewing files and the section about E-Mail, specifically the section about using the mail command.)

Microsoft Windows boot logs

The following details show how to generate and locate some inforamtion, but few if any details are provided about interpreting the information. Also, how useful the details are once interpreted is not provided a lot of detail.

The name of the log file may vary based on the operating system used.

Windows XP

Check %SystemRoot% for Ntbtlog.txt. If that doesn't exist, perhaps add /safeboot:network /sos /bootlog to boot.ini. MS KB Q315222: Safe Mode Boot options for XP has details.

SAFEBOOT_OPTION=Minimal(AlternateShell) may work more reliably? MS KB 833721 shows that using /safeboot:minimal(alternateshell) may start the operating system with a command prompt.


For Win9x(/ME), run win /b and then see C:\Bootlog.txt. For the text files by these operating systems, there is: MS KB Q127970: Common load failures listed in the Bootlog.txt file and MS KB 119066: BOOTLOG.TXT Failure Codes.

During installation, the Detlog files, which are Detcrash.log (a non-text file) and Detlog.txt, may have some information, as could Setuplog.txt.

Using tools from the operating system
Generalized tools

This software may work with a wide variety of hardware.


As a general rule, check out the sysctl values (as well as the boot logs).

As examples for OpenBSD:

Architecture (BSD detection)

Determine what native instruction command set is being used by the CPU. Available commands may include sysctl hw.machine and machine and arch and perhaps uname.

CPU info (BSD detection)
sysctl hw.model and “ sysctl | grep -i cpu ” and “ dmesg | grep -i cpu ” (which will probably be about identical to “ grep -i cpu /var/run/dmesg.boot ”).
Memory (BSD detection)
Physical RAM
dmesg | grep -i mem ” (will likely be the same as “ grep mem /var/run/dmesg.boot ” may show the total accessible memory, including some lines that start with spdmem and which have information about the individual memory sticks. “ sysctl hw | grep -i mem ” may show some of the information about what total memory is available.
Disks (BSD detection)
[#bsdetdrv]: Detecting disk devices (in BSD)
sysctl hw.diskcount
sysctl hw.disknames

will show what devices were detected.

Information from A post by Nick Holland, about drives suggests running a command like this:

dmesg | grep "^[swcf] d"

The names drives (like other devices in OpenBSD) will be based on the drive that is handling the device. As referred to by Nick Holland's post, drives that start with “cd” are optical drives, and drives starting with “fd” are floppy drives (or drives claiming compatability with floppy drives). Also also discussed a bit by OpenBSD installation: Boot detection: drives, drives with a drive name starting with “wd” are traditionally (E)IDE drives (a.k.a. ATA drives, or older drives). They may also be SATA drives if the BIOS is running in IDE-compatability mode. Drives that have a drive name starting with “sd” are drives running SCSI, or newer technologies including SATA in (the higher-performance) AHCI mode, and including USB drives. (This is, at least partially, discussed by OpenBSD FAQ 14: Intro (in the section called “Partitioning”; related/similar topics are discussed in the next sections called “Partition identification” and the “Disklabel Unique Identifiers” section of the OpenBSD FAQ on disks.)

Naturally, further information about the disks can be obtained with other tools such as dmesg (and the /var/run/dmesg.boot file), and potentially destructive commands (so be careful!) such as fdisk diskname and disklabel -pb diskname.

Disk/RAID layout


(Perhaps see: RAID)

Disk controller circuitry (e.g. RAID implementing cards)
(Does there need to be a separate section for this, different than detecting disks?
Network cards (BSD detection)
Since there's multiple tools that may help show the network cards, see a few ways to do this, see the section on detecting NICs.
Video (BSD detection)

Perhaps try “ dmesg | grep -i display ” and/or “ dmesg | grep -i video ”.

Check the X configuration file. If the location of the X configuration file is not known, try ~/xorg.conf or one of the locations mentioned on the “Description” section of the man page about the xorg.conf file (e.g. xorg.conf man page: heading 3 or OpenBSD manual page: Description section) or the “FILES” section of the man page for Xorg (e.g. Xorg man page: heading 10 or OpenBSD Xorg manual page: FILES section), or just try running “ Xorg -configure ” and then look for output specifying the configuration file's filename.

Audio (BSD detection)

Perhaps try “ dmesg | grep -i audio ”. With OpenBSD, that may show a line such as audio0 at followed by a device name, which may be separately viewed with another dmesg | grep -i command.

Another indication that the device was found may be if “ dmesg | grep -i ac97 ” shows some results.

Another option may be to try using the mixer software or other software that uses sound.

In the Unix realm, this has the potential of being fairly specific to the operating system. For instance, OpenBSD and FreeBSD may have some significant differences.

OpenBSD audio

This section may be OpenBSD-specific, and may be revised after more audio info is available for other operating systems.

OpenBSD FAQ 13: section on how to configure the audio device (OpenBSD FAQ 13.1), OpenBSD “manual page” about audio: section listing audio files, OpenBSD “manual page” for the mixerl command, OpenBSD “manual page” for the audioctl command, OpenBSD OSS audio emulation

FreeBSD audio
(Some old preliminary research has been done. Details are realistically expected to be added here at some point.)
(Misc) Expansion cards/Peripheral devices in BSD
PCI Cards in BSD

PCI cards may identify themselves.

Detecting PCI card info in OpenBSD

For PCI cards (which are represented by /dev/pci* files that are used to access PCI devices), a brief summary of what was detected may be available with pcidump. More details can be found with other commands such as pcidump -v and, naturally, dmesg (and the /var/run/dmesg.boot file).

(OpenBSD offers the above command as of OpenBSD 4.3.)

Another option in that operating system may be to interact with the kernel: See OpenBSD “manual page” for “boot_config” (and OpenBSD FAQ 5: section on “Boot-Time Configuration” (OpenBSD FAQ 5.8) as well as the following FAQ section (OpenBSD FAQ 5.9).


The lspci command may be part of a software package named “pciutils” info for pciutils states, “On OpenBSD you need to set sysctl machdep.allowaperture=2 in /etc/sysctl.conf, and run lspci and setpci as root.”

Some information about supported devices may be seen by OpenBSD manual page for PCI, and the numerous hyperlinked manual pages.

PCI devices in FreeBSD
pciconf -l ” is mentioend by Wikipedia page for lspci: “Other platforms”. TechRepublic article: Get Linux and FreeBSD hardware info with guide to commands suggests pciconf -lv
USB devices in BSD
USB devices in OpenBSD
Manual page for usbdevs
USB in FreeBSD
TechRepublic article: Get Linux and FreeBSD hardware info with guide to commands suggests usbconfig
Motherboard info
sysctl hw.vendor and sysctl hw.product
Hardware sensors (in BSD)

This may be pretty specific to OpenBSD.) sysctl hw.sensors provides information about temperatures and fan speeds.

Power management (in BSD)

Perhaps see also: power interfaces.

Check out:
maybe: usbhid-dump
DOS/Windows and similar

Use your preferred interface to check WMI. For example, Windows XP and newer comes with the command line program WMIC.

Seeing detected hardware that has/needs drivers

Query the Win32_PnPEntity object with WMI. Details about the object are documented at MSDN: Guide to the Win32_PnPEntity object.

An example of how to get this would be:

WMIC PATH Win32_PnPEntity Get

If the device is working, then the ConfigManageErrorCode column will be set to zero. (err... In Windows 7 this was ConfigManagerErrorCode, so maybe this was a typo, or maybe it changed?) If the device has an issue, such as not having the needed drivers, then that column may have a non-zero value. An example command line, to show less information, may be:

WMIC PATH Win32_PnPEntity Get Caption,ConfigManagerErrorCode
WMIC PATH Win32_PnPEntity Get Caption,ConfigManagerErrorCode,Description,Manufacturer,Name,PNPDeviceID,Status /FORMAT:LIST
WMIC PATH Win32_PnPEntity Get DeviceID,HardwareID,Name,PNPDeviceID /FORMAT:LIST

Note: IT may be fairly common for some (or even many) devices to show a blank Status value, or a value of “Degraded”. MSDN: Win32_PnPEntity notes, “Nonoperational statuses include: "Error", "Starting", "Stopping", and "Service".” Even some of those may be temporary situations that are rather acceptable.

Seeing some other types of hardware

There are various other WMI objects which may also be useful. MSDN: WMI Tasks: Computer Hardware provides some more examples. Here may be some more:

External device ports
[#winusbse]: USB
WMIC PATH Win32_USBHub Get Caption,Description,Name
WMIC PATH Win32_USBController Get Name
Old style Serial Port
WMIC PATH Win32_SerialPort Get Name
Parallel port
WMIC PATH Win32_ParallelPort Get Name

Here are some ways to detect this:


Craig's PCI Programs has PCI Visual Basic Script lists PCI buses, and lists devices within those PCI bsues. That is done with VBScript.


This has also been ported to JScript. Porting took a bit longer than anticipated (probably still under an hour), and the resulting JavaScript does look a bit more complex. (It uses an “Enumerator” object.) The filename for this is tentatively called pciwshjs.js and, although it functions, it has not been publicly posted yet.

And, here's how to not be successful at the task:

Trying WMIC

It does appear that much of the same sort of information can be retrieved using multiple steps with the WMIC command.

First, figure out what buses exist:

WMIC PATH Win32_Bus Get DeviceID

Example output:


List the devices:

WMIC PATH Win32_DeviceBus get Antecedent,Dependent /VALUE

That matches Device ID values to the individual bus. To get names related to the Device ID value, check out:

WMIC PATH Win32_PnPEntity get Caption,DeviceID,HardwareID,Name,PNPDeviceID /VALUE

The WMIC command can support a ASSOC parameter. Full details are not available here, at this time. Hopefully something like this can simplify that later:

Expansion Slots (e.g., PCI/AGP/(E)ISA)

(See also the section on buses, which lists devices per bus.)

WMIC SystemSlot Get SlotDesignation,tag

The SlotDesignation may be rather useless (e.g. a laptop has been known to show just J682 and J681 and J601), or may contain text like PCI or AGP.


MSDN: WMI Tasks involving Disks and File Systems provides some examples. For example, there is VBScript to “detect which drive letter is associated with a logical disk partition” (in Microsoft Windows).)

WMIC PATH Win32_DiskDrive Get
WMIC PATH Win32_DiskDrive Get /?
WMIC PATH Win32_DiskDrive Get Caption,DeviceID,PNPDeviceID,Partitions
WMIC PATH Win32_DiskDrive Get Caption,DeviceID,InterfaceType,Model,PNPDeviceID,SCSITargetID

(Some other commands...)

WMIC PATH Win32_DiskDriveToDiskPartition Get


WMIC BootConfig Get


Optical disc drives
WMIC CDROM Get Caption,CapabilityDescription,Description,DeviceId,Manufacturer,MediaLoaded,MediaType,Name /FORMAT:LIST

e.g., CapabilityDescriptions may say: “CapabilityDescriptions={"Random Access"," Supports writing"," Supports Removable Media"}

Another way to identify a writer may be to check the type. A type of “MediaType=DVD Writer” would probably indicate writability.

There are some other properties that may also be useful. They can be listed with:


and they can all be viewed with:


or, individual properties can be specified in a comma-separated list.

Tape drives

Interestingly, when viewing some of the info by CD-ROM drives, there was a property called “NeedsCleaning=”. This probably means that the CD-ROM code is sharing some object structure as tape drives, and that tape drives can report that property.

wmic cpu get CurrentClockSpeed,LoadPercentage,MaxClockSpeed,Name
wmic bios get name,serialnumber,version

(On a quick side note: for details about what the CPU is actually doing, one can check out CPU usage.)


See also the section on expansion slots. (For instance, specifically AGP probably only applies to video.)

The WMI object for video controllers can show some info. See the following command lines:

wmic Win32_VideoController get /FORMAT:LIST
wmic Win32_VideoController get AdapterRAM,AdapterCompatibility,Caption,Description,DeviceID,InfFilename,InfSection,Name,PNPDeviceID,VideoProcessor /FORMAT:LIST

For instance, on an ATI device, the InfSection was ati2mtag_Wrestler, which could have helped to identify that this was an ATI device.

The description may be another way to check for custom drivers. If the standard VGA driver is used, that may be reflected by the description.

There are lots of available properties. Here is a command that helps to show about the current state of the video devices:

wmic Win32_VideoController get Caption,CurrentBitsPerPixel,CurrentHorizontalResolution,CurrentNumberOfColors,CurrentRefreshRate,CurrentVerticalResolution,DriverDate,DriverVersion,Status,VideoModeDescription /FORMAT:LIST

Users of TightVNC's Mirage driver may find that a physical card has no current resolution, but that the Mirage device does. (This driver may be recommended for people who use VNC. See: remote access.)

Perhaps also useful: MSDN: WMI Monitor Listed Supported Source Modes class


Richard T. Gregory's Windows Gems: wmic - windows management interface provides these short examples:

wmic csproduct get name,vendor,identifyingNumber
wmic bios get name,serialnumber,version
wmic baseboard get Manufacturer,Model,Name,Product,SerialNumber,Version
wmic baseboard get /?
wmic MemoryChip get /?

FiveO's answer to “baalji av”'s question about detecting RAM nicely points out that this WMI object is related to the object described by MSDN: Win32_PhysicalMemory class which can point out details like FormFactor=12 meaning SODIMM and MemoryType=21 meaning DDR2. (DDR3 isn't listed on this page, and reportedly will show up like DDR2. Well, one shouldn't be too surprised: over the many years, certain details of hardware detection have often been very vague.)

With that resource in mind, here is an example command:

wmic MemoryChip get BankLabel,Capacity,DataWidth,DeviceLocator,FormFactor,HotSwappable,Manufacturer,MemoryType,Model,PoweredOn,Removable,Replaceable,TotalWidth

The MSDN article notes that a DataWidth value of zero and a TotalWidth value of 8 “indicates that the memory is used solely to provide error correction bits.”

Values that are blank seem to indicate “false” (e.g.: HotSwappable and Removable and Replaceable).

There are certainly more properties. Some of them might give some additional properties which may be interesting for hardware enthusiasts who know about the details that can affect RAM speed.

Here is another example command line which provides some other details that might be useful for people who try to track inventory:

wmic MemoryChip get Caption,Description,Model,Name,SerialNumber,OtherIdentifyingInfo,PartNumber,Tag

wmic SystemEnclosure get ChassisType,Manufacturer,SerialNumber,Tag

Perhaps the most useful of those items is ChassisType which provides a numeric value. To see what that numeric value means, check out one of the following resources: TechNet: Identifying the Chassis Type of a Computer, MSDN Win32_SystemEnclosure class (which also describes the other values), Hardware detection script (by Rob Van der woude), who has no known relation to the founder of this site.

Perhaps see also: WMIC CSProduct (info from SMBIOS)

wmic CSProduct get /ALL /VALUE
wmic UPS get

The section on expansion card slots has some details, like IRQs, which may apply to other types of devices as well.

[#devicmgr]: Device Manager

Modern versions of Microsoft Windows have a graphical interface called “Device Manager”.

Viewing Device Manager

There are multiple ways to go into Device Manager. The most traditional, well-known method may be from within the System Properties control panel applet. The fastest way to get to this may be to hold down the “Start Menu key” on the keyboard, a.k.a. the “Windows logo key” on the keyboard, and then press the Pause/Break key. Another method is to go through Control Panel and choosing the “System” icon. In Windows Server 2003 and older operating systems (including Windows XP), that would run %windir%\Control.exe Sysdm.cpl, or do some similar/equivilent thing that opens up the “System Properties” dialog box. In Windows Vista, that opens a “System” control panel applet which is different. From that applet, the left frame may just have a hyperlink called “Device Manager” that may be used. (That applet would also have an “Advanced system settings” hyperlink which would open the “System Properties” dialog box.)

Windows 95, 98, and ME would then have a tab called “Device Manager” (or some similarly-named tab?), while other versions of Microsoft Windows may have a “Hardware” tab which may have a “Device Manager” button. In Win9x/ME, one may run “ %windir%\Control.exe Sysdm.cpl, System,1 ” In modern versions of Microsoft Windows, “ start Control Sysdm.cpl,System,1 ” may go straight to the “Hardware” tab.

Windows 2000, XP, and newer may be able to run start devmgmt.msc which uses an MMC console that may also be available using other means (such as from start compmgmt.msc or as a Snap-In in MMC). On at least Windows XP and newer, users of the graphical interface may right-click on the “My Computer” icon (which might commonly be called either “My Computer” or just “Computer”, and which may often be on the desktop and/or on the Start Menu), and choosing “Manage”, which will either run the Computer Management (similar to start compmgmt.msc) or, on Windows Server 2008, will instead run the similar yet different Server Management/Manager(sp?) (which may not have all of the interfaces of Computer Management, such as those related to file sharing, but does also have Device Manager).

Once in Device Manager, the default view is to list “Devices by type”. So, types/categories of devices will show up. Devices that have been detected but which don't work may have a warning (yellow triangle with black exclamation point) icon, an error (red circle with white X) icon, or a disabled (black down arrow) icon.

Microsoft Diagnostics (“MSD” and similar)
MSD came with some Microsoft software, at least including some versions of MS-DOS and some versions of Microsoft Windows.
  • WinNT: WinMSD. WinMSDp.exe (Err... is that a misspelling? The lowercase p might not belong there) came with Resource Kits. MS KB 827218 refers to having people run WinMSD (if using Windows Server 2003 or Windows XP).
  • Win2K: WinMSD just runs msinfo32.exe (which is called the “System Information” tool.)
System Information

This is a separate program which is a different interface than Device Manager. It may be easier (or even more possible?) to find some informatin using this program, compared to using Device Manager. %SystemRoot%\system32\msinfo32.exe may be a program that gets run by a hyperlink that shows up on the Start Menu, in the Program or “All Programs” area, and more specifically in the folder called Accessories. (That may be a “shortcut file” located at "%USERPROFILE%\..\All Users\Microsoft\Windows\Start Menu\Programs\Accessories\System Tools\System Information.lnk".)

DirectX Diagnostic Tool

When running dxdiag /64bit, there are various tabs. (Note that the /64bit is optional on 64-bit versions of Microsoft Windows, and presumably should not be used for 32-bit versions of Microsoft Windows. If in doubt, simply leave that part off of the command. In a 64-bit version of Microsoft Windows, the 32-bit version of dxdiag will have a “Run 64-bit DxDiag” button that can be pressed.)

The default “System” tab may show information about the CPU model (including the processor speed), RAM amount, motherboard model, and so forth. There may also be a tab that says “Display”, and a tab that says “Sound”. Or there may be multiple such tabs, like “Diaplay 1”, “Display 2” “Sound 1”, etc. There is also an “Input” tab that shows devices that work with DirectInput, like a keyboard and a mouse. (As an example, consider a system that had a USB-based adapter that wirelessly communicated with both a keyboard and a mouse. It had a line for “Keyboard”, and a line for “Mouse”, as well as “2.4G Keyboard Mouse”). There's a “Save All Information” button which makes a text file (defaulting to DxDiag.txt on the user's desktop, but the program does ask what location is desired).

In old version(s) (perhaps just Windows 95 OSR1), DirectX needed to be installed. Newer versions of Microsoft Windows come with DirectX. (There may be a newer version of DirectX that can be added to the version of Microsoft Windows. Still, at least some version may be installed, which means the dxdiag command is likely to be available.)

Add/Remove Hardware Wizard

This software is meant to add support for hardware which isn't yet supported by an installed driver, and it has code for trying to automatically detect devices. If a device isn't automatically detected (including if the user chooses to skip automatic detection), the user may select from a list of available drivers which will hopefully then lead to the correct device becoming detected.

Safely Remove Media

This may show some detected hardware. It will, however, probably not show most hardware.) If supported hardware is detected, an icon that is partially green may be visible. In Windows Vista, it may look like a USB plug with a green circle and a white checkbox. If that icon isn't visible, the program may be run with “ RUNDLL32.EXE SHELL32.DLL,Control_RunDLL HotPlug.dll ”.

If the main “Safely Remove Hardware” interface is showing, be sure to choose the “Display device components” checkbox. Selecting an item and choosing Properties may show more information which is similar to the properties shown from within Device Manager. Selecting an item and choosing Stop typically doesn't stop a device, but will show a “Stop a Hardware device” dialog box. That dialog box may show more sub-devices, which in some cases (at least on older operating systems) may be more prone to identify which drive letter is associated with mounted removable data storage media.

Note: If trying to safely remove media, and if the operating system does not seem to want to allow the device to cleanly stop being used, check for open file handles. (See the section about files that are in use for further details.)

Nirsoft has some software that can accomplish similar tasks. The USBDeview (USB Devices View) has not only a graphical interface, but also a command line interface. It has been known to work well to eject a USB device that may be specified in one of multiple ways, such as using the product's name or the drive letter that is used as a mount point. The program supports a command line parameter syntax of using “ /remote \\ComputerName ” for remote systems.

[#usbwndrv]: Auto-installation (of drivers in Microsoft Windows) Vista web page about installing a USB device states, “The first time you connect a device that plugs into a universal serial bus (USB) port, Windows automatically installs a driver for that device.” (There is a section about USB ports that may cover information relevant to using this technology. This section is more about Microsoft Windows's implementation.)

The best standard is that the device should be turned on, and then plugged into a USB port, and then this will cause Windows to automatically install any needed driver. However, this is not a universally implemented Universal Serial Bus standard. The referenced web page notes, “some devices require you to install the driver before plugging the device in.” “Also, while most devices that have power switches should be turned on before you connect them, others require that you turn them on during the installation process. Because of issues like this, it's a good idea to read the instructions included with a new device before you connect it.” “If the instructions that came with your device contradict the information in this topic, follow the instructions that came with the device.”

In practice, using USB devices is generally fairly easy, even though the precise installation procedure may vary a bit. Once a USB device does work, it is often best to not try to update or otherwise tinker with the drivers, and then usually the device will continue to work on that computer in the future.

Side note: USB information does tend to get stored in the Registry. This may effectively be used to help log what USB devices have been connected to a system. A couple of programs by NirSoft that might help show some of this information rather easily may be NirSoft's USBLogView and NirSoft DriveLetterView.

(PC-DOS 6: See qconfig.exe as mentioned by Wikipedia's page about Microsoft Diagnostics )
Dr. Watson

The DOS DEBUG command can allow some interaction with hardware, which may be able to generate some useful information. Know that thi sis generally not the easiest way for novices. So this is being mentioned as an existing option that will probably usually only be viewed as an alternative, but not a recommendation.

Although the command seems to be lacking from newer versions of Microsoft Windows that are 64-bit releases, the 32-bit releases may still have the command (apparently still true as of at least Windows 8).

The detecting communications ports has a section about debug. : How to identify video card says that using the “d c000:0000” command will show some data. Then, the “d” command wills how the next block of data. An example screenshot shows how a video card was identified with two blocks of data, and a version number was revealed by showing a third block of data (which was made visible by running “d” again). Then, to quit the debugger, use “q”.

More specifically targeted methods of detecting hardware
[#detctnic]: Detecting network hardware
Information is available at available NICs. If that doesn't work, see information about detecting expansion cards (which might not be fully supported).
[#detctcom]: Detecting communications ports
Detecting communications ports with DOS DEBUG

Apparently, by using the Debug command in MS-DOS, typing “D 40: B” (without quotation marks, and then pressing enter) will show information about COM1 through COM4 and LPT1 through LPT2. This is slight speculation, on information shown at information about COM ports. The output shows a memory address (which is unnecessary), and then two bytes per port. Output is shown in a different Endian format than common, so output of “F8 03” refers to the hardware I/O address of 0x03F8 (more commonly written as 0x3F8, or sometimes as 3F8H or 3F8). Output of zeros indicates that the port was not detected.

After the output, enter Q to quit.


If memory serves correctly, there was a DOS program named WhatPort which worked well for detecting COM port information. Results could be more detailed/clear than MSD. However, a Word document file, CHECKIRQ (Word document file) indicated there may be some better software (presumably the *.EXE file) and that WhatPort could be buggier. CDTextFiles : PCMedic : I/O programs had a copy, and CDTextFiles : PC Medit : I/O programs : file listing provided descriptions of some other programs that appear to be similar.

Video cards : video card detection shows results of sending “D C000:01 (followed by the Enter key) into DOS's Debug command.

It seems probable that similar techniques may be easily generated for some other hardware, to see if it is at a known address. This is some slight speculation, but futher technical details may be available from resources such as RBIL (see: Wikipedia's article for “Ralf Brown's Interrupt List”).

Additional software from the operating system vendor

Software mentioned in this section may need to be downloaded/obtained.

Note: Some of the software, in the section about software bundled with operationg systems, might be bundled in with only some versions of the operating systems. In some cases, such software may be available as a seperate download. If the software doesn't seem to exist, check out the vendor's website to see if there is a downloadable version.

Microsoft software
[#devcon]: DevCon

For Windows 2000 and XP and newer: Microsoft KB Q 311272: The DevCon command-line utility functions as an alternative to Device Manager notes that “The source code for DevCon is also available in the Windows DDK (which is available from under DDK root\Src\Setup\Devcon, along with documentation.” The KB article also has a hyperlink to DevCon installer package.

To be very clear about compatibility, the just-referenced MS KB Q311272 notes, “You cannot use DevCon with Windows 95, Windows 98, or Windows Millennium Edition.”

More details may be at: TechNet: Devcon Overview, Rob Van der woude's web page about DEVCON (Note: Despite the similarity in names, Rob Van der woude is of no clearly known relation to Scott Conrad VanderWoude, the creator of ][Cyber Pillar][.)

Using third party software

Consider booting from removable media and accomplishing this task by using software which will report the information as detected by a different operating system. This is the sort of task that another operating system may be particularly good at if a system's usual primary operating system doesn't provide all the details, because the other operating system may use different detection routines and have drivers for some different hardware. By booting off of removable media, an existing configuration shouldn't need to be having substantial changes, such as changing partition sizes.

A system profiler may be able to provide some additional details, including what expansion card slots are used and available, and perhaps what memory slots are available. Additional details, such as the speed of memory used in each slot, may help one who wants to obtain additional memory which is similar to existing memory. Keep in mind that such information has historically been unreliable, so it may be worthwhile to physically look inside the case to double-check the information before making a purchase based on such information. (Additional steps, such as removing the RAM and reading stickers on a RAM chip, definitely may involve powering off the system and removing any power plugs or other power sources, mainly laptop batteries, that may exist.) However, hopefully such reporting mechanisms have, or will, improve in reliability, and some information may be helpful to determine what sort of parts to bring to a remote site. However, if traveling to the remote site is generally infrequent and expensive, it may be worthwhile to bring some different types of parts in case the reporting tool ends up being a bit... wrong.

The following may be helpful.

Detecting hardware in Unix (with third party software)

The following software may be helpful in trying to achieve success with this task. Note that these are not, at the time of this writing, recommended by the author of this text. So, some testing/experimentation may be needed to determine which ones are actually useful. (Of course, be aware of the standard considerations, such as that hardware probing can be “dangerous” leading to system lockups or, though rare, maybe even hardware damage. This is more true with older equipment.)

None of these show up in OpenBSD/i386 4.6's package list.

hardinfo, HardwareLiSter: lshw, SysInfo (perhaps at, this was previously at previously at but perhaps neither address works right now)

Some profiling options for DOS/Microsoft Windows

The following software may be helpful in trying to achieve success with this task. Note that these are not, at the time of this writing, recommended by the author of this text. So, some testing/experimentation may be needed to determine which ones are actually useful. (Of course, be aware of the standard considerations, such as that hardware probing can be “dangerous” leading to system lockups or, though rare, maybe even hardware damage. This is more true with older equipment.)

Further testing needed: The following aren't necessarily recommended (perhaps because they haven't been heavily tested), but some of these are well known.

  • PC Wizard (by the makers of CPU-ID) “100% free” according to its web page.
  • CPU-Z
    • CPU-Z (although it has a GUI, CPU-Z info mentions command line parameters, including -txt=filename.txt or -html=filename.htm or -console. The -console is documented as “(Windows XP Only)”.).
  • PCI
    • Includes PCI32 (for Win32), PCI64 (for Win64), PCI for DOS, and ports for OS/2 and BartPE.
  • FinalWare's AIDA64 (previously known as Everest)
  • System Information for Windows (SIW) (might be free for personal use)
  • HWINFO32
  • BelArc Advisor
  • System Information Viewer (SIV)
  • For DOS: Quarterdeck's QEMM may have Manifest (mft.exe).

The section about detecting a CPU may have some more details.

Here is some other information (possibly redundant with the text just previous to right here).

Detecting PCI info in DOS/Windows

(Note: The following software has not been tested by the creator of this text. Use at your own risk. See Mirror of Craig Hart's PCI software (downloads page). Grab the database. For DOS, also grab the software called PCI. For Windows, also grab PCIVBS.VBS or, another option for 32-bit Windows (but not 64-bit Windows nor 16-bit Windows), PCI32.

Although the earlier software may work in OS/2 (and eComStation), the author of this software refers to Veit Kannegieser's port to OS/2, stating, “Veit has spent a lot of time making his port focus on the specific quirks of OS/2 e.g. IRQ sharing issues, so I highly recommend his version to all OS/2 and eComStation users.”

A web page for a GUI under BartPE refers to “Craig Hart's PCI+AGP Bus Sniffer”.

On a side note, a Mirror of Craig Hart's website shows the website had a footnate saying “Best viewed with eyeballs and brains.” (This comment may make sense for old-timers who recognize that many early web pages would say what web browsers the web pages were designed for.)


System profiling on a Mac
System startup process

The system's setup program, e.g. BIOS setup, might be able to provide some information about the hardware. At least on x86 systems, this typically doesn't tend to provide a lot of useful information, unless there is an option to enable a device that was disabled by the BIOS. However, sometimes the BIOS setup does show some information.

Many BIOS systems will show a screen with some details about detected hardware, and will do this after the memory test, just before executing boot code. Unfortunately, many systems will have so much information that it scrolls right off the screen, which may be an 80 column by 25 row text mode (which isn't really configurable). There might be a way to pause the screen, perhaps by pressing Ctrl-S or using Scroll Lock, but some information might scroll by so quickly that attempting to pause at just the right time may not be a task that is reasonably easy to perform.

Misc notes: Dealing with Unknown Devices MS KB 314464

Plug 'n Play info

Sometimes, a “Device ID” string (or, sometimes called by the more specific term, “PnP Device ID”) may be visible. (Actually, a “Device ID” may also just refer to part of tha string. These terms might not be getting used quite perfectly here, yet...) MSDN: Device Identification Strings.

WMI may show these with a PNPDeviceID or a DeviceID or a HardwareID property. (They might not be the exact same thing, but overlap may be common?)

It may look something like this:



ConnType, id, number, val, and numeral

are customized. The parts before the underscores are called prefixes. So, the prefixes in this example are VEN, DEV, SUBSYS, and REV.


The part before the backslash specifies what protocol is used to communicate with the device. Values could include an expansion slot protocol (PCI) or a disk interface protocol (SCSI or IDE).

VEN: Vendor ID

The “id” in the sample refers to a numeric “Vendor ID”. This can be looked up in a database to determine who made a device. That requires that the device is new enough to support a standard like “Plug 'n' Play” where such a number is provided by the device.

DEV: Device ID

Vendors can give a different “Device ID” number for every different model of each device they make. This way, when there is an inquiry about a device (such as if Microsoft Windows is checking a database for a driver that claims to be compatible with a device that uses this “Device ID”), then this device can be suitably identified.

Man page for dmidecode: “Bugs” section states, “More often than not, information contained in the DMI tables is inaccurate, incomplete or simply wrong.”

There is also: Man page for Security Enhanced Linux Policy for the dmidecode processes,
Wikipedia: System Management BIOS