Drive later change - why?

I use Windows 7 64 home premium on PC and laptop. I back up using Cobian
to an external drive set as G:..

The other day it began to fail, not being able to create the directory. It
took me a couple of days to realise.. The drive had been allocated to H:.
There is no drive G:.

Lately I have been piddling around trying unsuccessfully to create a
homegroup (well it creates one but my PC can not access the laptop). Of
course there is also the standard Windows network via which I can access
either the PC or laptop from either by logging in so the homegroup thing
does not matter.

I use Truecrypt and always use drive X: for that. The only other thing I
use which affects drive letters is Daemon tools which I have not run for a
while. I am sure that nobody else has altered the drive letters. I know
Truecrypt is defunct but I have not yet got a replacement.

So why did drive G: get changed to H:?

On 04/04/2015 00:59:09, Johnbee wrote:
I use Windows 7 64 home premium on PC and laptop. I back up using Cobian
to an external drive set as G:..

The other day it began to fail, not being able to create the directory. It
took me a couple of days to realise.. The drive had been allocated to H:.
There is no drive G:.

Lately I have been piddling around trying unsuccessfully to create a
homegroup (well it creates one but my PC can not access the laptop). Of
course there is also the standard Windows network via which I can access
either the PC or laptop from either by logging in so the homegroup thing does
not matter.

I use Truecrypt and always use drive X: for that. The only other thing I use
which affects drive letters is Daemon tools which I have not run for a while.
I am sure that nobody else has altered the drive letters. I know Truecrypt
is defunct but I have not yet got a replacement.

So why did drive G: get changed to H:?

I have had that happen after I have plugged in a usb card reader.
Main installed computer drives are C, D, E and F.
I (did)backup to an external drive J using a usb slot. My last hard
drive on the PC is F.
Unplug the external drive and plug in the card reader then when viewed
in explorer it creates or shows drives G,H,I and J for the different
card formats.
Consequently, when I unplug the card reader, then next plug in the
external drive the drive letter has changed from J to K.

I have now set the external drive letter to P to give me more room to
manoeuvre.

--
mick

Johnbee wrote:

I use Windows 7 64 home premium on PC and laptop. I back up using Cobian
to an external drive set as G:..

The other day it began to fail, not being able to create the directory. It
took me a couple of days to realise.. The drive had been allocated to H:.
There is no drive G:.

Lately I have been piddling around trying unsuccessfully to create a
homegroup (well it creates one but my PC can not access the laptop). Of
course there is also the standard Windows network via which I can access
either the PC or laptop from either by logging in so the homegroup thing
does not matter.

I use Truecrypt and always use drive X: for that. The only other thing I
use which affects drive letters is Daemon tools which I have not run for a
while. I am sure that nobody else has altered the drive letters. I know
Truecrypt is defunct but I have not yet got a replacement.

So why did drive G: get changed to H:?

When you plugged in the USB drive, was G: already assigned? After you
plugged in the USB drive and saw it was assigned H:, did you see a drive
assigned to G:?

