I just tested booting the computer up with the HDD in the USB dock, and I got the same result. Technically, the SerialNumber field wasn't blank, but was all zero's instead of the actual serial number, which is probably just the same difference. It's seeming like it may be more work than it's worth to do this as a part of the script (assuming it's even possible), so I will likely just continue scanning the SN barcode into the script. It's an extra step, but only takes a couple seconds. Thanks everyone for the input.

I am adding this as an answer because it can save lot of time while debugging scenarios like System.NullReferenceException in WMI. Windows+R (run command); Type wbemtest. And connect to the machine for which you want to fetch information. Fire the query for Win32_DiskDrive and check the output.

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 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. 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. 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. 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. Free Online Video Cutter Splitter here. 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-WM. 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. 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. Simple Minds Sparkle In The Rain Rarest. Example: WD-WM.

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. 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. 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.