Как узнать серийный номер жесткого диска, SSD или тома в Windows 10, 8 или 7

Читайте, как определить серийный номер жесткого диска или тома не вставая из стула, с помощью командной строки. Во время покупки или улучшения ПК пользователи задумываются над тем, какие компоненты наиболее важны для них. Исходя из этого выбора на более важные компоненты тратится большая часть бюджета на покупку, а остальные комплектующие подбираются по принципу – чем дешевле, тем лучше. Наиболее значимым компонентом системы является жесткий диск. На нем хранится вся информация вашего компьютера.

Если ваш диск сбоит, или срок его гарантийного использования подходит к концу, возможно необходимо обратиться в сервисный центр для гарантийного ремонта или замены. Как и в случае любой гарантии вам необходимо будет идентифицировать устройство. HDD и SSD диск идентифицируются по серийному номеру, который как правило на печатан на корпусе устройства. Но если вы не хотите разбирать ваш ноутбук или настольный компьютер вы можете получить этот номер с помощью командной строки.

Серийный номер HDD или SSD диска

Чтобы найти серийный номер жесткого диска или серийный номер твердотельного накопителя, введите в командной строке следующую команду:

wmic diskdrive get serialnumber

В результате вы получите список серийных номером дисков, подключенных к системе. Этот номер необходимо предоставить производителю устройства или инженеру сервисного центра для обращения по гарантии. Этот способ работает для внешних жестких дисков, USB флешек и карт памяти.

Серийный номер устройства прошивается в микропрограмму производителем и не подлежит изменению.

Серийный номер тома

Серийный номер тома (логического устройства) отличается от номера устройства и создается во время разбиения диска на разделы. Для получения номера запустите командную строку нажав сочетание клавиш Windows + R, затем введите cmd и нажмите Enter. В командной строке введите:

Вы должны заменить c: буквой диска, на которой хотите найти серийный номер. Помимо серийного номера команда выводит метку диска, если она задана. Для изменения серийного номера раздела можно воспользоваться специальными программами пере разбить диск на разделы.

Автор: Vladimir Mareev, Технический писатель

Владимир Мареев — автор и переводчик технических текстов в компании Hetman Software. Имеет тринадцатилетний опыт в области разработки программного обеспечения для восстановления данных, который помогает ему создавать понятные статьи для блога компании. Спектр публикаций довольно широк и не ограничивается только лишь темой программирования. Статьи включают также разнообразные обзоры новинок рынка компьютерных устройств, популярных операционных систем, руководства по использованию распространенных и специфических программ, примеры решений возникающих системных или аппаратных проблем и многие другие виды публикаций. Подробнее

How to find the disk and volume GUID on Windows 10

Dec 12, 2018
Comment

Disks and volumes on Windows 10 have a unique identifier called a GUID. The GUID for volumes is stored somewhere in the registry but you’d have to go digging around to find it. If you need to find either or both the disk and volume GUID on Windows 10, and you prefer the simplest method possible, you can use the Diskpart utility and a simple PowerShell command.

Disk GUID

Open Command Prompt with admin rights and enter the following. If you need to find the GUID for an external drive, connect it first.

This will run the Diskpart utility. You now need to list all the disks connected to your system with the command below

You will get a list of disks that are connected and each disk will be assigned a number. The number is how you will reference a disk in a command so, if you want to find the GUID for disk 0, you need to select it with the command;

Once the disk has been selected, run this command to find its GUID.

Volume GUID

The easiest way to find the GUID of a volume on your system is to go through PowerShell.

Open PowerShell with admin rights and run the following command. You do not need to modify it in any way. The command will return a list of all volumes and their GUIDs.

Running the commands listed in the above two sections will not result in any sort of data loss. You can run them for your system’s disk while it is still in use. If you’re apprehensive about running commands from Command Prompt or PowerShell, you can always find an app that can read this data from your system.

It’s also important to mention here that volumes are not the same as drives. A drive may have multiple volumes, and Windows 10 doesn’t assign a GUID to drives. It instead assigns them to volumes. If you run the PowerShell command in the volume GUID section of this article, you will see that the results return more than one GUID for the C and D drive. This is because while the disk in question only had two drives, those drives were divided into multiple volumes.

Once you have the GUID for the disk and volumes on your system, use them wherever you need to.

Leave a Reply Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

How to change Hard Disk’s Volume Serial Number (Volume ID)

Last updated on March 3rd, 2016