USB assignment goes by the next available drive letter; i.e., which one
next would be available. A: and B: are fixed to floppy drives (even if
you don't have any). C: is typically for the partition on the hard disk
wherein Windows resides. That you expect a USB to be assigned G: when
plugged in means you have other drives before it. D:, E:, and F:, must
already be assigned, like to other partititons on the same or different
HDDs or SSDs, to optical drives, or other USB drives you leave plugged
in. G: would get used if it was the next available drive letter.

If you left a USB drive or somehow already had G: assigned then it
couldn't be used when you plugged in your USB drive. So the next
obvious choice is to try the next letter (H.

Some users try to assign a drive letter using Disk Management
(diskmgmt.msc). That isn't a permanent solution. Something else
plugged in and assigned G: would mean you don't get G: when you later
plug in your USB drive.

You never mentioned using 3rd party software that better manages drive
letter assignment for USB drives (and blocks the use of those same drive
letters when other devices try to use them). So I have to figure you
are just using what Windows gives you. Assignment is in sequential
order and you cannot use the same drive letter for multiple devices. So
plugging in a USB device means it normally gets the next available drive
letter. G: was in use so your USB drive, when plugged in, had to use
the next available one which was H:. There really isn't enough firmware
signature difference between same-vendor USB drives to ensure using Disk
Management will retain the same drive letter for every time you plug in
a USB drive.

You need something MORE than what you get in Windows if you want decent
drive letter management. In fact, what you want is to *reserve* drive
letters for specific devices. There are some tools to do reservation
and management of USB drive letter assignment. The only one that I
recall is USBDLM (USB drive letter manager). That one is free but
requires you edit an .ini file to configure it.

http://www.uwe-sieber.de/usbdlm_e.html

As I mentioned, if you have a bunch of same-vendor USB drives (flash or
HDD), they have little variance in their firmware sigs to differentiate
between them. Something must be available that makes one look different
than another so a drive letter manager can figure out when not to dole
out a drive letter and when it should. HDDs (in USB enclosures) can
have different drive IDs in their boot record (MBR or UEFI) to
differentiate between them; however, the USB-to-IDE/SATA circuitry sits
between the physical drive and the OS so I don't know that drive IDs on
USB-attached drives is usable. So make sure you use a different volume
ID (aka volume label) on each of your USB-attached drives (whether
flash, HDD, or SSD) to help differentiate between them. USBDLM can use
the volume ID to determine which drive letter is reserved for a
particular USB-attached drive.

What this means is that you need MORE than what Microsoft gave you in
Windows to ensure the same drive letter gets reserved and assigned to a
particular external drive. There may be other similar utilities to
USBDLM.

In article , says...

I use Windows 7 64 home premium on PC and laptop. I back up using Cobian
to an external drive set as G:..

The other day it began to fail, not being able to create the directory. It
took me a couple of days to realise.. The drive had been allocated to H:.
There is no drive G:.

Lately I have been piddling around trying unsuccessfully to create a
homegroup (well it creates one but my PC can not access the laptop). Of
course there is also the standard Windows network via which I can access
either the PC or laptop from either by logging in so the homegroup thing
does not matter.

I use Truecrypt and always use drive X: for that. The only other thing I
use which affects drive letters is Daemon tools which I have not run for a
while. I am sure that nobody else has altered the drive letters. I know
Truecrypt is defunct but I have not yet got a replacement.

So why did drive G: get changed to H:?

I've never encountered this problem once I've assigned a specific drive
letter to my various externals. I used "O" to "U" each assigned to a
specific external drive I use. First time a new thumbdrive hits system I
assign it "K" which is never an issue because I never have more than one
plugged in at any one time.

I do have a cheap USB card reader that when I plug it in it seems to
remove my built-in card reader's four assigned drive letter "W" thru
"Z" even though I've told system to use "K" to "N". I have to extract
and insert one of the cards I keep in it for them to reappear but they
do keep their assigned drive letters.

I seldom "mount" a networked drive and give it a drive letter. Usually a
shortcut is all that's required. If I wanted to, I could have enough
devices etc. attached that I'd use up all drive letters

pjp wrote:

johnbee says...

I back up using Cobian to an external drive set as G:..

The drive had been allocated to H:. There is no drive G:.

So why did drive G: get changed to H:?

I've never encountered this problem once I've assigned a specific drive
letter to my various externals. I used "O" to "U" each assigned to a
specific external drive I use. First time a new thumbdrive hits system I
assign it "K" which is never an issue because I never have more than one
plugged in at any one time.

How do you assign a drive letter to a USB-attached device? By using
Device Manager (devmgmt.msc)? That works as long as the software or
device assignment doesn't step on that drive letter assignment. Using
Devmgmt is more like reserving a drive letter than fixing it to a
device. Then there is still the problem of identifying the device to
match up the drive letter. If the firmware signature or the
presentation data offered by the USB device isn't unique enough to
identify it then Windows won't know that you put the same device in the
same slot. If you move to a different slot, reserved drive assignment
is even more tenuous. Microsoft has done a poor job in helping users
manage drive letter assignment to removable devices.

I seldom "mount" a networked drive and give it a drive letter. Usually a
shortcut is all that's required. If I wanted to, I could have enough
devices etc. attached that I'd use up all drive letters

Some [newer] software will let you use a UNC path to the networked
resource. Alas, some old software still demands the use of a drive
letter so you're stuck having to mount the drive with a letter for it.
UNC pathing has been around so long that it's a shame that software
doesn't use it. No having to mount, no slowdown on Windows boot to
mount (map) the drives, no slowdown in Windows Explorer having to
refresh itself as changes are made to the mapped drive.

Maybe UNC pathing is too *NIX like for Windows software authors to
embrace that method of referencing a resource. UNC was available back
in Windows NT4, maybe earlier. 20 years later and software mostly lacks
UNC support.

In article , says...

pjp wrote:

johnbee says...

I back up using Cobian to an external drive set as G:..

The drive had been allocated to H:. There is no drive G:.

So why did drive G: get changed to H:?

I've never encountered this problem once I've assigned a specific drive
letter to my various externals. I used "O" to "U" each assigned to a
specific external drive I use. First time a new thumbdrive hits system I
assign it "K" which is never an issue because I never have more than one
plugged in at any one time.

How do you assign a drive letter to a USB-attached device? By using
Device Manager (devmgmt.msc)? That works as long as the software or
device assignment doesn't step on that drive letter assignment. Using
Devmgmt is more like reserving a drive letter than fixing it to a
device. Then there is still the problem of identifying the device to
match up the drive letter. If the firmware signature or the
presentation data offered by the USB device isn't unique enough to
identify it then Windows won't know that you put the same device in the
same slot. If you move to a different slot, reserved drive assignment
is even more tenuous. Microsoft has done a poor job in helping users
manage drive letter assignment to removable devices.


That's not been my experience. Once I use Device Manager's "drive letter
assignment" dialog to fix the disk to a specific drive leter it always
shows there regardless of port I plug it into. Mind you I insure I
assign letters so none ever are simultaeously used along with another.
Only exception is small thumbdrives which are all assigned a specific
letter with no issues because I never have more than one plugged in at
same time.

I seldom "mount" a networked drive and give it a drive letter.
Usually a
shortcut is all that's required. If I wanted to, I could have enough
devices etc. attached that I'd use up all drive letters

Some [newer] software will let you use a UNC path to the networked
resource. Alas, some old software still demands the use of a drive
letter so you're stuck having to mount the drive with a letter for it.
UNC pathing has been around so long that it's a shame that software
doesn't use it. No having to mount, no slowdown on Windows boot to
mount (map) the drives, no slowdown in Windows Explorer having to
refresh itself as changes are made to the mapped drive.

Maybe UNC pathing is too *NIX like for Windows software authors to
embrace that method of referencing a resource. UNC was available back
in Windows NT4, maybe earlier. 20 years later and software mostly lacks
UNC support.

Hi, pjp and VanguardLH.

You mean DISK Management (diskmgmt.msc), not DEVICE Management
(devmgmt.msc).

Windows by default assigns the next available letter to a newly-installed
device. But, if you use Disk Management to specifically assign a letter to
that new device, then Disk Management will use that assigned letter each
time that device is re-connected. if possible. But if that letter has been
assigned to a different device in the meantime, then Disk Management will
revert to its default behavior.

The terminology can get confusing: A "DRIVE" letter actually refers to a
partition on a disk, rather than to the disk itself. So, for example,
Drives C:, D:, X: and Y: can all reside on Disk 0. (Disks are assigned
numbers, starting with zero, by the BIOS before Windows even loads.) And
"drive" letters are also assigned to many other kinds of devices, such as
USB flash drives, optical discs (CD/DVD), SD cards for cameras, network
drives, etc. Most of these devices can be partitioned into multiple
"drives", too, but usually are not.

RC
--
R. C. White, CPA
San Marcos, TX

Microsoft Windows MVP (2002-2010)
Windows Live Mail 2012 (Build 16.4.3528.0331) in Win8.1 Pro w/Media Center

"pjp" wrote in message
...

In article , says...

pjp wrote:

johnbee says...

I back up using Cobian to an external drive set as G:..

The drive had been allocated to H:. There is no drive G:.

So why did drive G: get changed to H:?

I've never encountered this problem once I've assigned a specific drive
letter to my various externals. I used "O" to "U" each assigned to a
specific external drive I use. First time a new thumbdrive hits system I
assign it "K" which is never an issue because I never have more than one
plugged in at any one time.

How do you assign a drive letter to a USB-attached device? By using
Device Manager (devmgmt.msc)? That works as long as the software or
device assignment doesn't step on that drive letter assignment. Using
Devmgmt is more like reserving a drive letter than fixing it to a
device. Then there is still the problem of identifying the device to
match up the drive letter. If the firmware signature or the
presentation data offered by the USB device isn't unique enough to
identify it then Windows won't know that you put the same device in the
same slot. If you move to a different slot, reserved drive assignment
is even more tenuous. Microsoft has done a poor job in helping users
manage drive letter assignment to removable devices.


That's not been my experience. Once I use Device Manager's "drive letter
assignment" dialog to fix the disk to a specific drive leter it always
shows there regardless of port I plug it into. Mind you I insure I
assign letters so none ever are simultaeously used along with another.
Only exception is small thumbdrives which are all assigned a specific
letter with no issues because I never have more than one plugged in at
same time.

I seldom "mount" a networked drive and give it a drive letter.
Usually a
shortcut is all that's required. If I wanted to, I could have enough
devices etc. attached that I'd use up all drive letters

Some [newer] software will let you use a UNC path to the networked
resource. Alas, some old software still demands the use of a drive
letter so you're stuck having to mount the drive with a letter for it.
UNC pathing has been around so long that it's a shame that software
doesn't use it. No having to mount, no slowdown on Windows boot to
mount (map) the drives, no slowdown in Windows Explorer having to
refresh itself as changes are made to the mapped drive.

Maybe UNC pathing is too *NIX like for Windows software authors to
embrace that method of referencing a resource. UNC was available back
in Windows NT4, maybe earlier. 20 years later and software mostly lacks
UNC support.

R. C. White wrote:

Hi, pjp and VanguardLH.

You mean DISK Management (diskmgmt.msc), not DEVICE Management
(devmgmt.msc).

Windows by default assigns the next available letter to a newly-installed
device. But, if you use Disk Management to specifically assign a letter to
that new device, then Disk Management will use that assigned letter each
time that device is re-connected. if possible. But if that letter has been
assigned to a different device in the meantime, then Disk Management will
revert to its default behavior.

The terminology can get confusing: A "DRIVE" letter actually refers to a
partition on a disk, rather than to the disk itself. So, for example,
Drives C:, D:, X: and Y: can all reside on Disk 0. (Disks are assigned
numbers, starting with zero, by the BIOS before Windows even loads.) And
"drive" letters are also assigned to many other kinds of devices, such as
USB flash drives, optical discs (CD/DVD), SD cards for cameras, network
drives, etc. Most of these devices can be partitioned into multiple
"drives", too, but usually are not.

RC

What does Disk Mgmt (thanks for the correction) do to recognize the SAME
device got plugged in? There needs to be a sig on the device to
identify it; however, I would think the firmware sig would be the same
across the same model for the same brand.

Do USB flash drives all have a different firmware sig?

HDDs have a disk ID (in the MBR and, I assume, also in GPT) that can
identify them but I don't know it is accessible through the USB
interface (SATA to USB).

When plugging in USB devices, their presentation data gets used in
creating an enumeration entry for that device. You can find it under:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\U SB
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\U SBSTOR

That's why, for example, when having problem with recognition of a USB
device that you can delete its enumeration data in the registry to force
re-recognition of that device rather than rely on the old enum data.
I believe the USBSTOR key is where USB-attached drive types are
registered. If you plugged in a USB drive and removed it, its enum data
remains in the registry. For example, there is still a "PNY" entry
under there although my old USB PNY flash drive got tossed awhile back
(it went bad). Under there will be a registry subkey with a HardwareID
data item with the device ID(s) for a device that you plugged in;
however, I don't have multiples of the same device (same brand and model
and version) to see how that hardware ID is different for each separate
instance of the same product.

Do you have multiple USB flash drives that are the same brand and model
so you can see if they have the same or different hardware IDs?

You don't have to use the registry to see this enumeration data. Run
Disk Management and look at the properties of the USB drive when it is
plugged in and after recognized. Under the properties for the USB
drive, go to the Details tab. Select "Hardware ID" from the drop-down
list of enumeration values.

Enumeration data is the only means that I know of that the OS could
identify what type is the USB device and provide some kind of signature
of the device.

VanguardLH wrote:
R. C. White wrote:

Hi, pjp and VanguardLH.

You mean DISK Management (diskmgmt.msc), not DEVICE Management
(devmgmt.msc).

Windows by default assigns the next available letter to a newly-installed
device. But, if you use Disk Management to specifically assign a letter to
that new device, then Disk Management will use that assigned letter each
time that device is re-connected. if possible. But if that letter has been
assigned to a different device in the meantime, then Disk Management will
revert to its default behavior.

The terminology can get confusing: A "DRIVE" letter actually refers to a
partition on a disk, rather than to the disk itself. So, for example,
Drives C:, D:, X: and Y: can all reside on Disk 0. (Disks are assigned
numbers, starting with zero, by the BIOS before Windows even loads.) And
"drive" letters are also assigned to many other kinds of devices, such as
USB flash drives, optical discs (CD/DVD), SD cards for cameras, network
drives, etc. Most of these devices can be partitioned into multiple
"drives", too, but usually are not.

RC

What does Disk Mgmt (thanks for the correction) do to recognize the SAME
device got plugged in? There needs to be a sig on the device to
identify it; however, I would think the firmware sig would be the same
across the same model for the same brand.

Do USB flash drives all have a different firmware sig?

HDDs have a disk ID (in the MBR and, I assume, also in GPT) that can
identify them but I don't know it is accessible through the USB
interface (SATA to USB).

When plugging in USB devices, their presentation data gets used in
creating an enumeration entry for that device. You can find it under:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\U SB
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\U SBSTOR

That's why, for example, when having problem with recognition of a USB
device that you can delete its enumeration data in the registry to force
re-recognition of that device rather than rely on the old enum data.
I believe the USBSTOR key is where USB-attached drive types are
registered. If you plugged in a USB drive and removed it, its enum data
remains in the registry. For example, there is still a "PNY" entry
under there although my old USB PNY flash drive got tossed awhile back
(it went bad). Under there will be a registry subkey with a HardwareID
data item with the device ID(s) for a device that you plugged in;
however, I don't have multiples of the same device (same brand and model
and version) to see how that hardware ID is different for each separate
instance of the same product.

