Since I raised several different issues, let me tackle them one at a time since I think they are distinct. That we have to reverse-engineer whatever WMI is doing and try to emulate that for backward-compatibility, but more reliably.
#HARD DISK SERIAL NUMBER CHANGER GITHUB DRIVER#
We're just not sure if it's attempting to fix the values butĪfter 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.ĭo you have any theories that could explain that sort of behavior? Are you proposing that the "vendor" is changing the format on the fly?Īt this point we'd be happy to abandon WMI and go straight to the device drivers, but now we're in a position That is what has led us to conclude that WMI isn't merely passing that data back as-is. Same vendor, same drive, but the serial number comes back in different forms for the I think the key part of my post you may have missed was where I mention the Thanks, your reply is actually very helpful. 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. Like the original poster, I've been looking for work-arounds to these issues. To the moderator: my apologies, I wasn't attempting to post a bug here. Number allocated by the manufacturer to identify the physical media. SerialNumber Data type: string Access type: Read-only Her eis the Win32_DiskDrive SerialNumber property dicription: Its source and usage are very clear. Once the specs ae complete then the vendors will have to comply.
As I mentioned above, this is being addressed in WMF 3.0 and beyond. There is much to criticize in WMI but this is not one of those items.
#HARD DISK SERIAL NUMBER CHANGER GITHUB WINDOWS#
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. It is similar to SNMP but includes OS and confighuration It is designed and specified at an engineering level. This si a very commong mistake for may who are not engineers or who have only basic asmin training. Windows WMI does not ever convert or interpret To prove this just view the property in WBEMTEST. If you don't like the contents then complain to the vendor. The device serial numvbers as Boe has pointed out above ar just vendor strings. Note that earlier versions of WMI did not even have a disk serial number. We should see, if nothing else, better documentation on how these fields are intended to be set up and used.Īl littel further testing and studying how WMI is deployed and used historically might help you to weed you way through 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. YOu must know how the vendor inserts this. Thisis also the way SNMP serial numvers are meant to work. The serial number has been inserted as a hex string. It is the way the vendor inserts the serial number into the device. You can also get different results based on your UAC settings.
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Īnother symptom is to intermittently get the correct serial number, but with pairs of characters flipped. This is a long-standing bug in WMI which Microsoft has yet to address, or even explain. This does not match the documented behavior. Mark is getting the serial number encoded as hexadecimal digit pairs which represent theĪSCII characters of the actual serial number. This doesn't really doesn't address the underlying issue shown in the question: WMI is returning aĬorrupt serial number.
0 kommentar(er)
