none
WMI Disk serial number RRS feed

  • Question

  • In Win32_Volume there is the welcome DriveLetter (C:) as well as SerialNumber which is an integer 681259522, for example).

    In Win32_DiskDrive there is also a SerialNumber, but now it is a string. Typically, it has leading hex 20s followed by other characters - here the same drive as above has 202020202020204c34304844595750

    Is there a way to transform one of these Serial Numbers so as to be able in a script to get the DiskDrive information (maker, model, interface ...) for a particular drive letter?

     

    a


    79 years old
    Sunday, January 23, 2011 6:07 PM

Answers

All replies

  • According the documentation on MSDN, Win32_Volume - Serial number is just the serial number of the Volume whereas the Win32_DiskDrive - Serial number is the manufacturer serial number of the disk drive.  So the question is which serial number do you want?

    Win32_Volume - http://msdn.microsoft.com/en-us/library/aa394515(v=vs.85).aspx

    Win32_DiskDrive - http://msdn.microsoft.com/en-us/library/aa394132(v=vs.85).aspx

    • Proposed as answer by Thiyagu14Moderator Monday, January 24, 2011 6:58 AM
    • Marked as answer by IamMred Tuesday, January 25, 2011 4:19 AM
    Monday, January 24, 2011 2:39 AM
    Moderator
  • This doesn't really doesn't address the underlying issue shown in the question:  WMI is returning a corrupt serial number.  Mark is getting the serial number encoded as hexadecimal digit pairs which represent the ASCII characters of the actual serial number.  This does not match the documented behavior.

    This is a long-standing bug in WMI which Microsoft has yet to address, or even explain.  There has never been a clear answer as to the root cause of this bug, only statements that Microsoft won't address it because it ostensibly involves unspecified non-Microsoft software.

    Another symptom is to intermittently get the correct serial number, but with pairs of characters flipped.  You can also get different results based on your UAC settings.

    Friday, September 21, 2012 3:26 PM
  • Hi,

    This isn't the right forum for bug reports, unfortunately; it's a scripting forum. It's highly unlikely anyone from the WMI and/or storage teams will ever see your post. I'm not sure where you would go to post a bug report such as this, but I recommend reading this article first:

    How to Report Bugs Effectively

    Bill

    Friday, September 21, 2012 3:34 PM
    Moderator
  • This doesn't really doesn't address the underlying issue shown in the question:  WMI is returning a corrupt serial number.  Mark is getting the serial number encoded as hexadecimal digit pairs which represent the ASCII characters of the actual serial number.  This does not match the documented behavior.

    This is a long-standing bug in WMI which Microsoft has yet to address, or even explain.  There has never been a clear answer as to the root cause of this bug, only statements that Microsoft won't address it because it ostensibly involves unspecified non-Microsoft software.

    Another symptom is to intermittently get the correct serial number, but with pairs of characters flipped.  You can also get different results based on your UAC settings.

    Not a bug.  It is the way the vendor inserts the serial number into the device.  The serial number has been inserted as a hex string.  Thisis also the way SNMP serial numvers are meant to work.  WMI and CIM make no attempt to convert this data.  That is up to the end user.  YOu must know how the vendor inserts this.

    Yes - with some sensitive items like serial number fields you must run elevatd to see them This a security consideration and not a bug.  It is an intended behavior.

    We are moving now to CIM standards. We should see, if nothing else, better documentation on how these fields are intended to be set up and used.

    Al littel further testing and studying how WMI is deployed and used historically might help you to weed you  way through this.  Note that earlier versions of WMI did not even have a disk serial number.

    The device serial numvbers as Boe has pointed out above ar just vendor strings.  If you don't like the contents then complain to the vendor.  To prove this just view the property in WBEMTEST.  Windows WMI does not ever convert or interpret any values in WMI.

    This si a very commong mistake for may who are not engineers or who have only basic asmin training.  WMI is an engineering tool.  It is designed and specified at an engineering level.  It is similar to SNMP but includes OS and confighuration items not monitored or manged by SNMP. 

    Those that are not trained in these technical tools frequently assume that the behavior that they see is somehow a Windows deficiency when, in most cases, it is intended to be what is seen in use, or, the behavior and usage of item is not understood.

    There is much to criticize in WMI but this is not one of those items.  As I mentioned above, this is being addressed in WMF 3.0 and beyond.  Once the specs ae complete then the vendors will have to comply.  This can take a few years; usually less than two.

    Her eis the Win32_DiskDrive SerialNumber property dicription:  Its source and usage are very clear.  It is a manufacturer supplied string.

    SerialNumber
    Data type: string
    Access type: Read-only

    Number allocated by the manufacturer to identify the physical media.

    Example: WD-WM3493798728

    Windows Server 2003, Windows XP, Windows 2000, and Windows NT 4.0:  This property is not available

    The example is a string but it does not say what the contents of the string are amde of.  Most manufactueres just use the SNMP string here which is always hex encoded for a variety of reasons. althought there is no requirement that they do this.

    I scanned a number of systems and drive Winws 7 and later and found all were hex.


    ¯\_(ツ)_/¯


    • Edited by jrv Friday, September 21, 2012 4:03 PM
    Friday, September 21, 2012 3:55 PM
  • To the moderator:  my apologies, I wasn't attempting to post a bug here [we're already working on that with Microsoft Support].  Like the original poster, I've been looking for work-arounds to these issues.  I get a little frustrated when I see folks ask questions that I would like to see addressed, and then an answer which I feel misses the point of the question gets marked as an answer by a Microsoft employee instead of by the person asking the question.  That just seems like a way to scare people away from the forums.  Sorry that my tone was so harsh.

    jrv,

    Thanks, your reply is actually very helpful.  I think the key part of my post you may have missed was where I mention the intermittent results we see.  Same vendor, same drive, but the serial number comes back in different forms for the same WMI property.  That is what has led us to conclude that WMI isn't merely passing that data back as-is [we would actually prefer that].  We're just not sure if it's attempting to fix the values but after a delay, or if it's switching which driver calls it uses, or if there are just race conditions inherent in the design of the system.

    Do you have any theories that could explain that sort of behavior?  Are you proposing that the "vendor" [not sure if you mean disk manufacturer or motherboard driver vendor] is changing the format on the fly?

    At this point we'd be happy to abandon WMI and go straight to the device drivers [yes, I'm an experienced engineer, and I've studied the CIM, SCSI, etc. standards, and we even design and manufacture our own motherboards here], but now we're in a position that we have to reverse-engineer whatever WMI is doing and try to emulate that for backward-compatibility, but more reliably.

    Friday, September 28, 2012 12:59 AM
  • I am sorry but what you are describing is just no what happens.  99% of vendors store the hex balue of the serial number a s a hex string.

    Show mye the scripthat you say is unreliable.  I suspect it has somthing to do with your script or method of extracting these values.

    Please post the script in question.


    ¯\_(ツ)_/¯

    Friday, September 28, 2012 1:47 AM
  • Since I raised several different issues, let me tackle them one at a time since I think they are distinct [and some might be off-topic for this particular thread].  Also, since this is a Scripting forum, I'll just use PowerShell examples [our shipped code had to embed these queries in an application, so we go straight to the underlying .NET calls there -- not sure if it's against the rules to post C# code here].

    Anyway, for now let's just talk about the prevalence of hexadecimal format, and the predictable [non-intermittent] format changes I've seen.  Here's a simple query run on my Windows 7 system.  The blue window is running as an elevated account, the black window is running as a normal user account.  Note that none of the drive serial numbers are in hexadecimal.  Also note that the query returns the values in different forms [big-endian or little-endian ASCII] depending on which user does the query.  To make things more unpredictable, the third drive's serial number remains the same [it's a CD drive], so we can't make reliable assumptions about how to "fix" the serial numbers.  This particular behavior is all new with Vista; our code had worked as expected on Windows XP.

    In our experience, the hexadecimal form that the original poster mentioned is a rarity.  But most of our drives are Seagate or Western Digital, so maybe those are a rarity in the marketplace.

    So based on your assertion that all of these drives are likely returning their IDs in hexadecimal, doesn't that imply that WMI or something else is doing some additional processing of the values to get the results shown below?  Also, note that Microsoft's official documentation for this property [after the screen shots] show an example that is non-hexadecimal.  So, based on the documentation, I wouldn't criticize the original poster for being surprised at getting a hexadecimal result, since the documentation sets a [possibly inappropriate] expectation that the value returned will match what is printed on the drive's sticker.

    Microsoft WMI Documentation:

    SerialNumber
    Data type: string
    Access type: Read-only

    Manufacturer-allocated number used to identify the physical media.

    Example: WD-WM3493798728



    • Edited by btjwork Friday, September 28, 2012 6:24 PM
    Friday, September 28, 2012 6:22 PM
  • I really fon't want to pursue this any further as it is not a scripting issue.

    The system is woking exactly as it should.  If you switch betwween user sessions and use different environments on a neer server then the string may be read as Unicode.  It is defeined in WMI as a WMI string.  It is NOT defined as hex or as binary.   it is just a string.  The byte order will only cahnge if it is being read from a Unicode session. WIn32 and VBScritp and POwerSHell 2.0 all read strings in ANSI format.  Under 64 bit and if users are configured for MUI support then the string can be misread.  The string is stil stored exactly the same and under all accounts WBEMTEST will show you the same strings.

    What you are seeing is due to local differences in the session used to read WMI.  WMI and the hardware are not changing.

    It is quite easy to get fooled by all of this.  It makes me crazy sometimes becuse I end up thinking similar things but have always found it was not WMI or WIndows.  In most cases it is differences in the sessions that are used to do the testing.

    The strings are being read by the driver API.  WMI calss a DLL that uese the driver API to request the vendor info.

    I suspect a good way to test this is for you to use PowerSHell 3.o and the CIM CMdLets as they have full support for Unicde and double byte environments.  Older programs may behave oddly if the culture is changed or if the environment is switched between 32 and 64 bit.

    I have scanned all over a number of networks and have not been able to detect and instability in serial number reporting.

    Be careful in C#/VB and C++ becuse teh naticve string is Unicde but WMI is ANSI.  Reaidn into a C# string in VS2008 or later will appear to reverse the byte order.  If you sue CreateObject or its Net equivalent instaead of the Management classes you will get even stranger results including numbers that are odd.

    In all cases I am familiar with the Net Management classes have correct support for accessing WMI classes.


    ¯\_(ツ)_/¯

    Friday, September 28, 2012 7:21 PM
  • jrv> I really fon't want to pursue this any further as it is not a scripting issue.

    Fair enough, I do appreciate you taking the time to try and help, I was sincerely hoping one of your suggestions would point out something we had missed over the several years we've been investigating these problems.

    I'll go ahead and post my tests of your theories for posterity.  Since readers of this forum experience WMI via scripting, they might be interested to know that in certain corner cases the many layers involved in implementing the drive-related WMI classes don't always behave as expected/claimed.

    Here's a summary of my actual results of testing your proposals; I'll put the supporting evidence at the end of the post:

      • The string is stil stored exactly the same and under all accounts WBEMTEST will show you the same strings.
        False.  I see the same inconsistency in WBEMTEST.
      • I suspect a good way to test this is for you to use PowerSHell 3.o and the CIM CMdLets as they have full support for Unicde and double byte environments.
        False.  We just tested this on Windows 8 RTM with PowerShell 3.0 CIM Cmdlets, and we see the same inconsistent behavior.
      • Older programs may behave oddly if the culture is changed or if the environment is switched between 32 and 64 bit.
        False (or, at least not the cause of our specific issues).  We get inconsistent results even with the same culture in programs that are set to run as 32-bit only, and also on 32-bit Windows 7.
      • In all cases I am familiar with the Net Management classes have correct support for accessing WMI classes.
        Possibly True.  But since we see the same inconsistent results when using the .NET System.Management classes, that would imply the problem is in one of the layers you assert it can't be in.
      • 99% of vendors store the hex balue of the serial number a s a hex string.
        I only brought it up for the benefit of the original poster.  In my company's case we don't actually care about the form of the string, we just care about getting consistent and reliable results for the same hardware on successive calls.  However, in the dozens of machines we've tested this on both inside and outside our company, getting hexadecimal format from the WMI SerialNumber property has been a rarity.  Obviously, your mileage did vary.
      • The strings are being read by the driver API.  WMI calss a DLL that uese the driver API to request the vendor info
        Agreed; in fact, I suspect the problem originates in the unspecified "glue" DLL(s) that connect WMI to the drivers.  If you or anyone else could state the path to this DLL that would be extremely helpful.  It would also be helpful if somewhere it was described precisely which driver IOCTL is being called for each property.  I strongly suspect that more than one is being called based on an undocumented heuristic, and under certain conditions the heuristic fails which leads to the inconsistent and/or intermittent behavior.
      • I am sorry but what you are describing is just no what happens.
        Well, I suppose we agree since I have reached the same conclusion about what you have described.  :-)  Just because you haven't yet reproduced my scenarios doesn't necessarily mean this isn't happening or that I am just confused.
      • The system is woking exactly as it should.
        That may well be the case.  If so, then for those who are interested in merely getting consistent results for this particular information via scripting in certain scenarios [see the next two paragraphs], that may mean that WMI scripting might not be the best mechanism to use.  I suppose that is the point I want to share with the forum.  Time and again I see "answers" suggesting that WMI is a simple, reliable solution for getting this particular information, but in the particular case of querying the local host's drives I disagree with that recommendation.

    I have scanned all over a number of networks and have not been able to detect and instability in serial number reporting.

    Ah, that probably explains the discrepancy.  All of our queries need to be direct queries of the local machine, not over the network [in some cases the machines aren't even on a network].  Doing the queries over the network would likely avoid the issues we are seeing.  Further, we tend to do our queries shortly after the machine is booted; in those cases we intermittently see a "successful" return from the WMI calls where the property might contain no data, random uninitialized binary data, or data in which the form will temporarily vary.  We already re-try the calls on obviously bad results [since if you keep trying WMI will eventually return good data], but when only the format temporarily changes we don't have a reliable way to detect that a value is "bad" since it is a legal form.

    Hopefully this info will be useful to others in the forum.  For the subset of scripting users who wish to get the drive [not partition or volume] information for the local machine, I would personally recommend avoiding WMI [via scripting or otherwise] for that particular scenario.  Unfortunately, the only alternative appears to be to go directly to the device drivers [which seems to be how most of these discussions conclude], which sadly is not a good option for those without a lot of OS-level programming experience.  The only reason we haven't done that already is that we first need to be confident that we understand the true root cause of these issues so that we can reliably emulate the varied behavior of WMI in these corner cases for backward-compatibility.

    Supporting Evidence

    WBEMTEST results on Windows 7 x64 with UAC turned on for user sessions which differ only in privilege:
    instance of Win32_PhysicalMedia
    {
        SerialNumber = "9VM8PV4Z            ";
        Tag = "\\\\.\\PHYSICALDRIVE0";
    };
    instance of Win32_PhysicalMedia
    {
        SerialNumber = "V98MVPZ4            ";
        Tag = "\\\\.\\PHYSICALDRIVE0";
    };

    PowerShell 3.0 on Windows 8 RTM with UAC turned on for user sessions which differ only in privilege:

    2# Get-CimInstance Win32_PhysicalMedia | Format-Table Tag,SerialNumber -AutoSiz
    Tag                SerialNumber
    ---                ------------
    \\.\PHYSICALDRIVE0             9LS6B7RN
    \\.\CDROM0         1K7MEC3355 2

    16> Get-CimInstance Win32_PhysicalMedia | Format-Table Tag,SerialNumber -AutoSize
    Tag                SerialNumber
    ---                ------------
    \\.\PHYSICALDRIVE0             L96S7BNR
    \\.\CDROM0         1K7MEC3355 2




    Friday, September 28, 2012 11:59 PM
  • That is exactly what you see wwhen the evironments are set differently.  ONe is defaulting to 32 bit and the other to 64 bit.

    Run only the 32 bit environment in both session and it will be the same.

    You must explicitly launch the 32 bit session.

    I haev also tried thsi directly on WS2012 64 bit and I do not see any issue.

    I am not running the MUI version of Windows anywhere.

    The byte order is exactly what we would see dumping ANSI to a Unicode prompt.

    If I really though this was a scripting issue I would build a script that can force the situation with all strins in a file.

    YOu have alreaady proven that the difference is between accounts.  Now figure out why the accounts are different.  It can only be the environment.  Tere is nothingmagic about the way WMI returns a string.  Ther eis a differenc in the way strings are managed in different Unicode environments. We have "bigf indians" and littel indians" and "ANSI non-indians". Lots of ways to mess up.


    ¯\_(ツ)_/¯

    Saturday, September 29, 2012 12:09 AM
  • jrv, I hate to break it to you, but HD serial numbers have never been represented as hex-encoded ASCII strings. It's just the way Windows shows them. Why would they be hex? Take a unit from your shelf or ask someone to hand it over to you and check the S/N imprinted on the label. Is it hex-encoded? I'm sure it's not. And so it is no t flashed as such in device's ROM. Grab a live CD with Linux, if you want, launch it and run `hdparm -I /dev/<your disk> | grep Serial' from terminal. I did that for my SSD. Here's what the result read: OCZ-E84E5605IJTH4698 and here's what Windows gives: 434f2d5a38454534363535304a49485436343839 ...yeah.

    Of course, you might think that Linux processes the original data to provide that clean string. It (almost) does not. Want a proof? Thankfully, unlike with Windows, we can check Linux source code, here is the link to ATA driver core, check it out.

    The only processing that takes place on Linux is swapping every two bytes with each other. This is an important part because it explains why hex-pairs are un-flipped on Windows so please bare with me. Drives send serial number and other information in response to ATAPI command IDENTIFY DEVICE. The response is being sent in 16-bit words. This doesn't make sense today when most drives use serial communication, but it works that way to maintain backwards compatibility with IDE (PATA drives) which were indeed using 16-bit data bus. ATAPI specification enforces the drive to encode all ASCII strings on 2-byte words using big-endian notation, so when you see such chunk of memory on little-endian machine (every Windows is LE, I think) it appears that subsequent pairs of bytes have been flipped.

    Now what Windows does apparently, is to take the memory as it was received from the device and encode it to hex. I don't know the reasoning behind it. This method probably made some sense in the old days and was preserved until today for compatibility reasons. I wouldn't have troubles with it if the results were consistent across all versions of Windows but, clearly, they are not.

    When you run the following command:

    Get-WmiObject Win32_PhysicalMedia | Where {$_.Tag -eq '\\.\PHYSICALDRIVE0'} | Format-Table SerialNumber

    on Windows 7 x64 (winver: 6.1, build 7601) using admin account, the serial number will be hex-encoded and flipped. If you start powershell with elevated permissions, it will be correct (ASCII and not-flipped). Mind you, I'm talking here about the same account that has admin privileges. The only difference is that you start powershell a) normally, b) using "run as administrator". Further more, Model property returned by the query above is empty regardless of what method you use.

    I haven't encountered this problem with Win32_DiskDrive, though. Limited users, admins, elevated or not, it always returns SerialNumber in hex-encoded and flipped form. I guess that's something. But the property isn't available on Windows XP so you have to diverge your script depending on host OS.

    Here's another quirk, BTW. On Windows 7 Win32_DiskDrive.Model property is suffixed with " <interface> device". So if your drive model is "OCZ-AGILITY3" (as returned by ATAPI), the Model property will be "OCZ-AGILITY3 ATA device". Windows XP, however, reports it without extras. Lovely, isn't it?

    So btj-agilent is correct all the way:
    a) Windows returns drive serial number, which is not a real serial number,
    b) the number can differ depending on the OS (which was a topic of a couple of bug reports on Microsoft Connect).
    The flipped S/N are caused by buggy WMI, not encoding problems. (BTW, jrv, how on earth can the difference between ANSI and Unicode encoding be responsible for swapping letters in string? Care to explain?)


    To the OP and anyone who wants to use WMI to get HD properties:
    If you can, avoid WMI when accessing those information. Especially if some vital functionality depends on it. WMI just appears to be broken and you cannot depend on it giving you concise results. Use IOCTLs in an executable tool and wrap it with your script instead. If you have to use PowerShell all the way (for example when you need to run the command remotely on domain nodes) take into account the points above. The subject of WMI returning bad serial numbers for accounts with different access rights was reported to Microsoft in 2010. Apparently it hasn't been fully resolved since.

    Wednesday, October 31, 2012 7:14 PM
  • That seems to be a pretty complete description.

    Regarding swapping: The most likely explanation is incorrect endian-ness in the WMI code that reads the data.

    Bill

    Wednesday, October 31, 2012 7:47 PM
    Moderator
  • You also can try use little program (i had a similar problem with hdd sn) - wmic-hdd-sn-converter on github - for correct convert HEX result.

    Sunday, July 23, 2017 3:34 PM
  • You also can try use little program (i had a similar problem with hdd sn) - wmic-hdd-sn-converter on github - for correct convert HEX result.

    BIOS serial number is not in HEX.  You are referring to device serial numbers which are in binary, not hex.  The HDD serial number is not in binary it is in ascii:

    PS C:\temp> gwmi win32_diskdrive|select serialnumber -first 1

    serialnumber
    ------------
          JA1096DW1MS0PW

    PS C:\temp> WMIC path win32_physicalmedia get serialnumber
    SerialNumber
    JA1096DW1MS0PW

    When getting monitors and other devices you will get the serial numbers in binary.  Some vendors also set the number as text into the description field.

    The original question shows a hex string fro Win32_DiskDrive.  This happens on old systems because the vendors had no spec and just converted the text to a hex string to sore in the disk.  This hasn't been true for drives for more than 10 years except for some very old drives that may still be in use.  I have some SCSI drives that are 20+ years old.


    \_(ツ)_/


    • Edited by jrv Sunday, July 23, 2017 3:51 PM
    Sunday, July 23, 2017 3:47 PM
  • @jrv

    This discussion started in 2011 !!!

    Most likely Win 7 32-bit was the king (I really do not remember)

    And you present results from 2017 from most likely Windows 10 64-bit

    Yes, by now Windows 10 does present correct results from BOTH commands

    wmic diskdrive get serialnumber
    
    and
    
    wmic path win32_physicalmedia get SerialNumber

    But back then Windows 7 32-bit was definitely doing exactly what described (and still does, get yourself a copy of Win7 & check for yourself!)

    Seb


    Thursday, December 21, 2017 9:14 AM