Do you have multiple USB flash drives that are the same brand and model
so you can see if they have the same or different hardware IDs?

You don't have to use the registry to see this enumeration data. Run
Disk Management and look at the properties of the USB drive when it is
plugged in and after recognized. Under the properties for the USB
drive, go to the Details tab. Select "Hardware ID" from the drop-down
list of enumeration values.

Enumeration data is the only means that I know of that the OS could
identify what type is the USB device and provide some kind of signature
of the device.

USB devices have a serial number ("iSerialNumber").

In this example, two identical Lexar Jumpdrive USB keys,
show their serial number. No matter what port this is plugged
into, the serial number tells the system which device it is,
and not to create a fresh entry when it is plugged in. The
old entry can be used from the Registry.

http://i59.tinypic.com/10z7gx5.gif

What you're seeing there, is an example of the ideal case.

Not all USB hardware is serialized.

Paul

On Sat, 4 Apr 2015 23:06:29 -0500, "R. C. White"
wrote:


The terminology can get confusing: A "DRIVE" letter actually refers to a
partition on a disk, rather than to the disk itself. So, for example,
Drives C:, D:, X: and Y: can all reside on Disk 0.


Yes, and to add to that, many people don't realize that even if a disk
has nothing on it but a single drive letter, C:, that C: is a
partition.

