Windows Devices: Hard drives and partitions

This page contains some information about names that Windows may provide for “long term storage” devices (like “hard drives” or SSDs (“solid state disks”) which are intended to store data for longer periods of time than, for example, RAM (which retains contents only as long as electricity is provided).

Quick hyperlink: If you're looking to identify a drive, check outthe sub-section on Identifying a (named, data storage) “\Device\. Otherwise, that section does come later, and this page provides some more overview/background information.

A reference to a partition may be more difficult than a hard drive. Let's first look at matching a hard drive's name.

[#wndvnamd]: Identifying a physical disk (in Microsoft Windows)

Note: if viewing logs, understand that the device that was mentioned might not currently be an active device. (For instance, if a removable USB device is removed improperly, there may be logs that show a reference to a Device that, especially when viewed later, may not appear to exist anymore.)

Ideally, what is nice to have is the ability to match up the following things: the disk's mount point and volume name, the make and model of the disk, the disk's serial number, and what connector/port (on the hard drive controller) the disk is plugged into. Knowing the serial number may help with looking up warranty information; knowing the serial number and the connectors may help when there are multiple disks of the same type/model in a single computer. This section is meant to provide this sort of info as much as possible.

Matching a hard drive's name to a physical hard drive may be doable with the following methods:

Software for RAID

If a hardware RAID controller is being used, use the software designed to work with a hardware RAID controller. This software may be the best/only good method to determine information about the actual physical hard drives. (There probably isn't any harm in trying to use other techniques, but anticipate that they may refer to one of the RAID volumes provided by the hard drive controller, instead of providing information about one of the storage devices that the controller interfaces with.)

Using WMI


wmic DISKDRIVE get DeviceID,InterfaceType,Manufacturer,MediaType,Model,Name,Size


wmic PATH Win32_DiskPartition Assoc

(the latter of which was recommended by: EXETOOLS Forum: matching drive letters to physical disks).

JScript and VBScript
Correlate Disk

Current, VBScript has been made available. See: Correlate Disk VBScript.

Matching drive letter to physical drive

The VBScript from EXETOOLS Forum: matching drive letters to physical disks: JuneMouse's posting is confirmed to match what was found at WMI Tasks: Disks and File Systems (code snippet 11) : “How do I...” “...detect which drive letter is associated with a logical disk partition?”

Output looks something like:

C:\>CScript //NoLogo ShHDNams.VBS
Disk drive Caption: CaptionText
DeviceID:  (deviceIDText)
Drive letter associated with disk drive = CaptionTextdeviceIDText
  Partition = Disk #diskNum, Parititon #partNum
  is driveLetter:

The “deviceIDText” starts with “\\”. Here is an actual example:

C:\>CScript //NoLogo ShHDNams.VBS
Disk drive Caption: Hitachi HTS543232A7A384 ATA Device
Drive letter associated with disk drive = Hitachi HTS543232A7A384 ATA Device\\.\PHYSICALDRIVE0
  Partition = Disk #0, Parititon #1
  is driveLetter:

EXETOOLS Forum: matching drive letters to physical disks: JuneMouse's posting shows an example from a system that has multiple drives.

Multiple implementations are available: Showing hard drive names (JScript code) and Showing hard drive names (VBScript code) are available; both together are available in Showing hard drive names (multiple-implementation zip file). The VBScript code is heavily based on Microsoft's example (only adding some comments, and possibly adjusting white space from a copy-and-paste process), while the JScript version is meant to take the same approach and it produces identical output.

Monitoring the disk

(Untested solution): Perhaps a solution can be derived by using DiskMon. (This might also work for identifying partitions?)

Following are some scratch notes, in case they are of any further use:

see dosdev subdir, LTRDATA Tools and utilities for Windows has a for which there is available source.

Richard T. Gregory's Windows Gems: wmic - windows management interface mentions some/all of:

wmic partition get name,bootable,size,type
wmic diskdrive get name,size,model
wmic LOGICALDISK get /all

Perhaps DeviceID can match drive letter using:

wmic volume get BootVolume,Caption,Description,DeviceID,DirtyBitSet,DriveLetter,DriveType,FileSystem,FreeSpace,Label,MaximumFileNameLength,Name,PageFilePresent,SerialNumber,SystemVolume
[#wndvhdnm]: Identifying a (named, data storage) “\Device\
Overview of problem/goal

Often, a device name may show up in the logs, but that device name may not seem to directly correspond to one of the physical drives. It may be well worthwhile to determine whether this is:

  • the operating system's boot drive,
  • or another hard drive storing lots of data,
  • or an optical drive that may be using a scratched disk,
  • or some removable drive that may have been removed (properly or improperly),
  • or some sort of virtual disk which may even have been intended to be temporary (possibly as a part of some sort of technology like Volume Shadow Copy Services (“VSC” or “VSS”), as part of a process intended to help back up data).
    • In that last case, there may be no need to stress out over trying to fix a disk that doesn't even exist anymore.

The device name that is reported might refer to a partition.

The types of log messages that typically use such “\Device\Harddisk#\DR#” references tend to sound quite potentially dangerous. The author of this text has seen such messages show up on multiple machines. Despite the apparent importance, solving this conundrum has been extremely perplexing, especially considering what seems to be at stake.

Some of the information presented here has been documented during attempts to figure out what to make of this. At least one of the processes described has not been a very quick process, nor a definite one. (It could take 10-15 minutes only to end up having no positive results.) However, the author of this text suspects that, at the time this guide was written, there might not be another guide to recommend using instead. So, just plan to need to spend (at least) that length of time if necessary.

[#dvnamisl]: Beware: Close enough may need to be good enough, but isn't always

Beware: If some names seem “close enough” to each other, sometimes that is a good indication that the log message matches a device with the similar-ish name. Sometimes, that has been the most telltale detail that seemed available, and needed to be “good enough”. However, despite the apparent need, sometimes that similarly has not been “good enough” of a clue to provide a correct conclusion.

To avoid such incorrect conclusions, realize that \Device\Harddisk1\ may not have anything to do with \Device\HardDiskVolume1. (Sometimes similarities in the Device Names may be useful, but the similarity shown in the above example is not useful. It is only misleading.)

A process

As of late 2016 (published in early November), this currently seems to be the best process I've been able to find.

A potential roadmap

Here's a quick rundown of what you may be reasonably able to anticipate being recommended:

  • Read about the process.
    • Understand this may take some time
    • (e.g., also read enough to learn about how the “DR” number may increase, proving that trying to match that number to hardware may be daunting or impossible in some cases). Especially know that such messages can come from temporary/software virtual “devices”, and might not actually be related to hardware failing.
  • Try using PowerShell's Get-PhysicalDisk (using the longer command line documented below).
  • See what you can find out from WinObj
  • See what can match up using dd --list
  • Check logs from around the time of the event that contains this reference. Did an enumerator service just start? Did a backup job just start?
    • The “Quick tips: some findings” and “More findings” section may be useful.

First of all, prepare yourself for the possibility that this seemingly simple problem may not be easy. The creator of this website has looked at various different pieces of software and read different guides and approaches. Sometimes the solutions have become rather clearly available, and sometimes they have not.

When a warning or error message is shown in the logs, this might not refer to a real physical drive. The message may relate to something like a virtual disk, possibly related to some sort of technology such as Volume Shadow Copy Services (“VSS” / “VSC”).

Understanding the “DR” number
Increasing DR number

Frederik Long's first answer to “M.a.r.k.T. _”'s question about “Which disk does \Device\Harddisk<X>\DR<Y> relate to?” had this to say:

“You will find that Y is a number that gets dynamically assigned to each drive.”

The forum posting goes on to show an example that indicates the DR number changes whenever Windows recognizes a drive other than the one that was previously used. By flip-flopping back and forth between multiple drives, the results end up increasing the number after “DR”.

Yirkha's answer to K834T953's question: “How to find out which hdd is \Device\Harddisk#\DR# ?” says:, “The number in the DRx part at the end really does not have any special meaning.” ... With some types of activity, “the number keeps increasing”. So, don't worry a whole lot about paying too much attention to that portion of the number.

What “DR” refers to

At least some of the following quoted information did not seem to come from an extremely authoritive documentation source. There is a bit that appears to come from a Microsoft employee. However, sometimes support representatives may say incorrect things. (Well, for that matter, sometimes documentation can also be incorrect.) In the end, this text does not make definitive claims about what is the actually accurate definition of “DR”. Still, since some information has been found, it is being presented here.

GetLag's answer to K834T953's question: “How to find out which hdd is \Device\Harddisk#\DR# ?” says, “DR is simply an abbreviation for Drive and should match the Harddisk# entry in the path before it...” Actually, GetLag indicates this statement was quoted from “Microsoft Enterprise support, from another thread”. (The actual thread wasn't identified.) The second part of the statement seems rather questionable, since the DR number is known to be increasable through user action (and, therefore, may not be a number that matches the Hard Disk number).

Leo Huang's comment states, “DR# means drive, removable”. (This was found thanks to moab's comment to user9999999's question, which states more clearly, “Identifying Windows 10 \Device\Harddisk1\DR2” says, “DR stands for Drive Removable, so it is a removable drive , not a fixed drive.” Moab's comment to Rod's question, “How do I determine which HD is involved in the Event Viewer?”

Mehrdad's answer to bwDraco's question about device names indicates that the DR refers to a disk (as opposed to a partition). (Currently, that seems rather unlikely. It seems more likely that the “Harddisk” section idntnifies the disk.)

One goal, which sounds ideal, is to fully understand everything that his happening. Another approach, which might need to be settled for, is simply to figure out whether the report represents a serious problem. For instance, many IT people will want to figure out just which drive the message refers to. However, if the message is related to some sort of identifier related to a temporary virtual disk created during an automated process, then figuring out the drive causing the error might actually be less important than just verifying that no serious threat is actually occurring with any of the physical drives which are actually critical.

Quick tips: some findings

Some technicians have reported that some error messages may occur whenever a specific service is started. The service mentions “Enumerator” and might have a name like “PnP-X IP Bus Enumerator”. (The precise service name seems to vary on different computers. It does contain the word “Enumerator”, and may contain “PnP”, and might even be the exact text shown in the example, “PnP-X IP Bus Enumerator”. In all likelihood, the exact name probably varies on different machines due to some actual software differences, possibly due to different hardware/drivers. However, the effect here seems to have been the same.)

The author of this text is not necessarily recommending restarting that service (as such actions should not be taken without a full understanding of just what consequences are likely). However, some technicians have done so, without seeing any consequences except for generating another copy of the error message. This has been considered evidence that strongly suggested that starting that service is what caused the error message the prior time.

Logs may be prone to show some sort of “backup” related activity, and/or activity related to Volume Shadow Copy Services (“VSS” / “VSC”).

Routinely reported backups may be reporting as successful.

It might be true that some of these error messages are more prone to occur when USB drives are being used.

More findings

A claim has been made that such errors can occur due to a “timeout” event being experienced. (Unfortunately, the source of this claim was not any official Microsoft documentation.) The recommended course of action was to check hardware. (This seemed like an easy recommendation to make, as the recommenders were not responsible for checking hardware. So, that recommendation would move issues out of their responsibility. The people who made this recommendation weren't necessarily quite so concerned about the impact of such downtime.)

It seems like such issues have often occurred right when a lot of activity is taking place, such as when backups (or the creation of “Volume Shadow Copies”) get started.

If that is true, then this “error” may be rather non-critical. It may simply refer to something being slow to respond, rather than being an error with being able to reliably read data. (That would make the whole situation far less critical.) This may be more prone to happen on older machines (which may have received enough security updates that they are running some software that may have been optimized for newer machines, which might actually cause some genuine slowdown). If that is the case, the proper course of action for an IT department may be to supply this as a demonstration that the hardware is getting to be rather old (and may be worthy of getting replaced).

As I recall, one of my favorite tools to use was “DMDiag -v”, which was built into Windows Server 2003 but could be run on Windows XP. Unfortunately, it didn't work so well in Windows Server 2008. So, this process skips trying to use that tool on newer operating systems.

Seeing details

This step will absolutely not resolve things in every case. However, in the cases where this step will help, this may be the fastest and most conclusive method.

If the reason to identify a device is related to a recorded event that showed up in a log, then check that log thoroughly. For example, One of Frederik Long's answers to “M.a.r.k.T. _”'s question about “Which disk does \Device\Harddisk<X>\DR<Y> relate to?” shows an example where the “Details” tab of the Event Viewer ends up showing helpful information about a logged event.

So, in the case of that Event ID 33 shown by Frederik Long's answer (which was just referenced), this process may be the best approach. In other cases, such as some experiences with Windows Event Logs, showing disk events, Event ID #51, this might not be helpful (because the type of information, which would be very helpful, simply isn't there). In that case, further steps are needed.

Using PowerShell

The following was recommended by Bill Fraser's answer to a question by “j riv”, titled “Which drive is \Device\Harddisk1\DR1?”.

From a PowerShell prompt:

Get-PhysicalDisk | Select -Prop DeviceId,FriendlyName,SerialNumber

Or, the following may work from a traditional command prompt:

PowerShell -Command " Get-PhysicalDisk | Select -Prop DeviceId,FriendlyName,SerialNumber "

The value in the DeviceID column is said to match match the number in a \Device\Harddisk# reference.

Using WinObj (by Sysinternals)

Then try using WinObj.

Getting the software
Get the program from obtained from, Sysinternals: WinObj / WinObj page, or get the program from Winobj.exe (from

The home page for WinObj by Sysinternals does refer to “Microsoft SDK's program” that has “the same name”. So there are multiple programs named WinObj. The home page for the Sysinternals version says that “the SDK version suffers from numerous significant bugs that prevent it from displaying accurate information (e.g. its handle and reference counting information are totally broken).” So, make sure to use the Sysinternals version.

If the system uses Microsoft Windows User Account Control (“UAC”), run the program elevated.

Recommended steps

Here are some steps:

  1. Figure out the “Harddisk#” portion of the name. e.g., \Device\Harddisk0\DR0
  2. In the left frame, of WinObj, the \ folder will likely be pre-expanded. Click on the Device sub-folder.
  3. Under \ and then Device, find a folder that corresponds to the drive name. (e.g., “Harddisk0). Click on that folder name.
  4. The third column will show SymLinks. Remember all of the SymLinks. (If needed, create a screenshot, or write them down.) Here is the information taken from an actual example:
  5. In the left frame of WinObj, under \ (but not nested any more deeply than what the Device folder is), click on the folder that is named “GLOBAL??”. (Yes, that folder name actually has two question marks in it.)
  6. Make sure the arrow (which designates the column that is sorted, and the direction) is in the SymLink column. Otherwise, click on that column.
  7. Choose one of the SymLinks from the remembered list. e.g., \Device\HarddiskVolume1 or \Device\Harddisk0\DR
  8. Scroll down to find the SymLink.
  9. Look in the first column, which is the column called “Names”. Look at each name that is related to the SymLink. For instance, if \Device\Harddisk0\DR0 was used, it may have a name like “PhysicalDrive0”. Another name may be “Disk{”, followed by a GUID, and then a corresponding right curly brace (”}”). See if this SymLink has a name which looks like a drive letter (meaning that the name consists of a single letter followed by a colon)
  10. If you're looking for something, such as a specific drive letter or GUID, and this SymLink does not have a name that matches what you're looking for, then repeat the process for anotehr SymLink that is related to this drive. As needed, repeat that process for every other SymLink that is related to this drive. (The SymLinks for the drive should have been remembered from the prior step, which showed an example chart.) For example, see which other SymLinks, for the same drive, has a name which looks like a drive letter.

(Credit where due: These diections were largely an adaptation of what was provided by Yirkha's answer to K834T953's question: “How to find out which hdd is \Device\Harddisk#\DR# ?”.)

What happens if the desired device doesn't show up in the Device folder? Well, that indicates that the system isn't currently aware of the device. That could mean that the device was a temporary device, such as a device related to Volume Shadow Copy Services (“VSS” / “VSC”) and/or created when a service like “PnP-X IP Bus Enumerator” started. Or, this situation could occur if a removable drive, such as a USB memory stick, has been removed. In such cases, poking around the system to try to find the drive might not be an approach that can work, because the drive might not be any real thing that is currently connected to the system. In such cases, the best bet might be to confirm that critical drives are being correctly seen/accessed without further problems being reported.

WarsawPact's answer to “M.a.r.k.T. _”'s question about “Which disk does \Device\Harddisk<X>\DR<Y> relate to?”

Old commentary

Hopefully the above process makes the desirable details less elusive than when some of this older commentary was first written:

One may also notice that \Device\Harddisk0\Partition0 is a symlink to \Device\Harddisk0\DR0

However, this doesn't necessarily point to the C:. One may go to \GLOBAL??\ and find that C: points to “\Device\HarddiskVolume1”. However, finding a relationship such as any one between \Device\HarddiskVolume1 and \Device\Harddisk0\Partition0 may remain elusive. Therefore, this does not necessarily seem like a full solution, although it may help to re-enforce information provided elsewhere, as well as showing some relationships of other symbolic links of the kernel (which may be interesting in seeing other links, even if not particularly useful for handling this event).

Using dd --list

One of the next most conclusive tools I've used has been's dd. (See the section on's dd --list).

First, some bad news. When using “ dd --list ”, the program has been known to appear to lock up. (Maybe the program was just stalled for several minutes. However, even that was deemed undesirable, so when this has been seen by the author of this text, the program was treated as if it had locked up.)

Furthermore, trying to kill the program would not seem to be effective for some time.

However, the good news is that even if that happens, the program may display some useful information first. Furthermore, although Windows initially seemed to have troubles killing the program, a bit of patience (several minutes) resulted in the program disappearing. So, this means that the behavior, which initially seemed like it might be a minor problem, actually did not end up being a substantial problem at all. (The program's behavior just led to requiring multiple minutes of patience.)

After downloading the program and extracting it, get to a command prompt and run:

dd --list
Analyzing examples

Let's look at a couple of examples from sample output of's dd --list. These examples quote just segments of that sample output. Viewing that sample output is recommended, as that may help make these samples be more understandable.

Some of these conclusions may be making some assumptions, such as some \Device\ entries corresponding with physical drives. Such an assumption might be invalid if the operating system doesn't tend to work directly work physical drives, but actually works with a RAID controller card (which is what communicates with the drives). In that case, Microsoft Windows might simply see the virtual device that gets presented by the RAID controller card, which might introduce a level of complexity which has been been resolved by the author of this text.


At first, it may look like there is little information available about this device. However, some further investigation shows that:

  • \Device\Harddisk0\Partition1 is related to \Device\HarddiskVolume1
  • Additional investigation shows that \Device\HarddiskVolume1 is related to the c:.
  • Therefore, \Device\Harddisk0\Partition1 is related to the c:.

Since both \Device\Harddisk0\Partition0 and \Device\Harddisk0\Partition1 are referencing the same physical device (which is Harddisk0), the conclusion is that \Device\Harddisk0\Partition0 does appear to be on the same physical drive as the C:.

Actual Findings

This sample text shows a fortunate case. We can conclusively determine which device this is.

\Device\Harddisk1\DR2 uses \Device\Harddisk1\ which is the same \Device\Harddisk number as what is seen by \Device\Harddisk1\DP(1)-0-+3 which is related to the disk that is mounted onto d:.

Hypothetical scenario

This sample text ended up being a bit more clear than some encountered real-world examples. So, let's just alter this sample a bit, just to show how to proceed when things aren't quite as conclusive. Let's pretend like:

  • there was no clear link to a device named \Device\Harddisk1\DP(1)-0-+3.
  • We are professional IT staff who want to make sure that this is not affecting the system's hard drive, which is the one data device on the system that is critical to keep running (in order to continue operations without significant data loss or downtime).

What would we do?

\Device\Harddisk1\DR2 does not appear to be on the same physical disk as the C:. This is figured out because:

  • The C: is related to \Device\HarddiskVolume1,
  • and \Device\HarddiskVolume1 is related to \Device\Harddisk0\Partition1,
  • and \Device\Harddisk0\ represents a different device than \Device\Harddisk1\

Since different numbers are shown on the \Device\Harddisk# objects, they are believed to be different devices.

Text commentary

The above section was named “A process”. That rather generic-sounding name was initially selected due to question about how useful the process was. However, upon working with it more and thinking further about the results, that currently seems to be the best process. (Namely, start with WinObj, and then get confirmation with “dd --list” if that seems helpful.)

The above section, currently labelled “A process”, represents the steps that currently appear to be the best-looking steps towards getting useful information quickly. Additional information is presented for people interested in looking further, but currently the remaining information is not expected to do a better job and finding better-sounding answers.

It is the thoughts of the author of this text that such messages are dealing with a rather technical part of Microsoft Windows. This part of Microsoft Windows simply reports the event, and doesn't bother to go through an elaborate process to try to find another description of the device. Although humans may prefer a more detailed description of the device, we may be able to typically appreciate the idea that some sections of Microsoft Windows don't go through elaborate processes that would slow things down. (People like speed.) Granted, priorities can feel a bit different when important things seem to be at stake.

To anyone who is reading this, still seeking answers that still seem to be needed: Good luck.

If you're feeling frustrated at not finding answers quickly, remember that was predicted. You may also want to re-assess some ideas, after having gathered what information could be obtained. For instance, you may wish to look over the “A potential roadmap” section again, particularly the spot which pointed to a section that discusses “timeout” events being able to throw this sort of error. Did backup jobs start up? Is the hardware rather old. Consider what ideas seem to make sense (matching available data.) Consider what drive is referred to, and how critical this seems to be (or not).

Official documentation

Official documentation may not lead to quickly coming up with the answer. However, for the daring: Some documentation that addresses this fairly directly may be Microsoft KB Q159865: How to Distinguish a Physical Disk Device from an Event Message. It recommends going to HKLM\Hardware\DeviceMap, and then looking under either Atdisk if using non-SCSI (ATA/IDE/ATAPI), or under SCSI if SCSI is actually being used. However, the guide doesn't give super clear details on how to decode the information found there. Furthermore, “M.a.r.k.T. _”'s question about “Which disk does \Device\Harddisk<X>\DR<Y> relate to?” states, “This article points to registry settings that disappeared in Windows 2000.”

Here are some other resources which have been seen:

Here are some approaches, which may or may not lead to a definite identification:

A device with a name that starts with \Device\Harddisk followed by a one or two digit number, followed by \DR followed by a number, seems to generally be a USB drive (which may or may not still exist). Note that this does not seem to always be true, as shown in the analysis about Interpreting the results of “DMDiag -v”'s output.

Beyond that generalized advice, the trick is to run some software which will show the name of the device that appears in the log file, and which also shows the name of a drive (such as “PHYSICALDRIVE0”). If those names can be matched up, then it should be rather doable to identify a disk from the disk's device name.

So, which software to use to accomplish that? There are a few choices: the guide doesn't necessarily recommend any one over the other as a solution which is both simplest and rather definite. Some options may be covered in the section about Identifying a physical disk in Microsoft Windows. Here are some additional options:

Using DMDiag

Depending on which operating system is being used (and possibly whether this software is pre-installed), the easiest way may be to use “DMDiag.exe -v” (which works, although some documentation has suggested “DMDiag.exe /v” and “DMDiag.exe /v /f output.txt”).

Having/getting the software

DMDiag may be bundled in with the operating system (with Windows Server 2003) or part of a “Support Tools” package for the operating system (which may be found on the operating system's original media and may be downloadable) or as a separate download. For Win2K, XP, and 2003, see if it is installed or downloadable. Once that is placed under the “Windows Support Tools” folder in the “Program Files” area (which might be pointed to by the %ProgramFiles% environment variable), run “DMDiag.exe -v”.

For some more information, including download locations, for DMDiag.exe, see these resources:

Windows Server 2003

See: documentation for DMDiag for 2003 or Windows XP Pro (and related links in the “See Also” section).

For Win Svr 2003, it may come with DMDiag. For Windows Server 2003, if there are many drives then ensure the operating system has a relavent Hotfix applied, such as MS KB 941602's update to DMDiag (MS KB 941602 Hotfix request).

Windows XP for 64-bit systems

For Windows XP for x64 systems, if there are many drives then ensure the operating system has a relavent Hotfix applied, such as MS KB 941602's update to DMDiag (MS KB 941602 Hotfix request).

Windows XP (32-bit)
download details page for Windows XP SP2 Support Tools. See: documentation for DMDiag for XP/2003 (and related links in the “See Also” section).
Windows 2000
download details page related to Win2K, Win2K version of DMDiag referred to by KB 927229.
Newer versions of Windows
DMDiag is not available. For Win Svr 2008/Windows 7, one may notice that Command-line Reference (A-Z List) does not show DMDiag. (That page was found by looking for a path similar to one that reaches the documentation for DMDiag for XP/2003.) This suggests that it is not available in these newer operating systems, and it also appears to not be available for Vista.
Using the Software

Some documentation by Microsoft is available. Details on this is actually in the section about getting the software.

Dmdiag example has some example output of what this will look like. The page may not make it clear that the “Sample DmDiag output” is obtained with using “DMDiag -v”.

In DMDiag -v's output, there is some fairly high likelihood that the section called “Drive Letter Usage, Drive Type” may reference the device name being sought. That may allow an easy way to match the device name to a drive letter. However, if that section does not absolutely answer the question, be sure to also note the results of the “Mount Points” section (if it is not blank) and any sections that start with the string “ \Device\”. (In the Dmdiag example, this is referring to the section with the header of “ \Device\Harddisk0 ”.)

If one is copying and pasting select portions of the “DMDiag -v” output for possible future reference, the sections that start with “ \Device\” may be useful to record (in addition to the “Drive Letter Usage, Drive Type” section).

[#intpdmdg]: Interpreting the results of “DMDiag -v”'s output
Let's use the example output on Microsoft's DmDiag Example page to determine whether \Device\Harddisk0\DR0 is part of the C:. First, we search for \Device\Harddisk0\DR0 and we find that it is listed (as a precise match) under the \Device\Harddisk0 section. Now, to check if the C: points to something in that same \Device\Harddisk0 section, we look at earlier output and notice that C: is related to \Device\HarddiskVolume1. We see that \Device\HarddiskVolume1 is pointed to by \Device\Harddisk0\Partition0 which is in the same section, \Device\Harddisk0. All of these are part of the \Device\Harddisk0 section, so the C: and the device that generated the error do appear to be related to the same physical drive.

This command may show a name for one device name. That doesn't stand as good of a chance of being informative as some of these other options, but there are two advantages to this command: It is pre-installed (which is convenient), and it may be able to get information from a remote machine. systeminfo | find "Boot Device"

Disk Management (MMC diskmgmt.msc)

This method may or may not be tell-tale. The functionality is likely not avaialble in Win NT 4, but should be in Win2K. Microsoft KB Q159865 makes some reference to the following method: Run Disk Management. In the lower pane, open up the Context/Shortcut/“Right-click” menu for the left-most rectangle related to a Disk. Using a rodent, this may be done as easily as right-clicking the grey background, underneath the name like “Disk 0”. On the menu, choose Properties.

It might be true that the numbers shown in the disk names will correspond to a number if the device name uses a format of \Device\Harddisk0 (or something similar like \Device\Harddisk0\Partition0, but not including \Device\HarddiskVolume0.)


The software is downloadable (ListDOSDevices (zip file)). Some official documentation is available (ListDOSDevices (English) documentation).

Extract the files and then run:

echo DoNotPause | ListDOSDevices verbose >> LsDosDev.txt

The program outputs some newline sequences which are just line feeds, without carriage returns (even though some other lines do have carriage returns). Therefore, running Notepad is not recommended. (If viewing this file in modern Microsoft Windows, which seems likely, use Write which will run Wordpad.)

If the name of the device shows in the upper part of the file, before the -------------------- then a drive letter can easily be matched to the device name. Otherwise, search for the device name that needs to be identified. If the line is indented, look above the indented line for a line that isn't indented. The line that isn't indented is a sort of “section” in this file. Note the name of the section (which is the contents of the first line), and all of the other names in that section (which are listed in the subsequent lines that are indented). All of those device names in one section are related.

The device may be mentioned more than once in the file. After noting all of the devices in one “section” of the file, keep searching again until a list has been made containing all of the device names in all of the sections with an occurrence of the desired device name.

If more results are desired (especially if there are no results), and if the name being sought is in the form of \Device\Harddisk#\DR#, then try removing everything after the last backslash and the last backslash: Just search for the relevant \Device\Harddisk#.

Hopefully by following all of this advice, a drive letter or the name of a physical drive will become apparent. (The name of the physical drive will start with the letters “PHYSICALDRIVE”, and will then contain a number.) If a physical device name is found, see the section about identifying a physical disk.

[#chrysodd]:'s dd --list

This software has been linked to from Intel's “Dd for Windows” web page which was at (but which now seems to no longer exist at that address). (There was a section on the page called “Downloads for dd family”. Be sure to get the a version that says “Binary” unless one plans to use Delphi source code.)

Although Intel's site may not be referring to the program as much, the prior endorsement did provide some comfort that the software was reliably trustworthy. And, the program can still be downloaded from the original author's site at's dd

dd --list 2> dd--list.txt
type dd--list.txt

See: sample output of's dd --list.

One may use “dd --list”. This will help match the \Device\HarddiskVolume## names to the mount points (which are typically drive letters), and mention whether the type is removable media or fixed media. All of this is standard fare, matching capabilities by “ DMDiag -v ” and ListDosDevices. However, another thing this does is matches the Volume{GUID} syntax, which may be helpful to match information found in the verbose output of ListDosDevices.

On a side note for developers, since this has source code released, its source code may help development efforts if anyone wants to make a tool to try to streamline a bunch of this stuff. (The site's reading partitions via the back door provides some very tech heavy details which may be useful for developers.)

Other Tools

There may be other methods, such as using WinObj. The following are some tools that look like they may be helpful, although details on successfully using them (well enough to completely resolve the issue) are not fully provided here.

(A brief blurb about WinObj was in this section, although it has now been moved.)

Perhaps one or more of the following might provide information that might be accurate/useful:

WMIC partition get Caption,CreationClassName,Description,DeviceID,DiskIndex,Index,Name,NumberOfBlocks,PrimaryPartition,Size,StartingOffset,Type
WMIC LOGICALDISK get Caption,Description,DeviceID,DriveType,FileSystem,FreeSpace,MediaType,Name,Size,VolumeDirty,VolumeName,VolumeSerialNumber
WMIC VOLUME get BootVolume,Capacity,Description,DeviceID,DirtyBitSet,DriveLetter,FileSystem,FreeSpace,Label,Name,PageFilePresent,SerialNumber,SystemVolume

In the results of the first command, DiskIndex may relate to the PHYSICALDRIVE# name. Index may be the partition number.