Whenever I use the command line below
wmic bios get serialnumber
It outputs the BIOS Serial number with my laptop.
However, I've tried that command line to get BIOS serial number with my company's PC, I didn't work a bit.
Here was the output:
C:\Users\companypc>wmic bios get serialnumber
SerialNumber
System Serial Number
So how can I get the BIOS Serial with that problem...
If you have changed a board, and also not all BIOS codes are actually pre-entered. In that case it is necessary to boot into the BIOS of a machine with that issue, and enter it manually (from reading it off of the hardware itself.)
In other words, if the machine is not very old, the response you are getting is the default response when no value is set (null).
This exact question was answered in the Super User forum. See https://superuser.com/a/783271/399852 for the answer by Hennes.
Related
I need you'r help, I searched everywhere but couldn't find anything on the subject.
ACTUAL
A programm check my server version with this command :
[System.Environment]::OSVersion.Version.Major
6
The result is 6, this is perfectly good because it's a 2008R2 server.
EXCPECTED SITUATION
[System.Environment]::OSVersion.Version.Major
10
I need this same command to give a result equivalent to 10.
The objective is to deceive the program to make it believe that the server is a windows server 2016 but it is a windows 2008R2 server.
I don't need to just replace the string or other non persistant solution.
I need to change this value with a powershell script (or other non executable script) before launch the program that checks the OSversion.
The value is stored here, it seems to be directly related to the Common Language Runtime, i think i need to modify
So I think we should be able to modify a value in the CLR, but I don't know how to do it, and even if it is possible.
enter image description here
I was looking for a way to get the contents of the MXCSR register in WinDbg. Looking up the help for the r command I found a lot of options. I thought I had covered all registers with the command
0:000> rM 0xfe7f
However, the MXCSR register was still not included. So I did a full search in WinDbg help, which did not give me any results (sorry for the German screenshot):
So I continued my search in the Internet and finally found
0:000> r mxcsr
mxcsr=00001f80
I am now wondering whether there are other registers that will not be displayed by rM 0xfe7f but are available anyways. I am especially interested in user mode and x86 and AMD64 architecture.
I had a look at dbgeng.dll (version 10.0.20153.1000) and found a few more registers by trying some strings around offset 7DC340. Based on some of that information, I found the MSDN websites x64 registers and x86 registers.
In addition I found
brto, brfrom, exto, exfrom
The registers zmm0 through zmm15 can be used as zmm0h, possibly for the high half.
The registers xmm0/ymm0 through xmm15/ymm15 can be used as ymm0h and ymm0l, likely for the high and low half.
some more which didn't work either because of my CPU model or because I tried it in user mode instead of kernel mode.
I have a MATLAB program that I intend to run on different machines. Is there a way to get, from within MATLAB itself, the following info:
Name of machine
Specs of machine, especially processor and memory configuration
Number of cores deployed for MATLAB
I know the command computer but I require more than what it outputs. I'd like to write all the info above to a text file.
You are looking for the following:
1) To check the type of computer on which MATLAB is executing, use: computer .
2) The following displays information about your Windows:
winqueryreg('HKEY_LOCAL_MACHINE',...
'Software\Microsoft\Windows NT\CurrentVersion','ProductName')
or in general, to get information about the OS, use: feature('GetOS').
3) To check number of processors, use: getenv('NUMBER_OF_PROCESSORS').
4) To check CPU information, use: feature('GetCPU').
5) To get information about cores, use: feature('numCores') .
6) To check memory used by MATLAB, total physical memory and some other information, use: memory.
Note that:
Some of the above are undocumented and taken from Yair Altman's blog.
Finally, to write data in a text file, you can use: fprintf .
My first question on this forum so please forgive any mistakes etc.
I'm writing a PowerShell script that needs to run on both 32 and 64 bit OS's. This in itself is not a problem as I can easily identify the two architectures. The problem arises when I issue a "Get-ItemProperty" command on the registry. With a 32 bit OS I get four lines of unwanted data before the data I actually want, ie PSPath, PAParentPath, PSChildName & PSProvider. The same command issues on a 64 bit OS places those same pieces of data after my data. Having written some PS script to "Select-Object -last 1" to get the bit of data from the end of the last line which works perfectly on 32 bit machines I then found that everything was reversed on 64 bit machines and PS script no longer worked. I've tried using "Select-Object First 1" but this only returns the first part of my data line, if I change the value to 2 then I get everything. So, is there a way of either collecting the whole of the first line or stopping "Get-ItemProperty" from returning all the unwanted lines?
I hope all of that makes sense?
Thanks in advance
MrMackyD
Maybe I'm overlooking something here, but shouldn't
Get-ItemProperty <item> | Select-Object PSPath,PAParentPath,PSChildName,PSProvider
work perfectly fine in both cases?
What is the data you actually want? Can you simply select that directly? For example, (gp Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion).DevicePath reads the DevicePath entry directly, ignoring the PS* properties added by PowerShell.
Your issue is not so much of bitness, but of ignoring the PowerShell-specific properties.
I am having recurring intermittent problems with "losing" my environment variables, most onerously %windir% and %path%. The problem occurs when I have locked the keyboard and log back in. Rebooting the system (cold- and warm-boot) does not reliably bring them back, but eventually multiple iterations of booting has (so far) brought everything back.
If I open a command window and type echo %windir% and echo %path% and find that the variables exist and are properly defined, and if I leave that command window open, I can leave my system running for days without a problem.
I have captured the results of set to list all envars, both when the system is broken, and when it is fixed. The broken list is much shorter (%windir% is not even defined, %path% contains the definition from registry HKCU\Environment, but not from HKLM\SYSTEM\CurrentControlSet\Control\SessionManager\Environment).
I am guessing that the boot-up process is getting sidetracked.
Spent all morning with Geek Squad but they had no concrete suggestions. (They did suggest "taking the computer back to a previous restore point", but I fear that could cause more problems... and they didn't have confidence it would help.)
Do I have any options beyond possibly reinstalling everything?
I did finally find the answer, and although I understand this subject was closed by the commenter, I thought others might want to know. This link explains it pretty well:
https://superuser.com/questions/355594/windows-7s-path-and-environment-variables-are-corrupted
The short version is this: My system PATH exceeded a Windows maximum of 2048 bytes (it was more than 2200 bytes long). When that happens, the boot process fails to instantiate PATH and WINDIR.
The "fix" was to run c:\windows\system32\systempropertiesadvanced.exe from a command prompt (because without WINDIR, you can't open the Control Panel app for environment variables), and manually extract anything from the PATH I thought I could live without, until I whittled the PATH string down to under 2048 bytes.