Many people mistakenly think that to partition a disk is to divide it
into two or more partitions. But in fact it's to create one or more
partitions on it.

Paul wrote:

VanguardLH wrote:
R. C. White wrote:

Hi, pjp and VanguardLH.

You mean DISK Management (diskmgmt.msc), not DEVICE Management
(devmgmt.msc).

Windows by default assigns the next available letter to a newly-installed
device. But, if you use Disk Management to specifically assign a letter to
that new device, then Disk Management will use that assigned letter each
time that device is re-connected. if possible. But if that letter has been
assigned to a different device in the meantime, then Disk Management will
revert to its default behavior.

The terminology can get confusing: A "DRIVE" letter actually refers to a
partition on a disk, rather than to the disk itself. So, for example,
Drives C:, D:, X: and Y: can all reside on Disk 0. (Disks are assigned
numbers, starting with zero, by the BIOS before Windows even loads.) And
"drive" letters are also assigned to many other kinds of devices, such as
USB flash drives, optical discs (CD/DVD), SD cards for cameras, network
drives, etc. Most of these devices can be partitioned into multiple
"drives", too, but usually are not.

RC

What does Disk Mgmt (thanks for the correction) do to recognize the SAME
device got plugged in? There needs to be a sig on the device to
identify it; however, I would think the firmware sig would be the same
across the same model for the same brand.

