Как узнать серийный номер компьютера на Windows?

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

Узнаем серийный номер компьютера с помощью командной строки

Я работаю на Windows 10, поэтому всё показываю из этой операционной системы. Запустите командную строку, для этого просто нажмите клавиши Win+X и выберите нужный пункт. Либо из любой ОС нажмите клавиши Win+R и введите туда команду cmd.

В открывшемся окне вводим следующую команду:

wmic bios get serialnumber

Нажимаем клавишу «Ввод» и видим результат под строчкой «SerialNumber». Данная команда вытаскивает данные о серийном номере из BIOS.

Если никаких данных нет, значит вина лежит на производителе вашего компьютера. Иногда такое бывает, когда производители забывают сохранить номер в BIOS или UEFI, также они не всегда могут заполнить его правильно, тогда вы увидите цифру 0 или что-то другое.

Проверка серийного номера компьютера в BIOS

Вы также можете посмотреть серийный номер в BIOS. Если вы решили убедиться в правильности приведённых данных в командной строке, то зайдите в BIOS и на вкладке Main или System найдите пункт SerialNumber.

На данном сервисе можно крайне дешево купить подписчиков на свой аккаунт в Инстаграме. Здесь Вам предложат не только выгодные условия приобретения, но также и различный формат подписчиков: от офферов до таргетированной аудитории. Так Вам удастся легко и качественно поднять свою страницу в рейтинге сети.

Найти серийный номер на компьютере с обратной стороны

• Это раздел для ноутбуков. Если вы не смогли определить серийный номер программно, то переверните ноутбук и посмотрите, что написано там. Там вы увидите различную информацию либо на этикетке, либо на самом корпусе. Смотрите внимательнее.

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

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

How to find computer serial number

Author:

Yuval Sinay MVP

COMMUNITY SOLUTIONS CONTENT DISCLAIMER

MICROSOFT CORPORATION AND/OR ITS RESPECTIVE SUPPLIERS MAKE NO REPRESENTATIONS ABOUT THE SUITABILITY, RELIABILITY, OR ACCURACY OF THE INFORMATION AND RELATED GRAPHICS CONTAINED HEREIN. ALL SUCH INFORMATION AND RELATED GRAPHICS ARE PROVIDED «AS IS» WITHOUT WARRANTY OF ANY KIND. MICROSOFT AND/OR ITS RESPECTIVE SUPPLIERS HEREBY DISCLAIM ALL WARRANTIES AND CONDITIONS WITH REGARD TO THIS INFORMATION AND RELATED GRAPHICS, INCLUDING ALL IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, WORKMANLIKE EFFORT, TITLE AND NON-INFRINGEMENT. YOU SPECIFICALLY AGREE THAT IN NO EVENT SHALL MICROSOFT AND/OR ITS SUPPLIERS BE LIABLE FOR ANY DIRECT, INDIRECT, PUNITIVE, INCIDENTAL, SPECIAL, CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF USE, DATA OR PROFITS, ARISING OUT OF OR IN ANY WAY CONNECTED WITH THE USE OF OR INABILITY TO USE THE INFORMATION AND RELATED GRAPHICS CONTAINED HEREIN, WHETHER BASED ON CONTRACT, TORT, NEGLIGENCE, STRICT LIABILITY OR OTHERWISE, EVEN IF MICROSOFT OR ANY OF ITS SUPPLIERS HAS BEEN ADVISED OF THE POSSIBILITY OF DAMAGES.

SUMMARY

The following article will help you to find the computer serial number

Please use one the method bellow to retrieve the computer serial number:

1. Using the buid in » wmic» command:

» wmic bios get serialnumber«

Tip: You can use the command » wmic csproduct get name» to retrieve the local computer model.

Serial number machine 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