locked
Disk <n> has the same disk identifiers as one or more disks connected to the system. RRS feed

  • Question

  • On Windows 10 Enterprise, I recently connected 5 identical LaCie USB 3.0 8Tb disks, formatted them with ReFS & encrypted them with Bitlocker. They function without problems.

    Then, after an unexpected restart moved me to look at the event log (which turned out to be Windows Update related), I noticed warnings logged:

    ---
    Log Name:      System
    Source:        Disk
    Event ID:      158
    [snip]
    Description:
    Disk 3 has the same disk identifiers as one or more disks connected to the system. Go to Microsoft's support website (http://support.microsoft.com) and search for KB2983588 to resolve the issue.
    ---

    (repeated for disks 4, 5 & 6). Which means the first disk doesn't generate this error, but all 4 other disks connected after it generate this event ID. I assumed the manufacturer (LaCie) clones their drives as it comes formatted and has some utility and a manual on it.

    The KB mentioned in the event is completely useless as it pertains to Windows Server, and there are not multiple paths to the disks.

    An extended Google search yields many other people that encountered this issue over the years, but no solutions. As others found as well, when I check the unique IDs of the disks with diskpart, like so:

    DISKPART> list disk

      Disk ###  Status         Size     Free     Dyn  Gpt
      --------  -------------  -------  -------  ---  ---
      Disk 0    Online          953 GB      0 B        *
      Disk 1    Online          931 GB      0 B        *
      Disk 2    Online         7452 GB      0 B        *
      Disk 3    Online         7452 GB      0 B        *
      Disk 4    Online         7452 GB      0 B        *
      Disk 5    Online         7452 GB      0 B        *
      Disk 6    Online         7452 GB      0 B        *

    DISKPART> sel disk 2
    Disk 2 is now the selected disk.
    DISKPART> uniqueid disk
    Disk ID: {747E4712-BCFB-428A-88AF-D8E1B9149FFB}
    DISKPART> sel disk 3
    Disk 3 is now the selected disk.
    DISKPART> uniqueid disk
    Disk ID: {F2F217F6-31AA-497A-9E59-027619AA8448}
    DISKPART> sel disk 4
    Disk 4 is now the selected disk.
    DISKPART> uniqueid disk
    Disk ID: {E98D6D5A-1023-4980-AF09-7650CDDE6DC8}
    DISKPART> sel disk 5
    Disk 5 is now the selected disk.
    DISKPART> uniqueid disk
    Disk ID: {94BFE1D0-9AE1-4EBC-9A76-0E1D184C2A1A}
    DISKPART> sel disk 6
    Disk 6 is now the selected disk.
    DISKPART> uniqueid disk
    Disk ID: {19464FC6-C3D9-4767-B0D5-F782DA3CBBE4}

    The GUIDs of the disks are clearly different. I figured maybe windows uses a temporary GUID to make things work, but if I connect the disks individually the disk GUIDs don't change. To make sure, I changed all the disk GUIDs with new randomly generated GUIDs (using uniqueid disk ID=[GUID] in diskpart), this didn't change anything.

    The volume serial numbers are different as well:

    C:\Windows\system32>fsutil fsinfo volumeinfo f:
    [snip]
    Volume Serial Number : 0x74862e30
    [snip]

    C:\Windows\system32>fsutil fsinfo volumeinfo g:
    [snip]
    Volume Serial Number : 0xbee4ad67

    (other 3 are different as well). So clearly there must be some *other* ID that is the same for these 5 disks. Eventually I found this Powershell command:

    "Get-PhysicalDisk | select-object *"

    Which outputs a lot of properties of all physical disks. Including an "UniqueId" property for each disk (apparently *different* than the disk GUID, which is a part of the "ObjectId" property). Selecting only some of the properties yields:

    ---
    PS C:\Windows\system32> Get-PhysicalDisk | select-object FriendlyName,UniqueIdFormat,SerialNumber,UniqueId

    FriendlyName                  UniqueIdFormat SerialNumber    UniqueId
    ------------                  -------------- ------------    --------
    LaCie P9233                   FCPH Name      88RE23LN0000    5000000000000001
    LaCie P9233                   FCPH Name      Q59F23LN0000    5000000000000001
    LaCie P9233                   FCPH Name      TY9F23LN0000    5000000000000001
    LaCie P9233                   FCPH Name      CBRE23LN0000    5000000000000001
    LaCie P9233                   FCPH Name      KS9F23LN0000    5000000000000001
    Samsung SSD 860 PRO 1TB       FCPH Name      S42NNF0KA04120L 500253E8409050B9
    Samsung SSD 860 EVO mSATA 1TB FCPH Name      S41PNB0K505237J 500253E8403E43FB
    ---

    And there it is! The "UniqueId" fields are clearly the same and *not* unique... When digging around a bit, it seems this property is "Read-Only", per:
    https://docs.microsoft.com/en-us/previous-versions/windows/desktop/stormgmt/msft-physicaldisk
    and
    https://docs.microsoft.com/en-us/previous-versions/windows/desktop/stormgmt/msft-storageobject

    (Strangely enough information on this is only found in "previous versions" documentation).

    Obviously it's not very smart to use two diffent kinds of Unique Id's for the same disk. So what is this UniqueId exactly and can it be changed? Or is this something LaCie screwed up and baked the same "unique" ID in the hard/firmware?

    That it originates from hard/firmware seems to be indicated by the fact that when I search for "LaCie 5000000000000001" I find some French forum post that includes the output of smartctl on linux of a LaCie drive with "Logical Unit id: 0x5000000000000001". See: https://forum.ubuntu-fr.org/viewtopic.php?id=2008790

    Also I found a WD drive with the same "Unique" ID: https://gist.github.com/progre/1b3d7aa5eb0dba5a29f2dfe43be4c4ff

    Are these drive makers assuming nobody will use more than one of their drives? Or is this a default that can be changed somewhere? Please advise, thanks!
    Sunday, April 14, 2019 4:36 PM