Do USB flash drives all have a different firmware sig?

HDDs have a disk ID (in the MBR and, I assume, also in GPT) that can
identify them but I don't know it is accessible through the USB
interface (SATA to USB).

When plugging in USB devices, their presentation data gets used in
creating an enumeration entry for that device. You can find it under:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\U SB
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\U SBSTOR

That's why, for example, when having problem with recognition of a USB
device that you can delete its enumeration data in the registry to force
re-recognition of that device rather than rely on the old enum data.
I believe the USBSTOR key is where USB-attached drive types are
registered. If you plugged in a USB drive and removed it, its enum data
remains in the registry. For example, there is still a "PNY" entry
under there although my old USB PNY flash drive got tossed awhile back
(it went bad). Under there will be a registry subkey with a HardwareID
data item with the device ID(s) for a device that you plugged in;
however, I don't have multiples of the same device (same brand and model
and version) to see how that hardware ID is different for each separate
instance of the same product.

Do you have multiple USB flash drives that are the same brand and model
so you can see if they have the same or different hardware IDs?

You don't have to use the registry to see this enumeration data. Run
Disk Management and look at the properties of the USB drive when it is
plugged in and after recognized. Under the properties for the USB
drive, go to the Details tab. Select "Hardware ID" from the drop-down
list of enumeration values.