The Volume Serial Number (also known as VSN) is a unique serial number that is assigned to an optical disk (CD or DVD) or a hard drive after formatting. The Volume Serial Number was added by Microsoft and IBM so that the operating system could recognize if an optical disk or a drive is changed on the system. By that time the only way to determine this, was the volume label (Volume Name) that the user defined to each storage disk. But that way, there was a problem if a user gave the same (Volume) name to two (or more) disks. To bypass this problem, Microsoft and IBM decided to assign a new unique number in hexadecimal form (called ‘Volume Serial Number’ or ‘Volume ID’ or ‘VSN’) when a drive (optical disk or hard drive) was formatted.

In simple words, the Volume Serial Number indicates the exact time of format operation. The VSN is changed anytime you format the disk, so if you re-install Windows and you format the system disk, Windows will ask again for activation.

Taking advantage of VSN, some software vendors use the Volume Serial Number to avoid pirate copying of their products. This means that software from these vendors can not run if the Volume Serial Number is different from the VSN of the product’s original optical disk that was shipped or of the hard drive that the software was first installed. Also this technique was previously used by multiplayer game vendors to ban the gamers that tried to cheat. Nowadays, this method is useless because the game or software vendors now use the hardcoded serial number (HDD Manufacture’s S/N that is embedded into the firmware) to identify (ban) cheaters or they ban the CD key.

In this article you will find detailed instructions on how to change the hard drive’s Volume Serial Number (aka Volume ID or VSN).

How to change HDD Volume Serial Number (VolumeID).

Option 1: Using Sysinternals VolumeID changer.

VolumeID by Mark Russinovich, is another freeware tool that helps you to change the Volume IDs of drives from command line window.

1. Download VolumeID.

2. Extract «volumeid.zip» file contents and move the extracted files («Volumeid.exe» & «Eula.txt«) to the root of C: drive.

3. Open an elevated command prompt. To do that:

In Windows 7, Vista & XP: 1. Go to Start > All Programs. 2. Click to expand Accessories. 2. Right click on Command Prompt and choose “Run as administrator”

In Windows 8

Right-click at the screen’s bottom-left corner and from the pop-up menu, choose “Command Prompt (Admin)”.

4. Let’s say that we want to change the Volume serial number of the system drive C:.

Inside the command prompt window, type the following command to see the current Volume Serial Number of C: drive

4a. The «vol» command should return the Volume Serial Number. In this example the VSN is «94F8-9C08«.

– To change the current VSN –

5. Navigate to the root folder of Disk C: (where «volumeid.exe» is located/saved) and type the following command:

* As : type the drive of the disk (drive or volume) that we want to change the VSN («C:»).

** As xxxx-xxxx : type the new Volume Serial Number (e.g. 74F8-9C08).

In this example I want to change the VSN of disk C: and I have changed only one character (the first) of the old VSN to specify the new one. So the full command should be:

volumeid c: 74F8-9C08

5. When «volumeid» command updates the Volume ID of your drive, close the command prompt window and restart your computer.

Option 2: Using Hard Disk Serial Number Changer.

Update: The download link is not working anymore (removed).

The second free tool you can use to change the Volume Serial Number is called Hard Disk Serial Number Changer. The program can change only the HDD’s Volume Serial Number and not the Hardcoded Serial Number.

1. Download Hard Disk Serial Number Changer.

2. Right-click at HardDiskSerialNumberChanger.exe & select Run as Administrator.

3. Accept the UAC warning message.

4. Choose the disk that you want to change the Serial Number. (e.g. «C:»).

5. Type the new serial number at this form XXXX-XXXX.

6. Press Change.

7. Click Yes and reboot your computer.

How to get hard drive serial number from command line?

From the Windows NT-based (Windows XP and 7 specifically) command prompt, how can I get the serial number of a hard drive as a variable? The one I’m looking at is the serial number of the physical hard disk drive

5 Answers 5

this will get the volume serial number given to it by windows.

wmic diskdrive get serialnumber

this gets the manufacturers serial number of the hard drive.

In the same vein as Moab’s answer, but using PowerShell this time:

This command gets an instance of the Win32_DiskDrive WMI class and outputs the model of each disk drive in the computer and its corresponding serial number from that instance.

This answer assumes PowerShell 3.0 or later. If running an older version, use Get-WmiObject in place of Get-CimInstance .

On Windows 8 and later, you can also use this command:

What you are looking at is NOT the hard drive serial number.

It is called the Volume Serial Number. It is generated at the time of creating and formatting the volume / partition.

You can get it by using a command at command prompt : C:\> vol c: if C: is the drive you want to retrieve the Volume Serial Number for.

All you can do is redirect the output of that command to a file : C:\> vol c: > myvol.txt and it will be stored as a text file in your C:

I am attaching a screenshot with the highlights:

• The file was stored in the root of C:

Find disk volume number windows

This forum is closed. Thank you for your contributions.

Answered by:

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?

Answers

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?

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?

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

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.

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.

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.

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.

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.

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.

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.

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