Win32_PhysicalMedia returns incorrect serial number on Vista or higher when run as standard user by Keith Hill MVP

Thank you for your bug submission. The issue you reported appears to be on a released Windows Product. If this issue is severe, causing critical business situations or blocking your product development or deployment, please go to http://support.microsoft.com or call 1-800-MICROSOFT for assistance. For Microsoft premier customers, please contact your administrator, your Technical Account Manager, or your Microsoft premier account representative.
Other Support links - http://support.microsoft.com/ph/14019#tab13

It appears that it's consistently wrong for x86 as well.

Here's my complete test results:

XP Admin
========

Win32_PhysicalMedia = VNVD04G4C08E1G
Win32_DiskDrive = Error, valid for >= Vista

XP Non-Admin
============

Win32_PhysicalMedia = Nothing
Win32_DiskDrive = Error, valid for >= Vista

Windows 7 x86 Ultimate Standard User
=========================

Win32_PhysicalMedia = 2020202020204e56445634303447304345384731
Win32_DiskDrive = 2020202020204e56445634303447304345384731

Windows 7 x86 Ultimate Run as Admin
=========================

Win32_PhysicalMedia = VNVD04G4C08E1G
Win32_DiskDrive = 2020202020204e56445634303447304345384731

I just remembered that in the Forums on the "social.msdn.microsoft.com" site, the post "http://social.msdn.microsoft.com/Forums/en/netfxbcl/thread/8523d7b9-0dc8-4d87-be69-a482aec9ee5e" dated 14 Oct 2009 reported a similar bug. One Moderator suggested using the "Win32_DiskDrive" class.

Guess what! On Win7 Ultimate 64 Bit (x64) using the code reported in my previous post, I get the "Reversed" string for the serial number whether the code is running Elevated or Standard. What a great solution (excuse the irony), at least you get a consistent serial number but its wrong.

Consider taking an inventory of PC's. You want to record serial numbers and then check with a disk manufacturer's web site which hard disks have warranty and which don't. So you decide to use WMI. If this is scripted and you run the script when the PC starts up, its likely that this will run with standard/normal privilege. If you use "Win32_PhysicalMedia" you get a hex string. None of your disks have warranty. If you use "Win32_DiskDrive" you get back what looks like a real serial number and you find which of your disks have warranty.

Now suppose that a particular PC has a hard disk with a serial number "ABCD". Using "Win32_DiskDrive" will give you a serial number of "BADC". The real disk with this serial number has warranty, but "ABCD" doesn't. So, you are looking at the warranty for the the disk of a totally different PC, probably owned by someone else (assuming its not sitting on a shelf somewhere).

So how much time and effort (i.e. cost to a company) will this take to sort out? How many companies have inventories riddled with this bad data?

Following JimBob99's comment I decided to look at several PC's and post the results (apologies if the layout goes awry). PC, CPU, OS and Hard Disk are self-explanatory. Elevated means that the program (which uses compiled code to make the WMI call) was run "As Administrator". Standard means that the program was run "As Invoker" which is what the program Manifest asks for. Although logged on as an Administrator, "As Invoker" will run the program with standard/normal (non elevated) credentials and give standard/normal privilege.

PC / CPU / OS / Hard Disk / Elevated / Standard

Acer / Intel T4300 64 Bit/ Win 7 Home Premium 64 Bit/ Western Digital / OK / Reversed
Fujitsu / Intel Core i3-330M 64 Bit / Win 7 Ultimate 64 Bit / Fujitsu / OK / Reversed
HP / Intel E5500 64 Bit / Win 7 Professional 32 Bit / Hitachi + Seagate / OK / Reversed
Toshiba / Intel T5500 64 Bit / Vista Business SP1 32 Bit / Fujitsu / OK / Raw
Toshiba / Intel T5500 64 Bit / Vista Business SP2 32 Bit / Fujitsu / OK / Raw

The "OK" is the serial number you would expect from CreateFile after byte reversal and conversion from Hex.
The "Reversed" is what looks like a valid serial number but with pairs of characters reversed (the original posting).
The "Raw" is just a hex string.

The two "Toshiba" entries are for a "mothballed" PC which had SP1 on it, which I then updated to SP2. So as of 18 Jan 2011 this PC still gives "Raw" data when a WMI query for "Win32_PhysicalMedia" is perfomed from the "root\cimv2" namespace. According to "Windows Update", there are no other updates I can currently install on this PC, so the problem remains.

As to the data provided above, the problem is persistent across different PC's with different CPU's and Hard Disk drives (as you might expect). The only consistencies appear to be with the OS.

From JimBob99's comment, if you run Win 7 Ultimate the x86 version will give you a "Raw" Hex string, whereas my Win 7 Ultimate 64 Bit (x64) gives the reversed characters. However, the Win 7 Professional 32 Bit (x86) above gives "Reversed" not "Raw". The code making the WMI call is only running as a Win32 32 Bit process and in this case there is no 32/64 process boundary to get in the way and cause more confusion.

I guess one other dimension to this problem is to look at whether there is a difference between managed and unmanaged code to account for the "Raw" and "Reversed" results, but I'm not volunteering for that.

To add to the confusion, Windows 7 Ultimate x86, run as standard user, does not return "normal" characters, as DrGMC said for x64.

It returns a Hex string, reversed byte order.

Mods, I'd originally thought this problem was just referring to Vista and, as such, I created a new submission for Windows 7 here: https://connect.microsoft.com/VisualStudio/feedback/details/635920/win32-physicalmedia-returns-incorrect-serial-number-in-windows-7-when-run-as-standard-user.

It looks like my submission is a duplicate.

This bug has been present since Vista. Whether it is present on all variants of the OS I cannot tell, but on Vista Business using WMI and Win32_PhysicalMedia results in the correct SerialNumber when code is run elevated. For code which runs as a normal user a raw data string is returned as Hex characters. The workaround I use is to check for only Hex characters (and an even number of them) and then convert to ASCII and reverse character pairs. This method has been noted elsewhere on the web.

Unfortuately, in Windows 7 the situation is even worse. In the case of Windows 7 Ultimate (x64), both elevated and non-elevated code return "normal" characters BUT in the non-elevated case the character pairs are still the wrong way around, so you cannot use the "kludge" given above.

The only thing to do in this case is to fall back on old methods (not recommended) using CreateFile and see which call (SMART, SCSI ...) succeeds. Again this method is documented on the web.

I thought that the point of using WMI was to have a standard and consistent way of getting information. I can accept that some data is absent if you run code with the wrong privilege, but inaccurate information determined by privilege and the specific OS is just plain crazy.

Thanks for your feedback.
We are routing this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.

Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)