Enumeration data is the only means that I know of that the OS could
identify what type is the USB device and provide some kind of signature
of the device.

USB devices have a serial number ("iSerialNumber").

In this example, two identical Lexar Jumpdrive USB keys,
show their serial number. No matter what port this is plugged
into, the serial number tells the system which device it is,
and not to create a fresh entry when it is plugged in. The
old entry can be used from the Registry.

http://i59.tinypic.com/10z7gx5.gif

What you're seeing there, is an example of the ideal case.

That would work if Windows used that info. I found the following:

http://blogs.msdn.com/b/usbcoreblog/...-a-device.aspx

Looks like there is a "serial number string descriptor query" that gets
the serial number. Presumably the iSerialNumber field shown in the USB
utility is the serial number for the device that Windows will see.

When I used Device Mgmt (safer then using regedit to look at enumeration
data) and the properties of a drive under the Detail tab, I could see
hardware IDs that looked like:

ST3750528AS_____________________________CC44____
(for a Seagate HDD)

WDC_WD10EZEX-00RKKA0____________________80.00A80
(for a Western Digital HDD)

Alas, I do not have another same-vendor and same-model HDD to compare
how their hwids would differ.

Had to go back into the registry to look at the enumeration data.
According to:

https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx

the USB driver assigns a name to the device, like:

VID_xxxx&PID_yyyy

For my crappy digital camera, although not connected but its enum data
remains in the registry, under:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\U SBSTOR\

there was created the enum key named:

Disk&Ven_FUJIFILM&Prod_USB-DRIVEUNIT&Rev_1.00

That's not unique. If I plugged in another camera of same brand model,
it would have the same value. I don't see anything in that enum key for
that device that yet uniquely identifies it.

Not until I wander down through its subkeys do I find a "Hardware ID"
data item that contains what looks like multiple IDs which progress from
specifically identifying the device to more generic IDs.

Alas, I don't have multiples of hardware that are of the same brand and
model to see how their enumeration values would differ. You have a
couple USB flash drives of same brand and model and showed the USB
utility retrieved different serial number for them.

If you look under:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\U SBSTOR\

and find the enum entry for each of those devices while they are plugged
(or after you plug them in and unplug them), do they have the same or
different Hardware ID values? Can you see the serial number in any of
the data items or in the key names for the enum data for those devices?

The reason why I am curious is that I have used the devcon.exe program
(command-line equivalent of Device Management - except devcon.exe is old
and only a 32-bit version exists for x86 architecture, no x64 version
and the IA-64 is for Itanium) to disable and enable devices,
specifically hard disks. The hardware ID is all I've been able to
figure out how to specify which HDD to disable/enable (and, as I recall,
is the only parameter devcon uses to identify the device). So the name
of the ENUM key for the device doesn't look to identify the device but
it's the Hardware ID in that device's enumeration data used to identify
the device. If the serial number is in there somewhere, I'd like to
know where it is.

VanguardLH wrote:
Paul wrote:

VanguardLH wrote:
R. C. White wrote:

Hi, pjp and VanguardLH.

You mean DISK Management (diskmgmt.msc), not DEVICE Management
(devmgmt.msc).

Windows by default assigns the next available letter to a newly-installed
device. But, if you use Disk Management to specifically assign a letter to
that new device, then Disk Management will use that assigned letter each
time that device is re-connected. if possible. But if that letter has been
assigned to a different device in the meantime, then Disk Management will
revert to its default behavior.

The terminology can get confusing: A "DRIVE" letter actually refers to a
partition on a disk, rather than to the disk itself. So, for example,
Drives C:, D:, X: and Y: can all reside on Disk 0. (Disks are assigned
numbers, starting with zero, by the BIOS before Windows even loads.) And
"drive" letters are also assigned to many other kinds of devices, such as
USB flash drives, optical discs (CD/DVD), SD cards for cameras, network
drives, etc. Most of these devices can be partitioned into multiple
"drives", too, but usually are not.

RC
What does Disk Mgmt (thanks for the correction) do to recognize the SAME
device got plugged in? There needs to be a sig on the device to
identify it; however, I would think the firmware sig would be the same
across the same model for the same brand.

Do USB flash drives all have a different firmware sig?

HDDs have a disk ID (in the MBR and, I assume, also in GPT) that can
identify them but I don't know it is accessible through the USB
interface (SATA to USB).

When plugging in USB devices, their presentation data gets used in
creating an enumeration entry for that device. You can find it under:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\U SB
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\U SBSTOR

That's why, for example, when having problem with recognition of a USB
device that you can delete its enumeration data in the registry to force
re-recognition of that device rather than rely on the old enum data.
I believe the USBSTOR key is where USB-attached drive types are
registered. If you plugged in a USB drive and removed it, its enum data
remains in the registry. For example, there is still a "PNY" entry
under there although my old USB PNY flash drive got tossed awhile back
(it went bad). Under there will be a registry subkey with a HardwareID
data item with the device ID(s) for a device that you plugged in;
however, I don't have multiples of the same device (same brand and model
and version) to see how that hardware ID is different for each separate
instance of the same product.