All replies

  • Hi,

    Would you please share us the screenshot of Disk Management?

    Also we can refer to the link below to see if any help:

    Fixing Disk Signature Collisions

    https://blogs.technet.microsoft.com/markrussinovich/2011/11/06/fixing-disk-signature-collisions/

    Best Regards,


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, April 15, 2019 7:15 AM
  • The link you provided concerns MBR disk signatures, but I have done the equivalent for GPT partitions (change the GUID for each disk, even though they were already different).

    It's definitely not this UniqueId/GUID that is the cause, but a different one (a hardware ID that can be found running "Get-PhysicalDisk | select-object FriendlyName,UniqueIdFormat,SerialNumber,UniqueId" in Powershell as I detailed in my original post).

    Seeing this link: https://social.technet.microsoft.com/Forums/windowsserver/en-US/578a4c17-ed61-4d1a-837b-bdde46f2e7fe/storage-spaces-ui-missing-disks-when-a-controller-reports-the-same-uniqueid-for-all-attached-disks?forum=winserver8gen

    It seems that it may be a driver or controller issue in some cases. In my case it's USB 3.0 disks, and the driver used is from Microsoft. Probably LaCie hard-coded "5000000000000001" in their drive or controller firmware, assuming it's not important. At least currently it assures that no more than one of those drives can be used with Windows Storage Spaces at a time (see link above).

    I have sent LaCie a link to this post, who knows, they might even fix it. I don't have high hopes though. 

    Here's someone else that has the same issue (different GPT GUIDs, but still a conflicting UniqueId): https://forums.whirlpool.net.au/archive/2769597

    And the requested screenshot of Disk Management: 



    • Edited by raphidae Monday, April 15, 2019 11:01 AM
    Monday, April 15, 2019 10:11 AM
  • Description:
    Disk 3 has the same disk identifiers as one or more disks connected to the system. 

    Eventually I found this Powershell command:
    "Get-PhysicalDisk | select-object *"
    Which outputs a lot of properties of all physical disks. Including an "UniqueId" property for each disk 
    ---
    PS C:\Windows\system32> Get-PhysicalDisk | select-object FriendlyName,UniqueIdFormat,SerialNumber,UniqueId

    FriendlyName                  UniqueIdFormat SerialNumber    UniqueId
    ------------                  -------------- ------------    --------
    LaCie P9233                   FCPH Name      88RE23LN0000    5000000000000001
    LaCie P9233                   FCPH Name      Q59F23LN0000    5000000000000001
    LaCie P9233                   FCPH Name      TY9F23LN0000    5000000000000001
    LaCie P9233                   FCPH Name      CBRE23LN0000    5000000000000001
    LaCie P9233                   FCPH Name      KS9F23LN0000    5000000000000001
    Samsung SSD 860 PRO 1TB       FCPH Name      S42NNF0KA04120L 500253E8409050B9
    Samsung SSD 860 EVO mSATA 1TB FCPH Name      S41PNB0K505237J 500253E8403E43FB
    ---

    And there it is! The "UniqueId" fields are clearly the same and *not* unique... 

    I'd like to confirm the issue described above.  I experienced the same issue with two external (USB) hard disk drive enclosures which I use with different hard disks. The disk enclosures are from different manufacturers, but both use an USB-SATA controller from ASMedia. The UniqueId of the two disks is (according to Windows) identical, and so I get a warning, too:

    FriendlyName              UniqueIdFormat  SerialNumber    UniqueId
    ------------              --------------  ------------    --------
    ST950042 0AS              FCPH Name       B1A000000002    5000000000000001
    ASMT 2115                 FCPH Name       8B0987654321    5000000000000001

    If I place one of the hard disks in another disk enclosure with a chipset from a different manufacturer everything is fine. So it's obvious that this 'error' message has nothing to do with the format of the hard disks drives, but is a result of using the same chipset on USB. 

    Edit: I get the same error message now when I use a SD card reader (from Kingston) with two slots (one for normal SD Cards, one for Micro SD Cards). Again, Windows reports identical UniqueIDs - and even if I use only ONE SD Card and let the other slot empty. As a workaround I deactivated the Micro SD Card slot as I don't need it normally. 

    Therefore this is a bug of Windows 10 and not an issue of hard disks (or SD Cards) or an issue of using special enclosures resp. chipsets. 


    • Edited by Thorsten Albrecht Tuesday, April 14, 2020 12:59 PM Added SD Card reader issue
    Wednesday, February 5, 2020 4:05 PM
  • I've had this same issue on my Windows 10 Pro desktop.  It has four external drives attached and your research helped me find the source of the elusive warning that has been shifting between disks.

    In my case, the external drives are Seagate Backup Plus drives.  Here are details from my device.


    FriendlyName UniqueIdFormat SerialNumber UniqueId
    ------------ -------------- ------------ --------
    Fantom External HDD Vendor Specific 7A2081303102 {152d7081-875a-e4e8-77bd-fa411d5a548b}
    Seagate Backup+ Desk FCPH Name NA7HF01Y 5000000000000001
    WDC WD10EZEX-75M2NA0 FCPH Name WD-WCC3F4KNAXJV 50014EE2615D9BDF
    HGST HTS 721010A9E630 Vendor Id RANDOM__EBBBA021D50A HGST HTS721010A9E630 RANDOM__93D26710B8880000
    Seagate Backup+ Desk FCPH Name NA5KGWAT 5000000000000001

    This thread was started over a year ago.  I believe @raphidae is correct in his surmise that it is related to Microsoft Windows software.  Usually, this warning swaps between the two Seagate Backup+ drives.  This morning, it cycled to the Fantom HDD which has no apparent duplication.  All these drives are using the Microsoft driver.

    Do we think Microsoft will ever address the issue?


    • Edited by Marj Wyatt Monday, February 17, 2020 5:51 PM
    Monday, February 17, 2020 5:47 PM
  • FWIW here is my list, same ID as yours.   I only checked my event log by chance as I had an application stored on one of those drives prompt me for a firewall rule out of nowhere.   I checked the rule and the path to the disk was not S:\path\to\exe as one would expect.   It was instead E:6\path\to\exe which ive never seen before.   I proceeded to make the path "proper" and upon next startup, it prompted me for the rule again and added the wonky path.  So begun my digging for a fix, as id really like to be able to discern the paths to my firewall rules, nevermind any other conflict or fallout this might present elsewhere.


    FriendlyName           UniqueIdFormat   SerialNumber         UniqueId
    ------------           --------------   ------------         --------
    ST10000DM0004-2GR11L   FCPH Name        ZJV67SC5             5000C500C3A5C395
    NVMe Samsung SSD 970   SCSI Name String 0025_3851_9150_1307. EUI.713509151382500
    JMicron Generic        FCPH Name        0123456789ABCDEF     3001234567891234
    Seagate Backup+ Hub BK FCPH Name        NA9QYE2X             5000000000000001
    Seagate Backup+ Hub BK FCPH Name        NA9QYDZF             5000000000000001
    Seagate Backup+ Hub BK FCPH Name        NA9QYE4D             5000000000000001
    Seagate Backup+ Hub BK FCPH Name        NA9QYDV2             5000000000000001
    ST10000DM0004-2GR11L   FCPH Name        ZJV6BMYE             5000C500C4937382
    ST10000DM0004-2GR11L   FCPH Name        ZJV66YYQ             5000C500C388E8A3
    ST10000DM0004-2GR11L   FCPH Name        ZJV6985J             5000C500C41EC6E9
    Seagate Backup+ Hub BK FCPH Name        NA9QYERJ             5000000000000001
    ST10000DM0004-2GR11L   FCPH Name        ZJV6BPNX             5000C500C4938960
    ST10000DM0004-2GR11L   FCPH Name        ZJV6B47M             5000C500C4931475


    Monday, April 6, 2020 9:38 PM
  • Fixing Disk Signature Collisions

    https://blogs.technet.microsoft.com/markrussinovich/2011/11/06/fixing-disk-signature-collisions/

    This link does not fix the problem as it has something to do with disk drives using the same (USB) chipset. Please have a look to my detailed problem description below.

    This issue should be escalated to the developers as they seem not aware of this problem. 

    Tuesday, April 14, 2020 1:03 PM
  • Fixing Disk Signature Collisions

    https://blogs.technet.microsoft.com/markrussinovich/2011/11/06/fixing-disk-signature-collisions/

    This link does not fix the problem as it has something to do with disk drives using the same (USB) chipset. Please have a look to my detailed problem description below.

    This issue should be escalated to the developers as they seem not aware of this problem. 

    Well I did pass it along to seagate just now, no telling if it will get into the right hands - much less if anything will be done about it.

    I'd certainly urge everyone else to do the same.  Like most things, the more the merrier!
    Monday, April 20, 2020 4:30 PM
  • This is an issue for Microsoft, not for Seagate or any other manufacturer.

    BTW The issue does not exist in Windows 7.

    Monday, April 20, 2020 5:23 PM
  • This is an issue for Microsoft, not for Seagate or any other manufacturer.

    BTW The issue does not exist in Windows 7.

    Pretty much exactly what the seagate engineer said. 

    "The issue seems to be related to BOT vs UAS. On new machines with UAS you get the same Unique ID, it appears to be handled by UPnP. There doesn't appear to be anything we can do about it. It appears to have something to do with the UAS driver as this does not happen when the same drives are connected via BOT. We would like to advise reaching out to Microsoft as well because this appears to be how the host bus handles Bulk Only Transport (BOT) and USB Attached SCSI (UAS) in Windows. The issue is not seen when connected to a host via BOT and is only seen when connected via UAS. So it appears to be dependent on the hosts bus and some underlying logic of the bus in Windows. It is something that Seagate cannot control"

    Wednesday, May 6, 2020 2:54 PM