Do you have multiple USB flash drives that are the same brand and model
so you can see if they have the same or different hardware IDs?

You don't have to use the registry to see this enumeration data. Run
Disk Management and look at the properties of the USB drive when it is
plugged in and after recognized. Under the properties for the USB
drive, go to the Details tab. Select "Hardware ID" from the drop-down
list of enumeration values.

Enumeration data is the only means that I know of that the OS could
identify what type is the USB device and provide some kind of signature
of the device.
USB devices have a serial number ("iSerialNumber").

In this example, two identical Lexar Jumpdrive USB keys,
show their serial number. No matter what port this is plugged
into, the serial number tells the system which device it is,
and not to create a fresh entry when it is plugged in. The
old entry can be used from the Registry.

http://i59.tinypic.com/10z7gx5.gif

What you're seeing there, is an example of the ideal case.

That would work if Windows used that info. I found the following:

http://blogs.msdn.com/b/usbcoreblog/...-a-device.aspx

Looks like there is a "serial number string descriptor query" that gets
the serial number. Presumably the iSerialNumber field shown in the USB
utility is the serial number for the device that Windows will see.

When I used Device Mgmt (safer then using regedit to look at enumeration
data) and the properties of a drive under the Detail tab, I could see
hardware IDs that looked like:

ST3750528AS_____________________________CC44____
(for a Seagate HDD)

WDC_WD10EZEX-00RKKA0____________________80.00A80
(for a Western Digital HDD)

Alas, I do not have another same-vendor and same-model HDD to compare
how their hwids would differ.

Had to go back into the registry to look at the enumeration data.
According to:

https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx

the USB driver assigns a name to the device, like:

VID_xxxx&PID_yyyy

For my crappy digital camera, although not connected but its enum data
remains in the registry, under:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\U SBSTOR\

there was created the enum key named:

Disk&Ven_FUJIFILM&Prod_USB-DRIVEUNIT&Rev_1.00

That's not unique. If I plugged in another camera of same brand model,
it would have the same value. I don't see anything in that enum key for
that device that yet uniquely identifies it.

Not until I wander down through its subkeys do I find a "Hardware ID"
data item that contains what looks like multiple IDs which progress from
specifically identifying the device to more generic IDs.

Alas, I don't have multiples of hardware that are of the same brand and
model to see how their enumeration values would differ. You have a
couple USB flash drives of same brand and model and showed the USB
utility retrieved different serial number for them.

If you look under:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\U SBSTOR\

and find the enum entry for each of those devices while they are plugged
(or after you plug them in and unplug them), do they have the same or
different Hardware ID values? Can you see the serial number in any of
the data items or in the key names for the enum data for those devices?

The reason why I am curious is that I have used the devcon.exe program
(command-line equivalent of Device Management - except devcon.exe is old
and only a 32-bit version exists for x86 architecture, no x64 version
and the IA-64 is for Itanium) to disable and enable devices,
specifically hard disks. The hardware ID is all I've been able to
figure out how to specify which HDD to disable/enable (and, as I recall,
is the only parameter devcon uses to identify the device). So the name
of the ENUM key for the device doesn't look to identify the device but
it's the Hardware ID in that device's enumeration data used to identify
the device. If the serial number is in there somewhere, I'd like to
know where it is.

There is a devcon64. I have a copy. It's just torturous to get it.

http://social.technet.microsoft.com/...evcon-exe.aspx

I haven't tried it, but I'd probably just search the Registry
for the serial number, and see how it's being used. There's
enough stuff stitched together with GUIDs, the association
could be stored practically anywhere.

Paul

OK thanks for the replies. I think I will try having a letter further on
in the alphabet for a while, see if that sticks. I should have made it
clear that I have been using Cobian with a drive plugged in to a USB port
and assigned to G: for quite a few years. When I buy a new drive I use the
same port and make sure it is set to G: of course.
I will also try to remember how to get the Cobian icon to show all the time
in the notification area instead of being hidden (it has a red blob on it
when it fails). If anyone is interested my guess is that it is the laptop
being part of the network and being on when the PC boots.