Develop Reference

How can I find the Windows product name in Windows 11?

Windows 11, released yesterday, reports itself as Windows 10.0 just about everywhere - RtlGetVersion says 10.0, and if you ask VerifyVersionInfo if you are 11.0 or greater, it says no.
There seems to be no new GUID to shove into app.manifest to say "hey I support Windows 11" like there was for Windows 7, 8, 8.1, and 10.
Currently I rely on HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductName to tell me what the current version of Windows is, but on my machine that I've upgraded, it still says "Windows 10 Enterprise", not "Windows 11 Enterprise".
There appears to only be a single place in the registry that contains the text "Windows 11" and that is the BCD section (boot configuration), which can also be renamed so I don't want to touch that.
So far I have only identified a handful of methods to tell if I am running on Windows 11:
Invoke WMI to query Win32_OperatingSystem and check the Name property, which simply says "Windows 11". This is incomplete (it does not include the SKU such as "Enterprise"), and WMI is relatively slow and slightly brittle, so it's not an acceptable solution for my use-case.
Check the build number to see if it is above 21996 (beta builds) or 22000 (first public release). As above, this won't include the SKU, and would require some manual jiggery-pokery in order to build the full string.
Run sysinfo and parse the output. This is quite slow, and possibly brittle (I haven't checked but the output might be localised into different languages).
winver knows, but it's a GUI application so I can't exactly query it programmatically.
Does anyone have any other ideas on how to get the string "Windows 11 Enterprise" (or "Windows 11 Pro", etc. as the case may be) out of my operating system in a performant and complete manner? Where do WMI, sysinfo, and winver get it from?
I need to do this from a .NET library, but P/Invokes / native function calls are acceptable solutions.

Leaving this here so that I can find it later:
It seems that Windows itself (e.g. winver) gets this information from Windows branding - specifically from the resource table in %WinDir%\Branding\Basebrd\en-US\basebrd.dll.mui.
To access this one could use the private APIs in %WinDir%\System32\winbrand.dll. Specifically, the function BrandingFormatString which accepts a wide string (LPW[C]STR) and returns a wide string.
e.g. BrandingFormatString("%WINDOWS_LONG%") returns "Windows 11 Pro" on my home PC.
I do not know the lifecycle semantics of the resulting string, i.e. if/when/how it should be freed.
The following code serves as a functional proof-of-concept (C# 9.0):
using System;
using System.Runtime.InteropServices;
[DllImport("winbrand.dll", CharSet = CharSet.Unicode)]
[DefaultDllImportSearchPaths(DllImportSearchPath.System32)]
static extern string BrandingFormatString(string format);
Console.WriteLine(BrandingFormatString("Hello World from %WINDOWS_LONG%!"));

tldr - Using the EditionID and the CurrentBuild from the CurrentVersion in the registry seems to be a reliable way to determine Win10 vs Win11 and the "edition" of the software. EditionID is "Professional" on Windows 10 Pro and Windows 11 Pro, and CurrentBuild >= ~22000 tells you if it is 10 or 11.
The collection of registry values in the HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion reveals what feels like a lack of planning on Microsoft's part. There's ReleaseId, which is a number that changed with each Windows 10 release (e.g., 1903, 1909, 2004,...) until its last change for Windows 10 20H2, where it changed to 2009. At the same time, DisplayVersion was added, and was set to 20H2.
Then Windows 10 21H1 released, and ReleaseId inexplicably stayed at 2009.
The fact that both current Windows 10 and Windows 11 releases can have the same DisplayVersion (e.g., 21H2 when Windows 10 21H2 releases soon) and ProductName (e.g., Windows 10 Pro) is really head-scratching. (Thanks #yaakov for catching my mistake saying it was 21H1.)

The following code has been tested on Windows XP, 7, 10, 11. It works on 32 bit and 64 bit operating systems. It works inside 32 bit and 64 bit applications.
The following strings will be generated:
"Microsoft Windows XP, Build 2600, 32 bit"
"Windows 7 Ultimate, Build 7601, 64 bit"
"Windows 10 Enterprise LTSC 2019, Version 1809, Build 17763, 64 bit"
"Windows 10 Pro, Version 1909, Build 18362, 64 bit"
"Windows 11 Professional, Version 21H2, Build 22000, 64 bit"
Put the code into a static constructor so it executes only once and writes the version into a static variable.
static String ms_OperatingSystem;
static Constructor()
{
try
{
String s_KernelPath = Path.Combine(Environment.SystemDirectory,"Kernel32.dll");
FileVersionInfo k_Kernel = FileVersionInfo.GetVersionInfo(s_KernelPath);
// on 32 bit Windows this will read the 32 bit hive instead
using (RegistryKey i_HKLM = RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, RegistryView.Registry64))
{
using (RegistryKey i_RegVer = i_HKLM.OpenSubKey(#"Software\Microsoft\Windows NT\CurrentVersion", false))
{
// Kernel32.dll on Windows 11 has Product Version 10.0.22000.120
if (k_Kernel.ProductMajorPart == 10 && k_Kernel.ProductBuildPart >= 22000)
{
ms_OperatingSystem = "Windows 11";
Object o_Edition = i_RegVer.GetValue("EditionID"); // "Professional"
if (o_Edition is String)
ms_OperatingSystem += " " + o_Edition;
}
else
{
// "Microsoft Windows XP"
// "Windows 7 Ultimate"
// "Windows 10 Pro" (same string on Windows 11. Microsoft SUCKS!)
ms_OperatingSystem = (String)i_RegVer.GetValue("ProductName");
}
// See: https://en.wikipedia.org/wiki/Windows_10_version_history
// Windows 10 older releases --> "2009" (invalid if DisplayVersion exists)
Object o_ReleaseID = i_RegVer.GetValue("ReleaseId");
// Windows 10 latest release --> "21H1"
// Windows 11 first release --> "21H2"
Object o_DispVer = i_RegVer.GetValue("DisplayVersion");
// Use ReleaseID ONLY if DisplayVersion does not exist in registry!
if (o_DispVer is String) ms_OperatingSystem += ", Version " + o_DispVer;
else if (o_ReleaseID is String) ms_OperatingSystem += ", Version " + o_ReleaseID;
ms_OperatingSystem += ", Build " + k_Kernel.ProductBuildPart;
if (Environment.Is64BitOperatingSystem) ms_OperatingSystem += ", 64 bit";
else ms_OperatingSystem += ", 32 bit";
}
}
}
catch (Exception Ex)
{
ms_OperatingSystem = Ex.Message;
}
}

I created a remote support tool for desktop admins (see http://www.appslife-rdt.appspot.com) In VB.Dot.Net i used a call to the WMI space Win32_OperatingSystem and got the "Name" value back. This then needs to be split to get the first object which is what you require. i.e.
Dim query2 As New SelectQuery("SELECT * FROM Win32_OperatingSystem")
Dim searcher2 As New ManagementObjectSearcher(objManagementScope2, query2, QueryOptions)
For Each mo As ManagementObject In searcher2.[Get]()
OSname = mo("Name")
Next
Dim array1 As Array = Nothing
array1 = Split(OSname, "|")
OSname = array1(0).ToString
OSname then gives you the "Windows 11 Pro" or "Windows XP Professional" that you require.
I also get the OSVersion with the latest patch update info from registry as follows if needed...
THIS IS FOR CLIENT VERSIONS 10/11 :-
.SetPropertyValue("sSubKeyName", "SOFTWARE\Microsoft\Windows NT\CurrentVersion\Update\TargetingInfo\Installed\Client.OS.rs2.amd64")
.SetPropertyValue("sValueName", "Version")
THIS IS FOR SERVER VERSIONS 2019 :-
.SetPropertyValue("sSubKeyName", "SOFTWARE\Microsoft\Windows NT\CurrentVersion\Update\TargetingInfo\Installed\Server.OS.amd64")
.SetPropertyValue("sValueName", "Version")
Hope this is of help.

Process.WorkingSet64 returns max value of 4294967295

I'm trying to monitor the memory of another process with C#. However, the maximum memory value that Process.WorkingSet64 or Process.PrivateMemorySize64 will output is 4294967295. I've also have the same problem with Performance Counters.
Here's my code:
using System;
using System.Diagnostics;
namespace perfmon
{
class Program
{
static void Main(string[] args)
{
int pid;
if (int.TryParse(args[0], out pid))
{
var p = Process.GetProcessById(pid);
var ramCounter = new PerformanceCounter("Process", "Working Set", p.ProcessName);
Console.WriteLine($"ProcessName:{p.ProcessName}");
var ram = ramCounter.NextValue();
p.Refresh();
Console.WriteLine("WorkingSet64\tPrivateMemorySize64\tRam PC");
Console.WriteLine($"{p.WorkingSet64}\t{p.PrivateMemorySize64}\t\t{ram}");
}
}
}
}
Running on Windows Server 2012 R2 with .net 4.61.
Output:
C:\XXX\perfmon>perfmon.exe 15800
ProcessName:XXX.Windows.Services
WorkingSet64 PrivateMemorySize64 Ram PC
4294967295 4294967295 4.294967E+09
Powershell output for process:
PS C:\Users\xxx> get-process -id 15800 | select-object -property workingSet64
WorkingSet64
------------
5079859200
Tasklist output for process:
C:\Users\xxx>tasklist /FI "PID eq 15800"
Image Name PID Session Name Session# Mem Usage
========================= ======== ================ =========== ============
XXX.Windows.Services 15800 Services 0 5,031,424 K
As you can see, the C# process stops at 4294967295. However using powershell or tasklist continues to measure memory above 4 GB.
Is this a problem in my code or is this a known issue with memory measurement with C#/.net?

You cannot reliably monitor a 64-bit process from a 32-bit app, numbers are cooked by the Wow64 emulator to prevent them from overflowing UInt32.MaxValue. Just remove the jitter forcing so you can run as a 64-bit process as well.
Project > Properties > Build tab > Platform target = AnyCPU, untick Prefer 32-bit.

I don't see any problem in your code and while I suspected some very improbable weird interaction between the c# 6.0 features and the 32bit vs 64bit properties, the NextValue() method on PerformanceCounter is a float, so no way.
That leads me to believe the problem is not .Net and not the code, but something in your system, like the WMI. Possible related: http://msdn.developer-works.com/article/13358955/Interesting+issue+with+ManagementEventWatcher+monitoring+registry+changes

At runtime how does one determine which mono version is being used?

On a system multiple mono runtime versions may exist.
For example
/usr/bin/mono
/usr/local/bin/mono
When creating a new managed process from a C# application it can be useful to be explicit about which mono version you want to run it with. (The mono in the path may not be the mono being used to run the current process)
Using the Process class to get the current process name returns the assembly that mono is running not mono itself.
What is the best way to determine which mono runtime is currently being used?

On Linux, the process Id and /proc can be used to find the mono executable.
string monopath = String.Format("/proc/{0}/exe", Process.GetCurrentProcess().Id);
monopath will be a symlink to the current executing mono runtime, and can be used to launch a new process:
Process.Start(monopath);

You can use
Type monoRuntimeType;
MethodInfo getDisplayNameMethod;
if ((monoRuntimeType = typeof(object).Assembly.GetType("Mono.Runtime")) != null &&
(getDisplayNameMethod = monoRuntimeType.GetMethod("GetDisplayName",
BindingFlags.NonPublic | BindingFlags.Static | BindingFlags.DeclaredOnly | BindingFlags.ExactBinding, null,
Type.EmptyTypes, null)) != null)
Console.WriteLine("Mono " + (string)getDisplayNameMethod.Invoke(null, null));

Mono on debian error CS0234

I have a debian server and i saved its mac address on a txt file in the /usr folder.
Every time i start the machine the script i'm trying to do should check the current mac address and compare it to the one saved on the txt file. If they don't match than the machine should shutdown.
The code works on Windows , but i have to make it work on debian. So i installed mono (apt-get install mono-complete) ,created the .cs file containing the code and transferred it on debian machine.
When i run the mcs shutdown.cs (shutdown is the name of the file i created) command i get this error :
CS0234: The type or namespace name 'NetworkInformation' does not exist i the namespace 'System.Net'. Are you missing an assembly reference?**
How can this be solved?
using System.Net.NetworkInformation;
static void Main(string[] args)
{
string newmc = Convert.ToString(GetMacAddress()); //current mac address
string mc = File.ReadAllText(#"/usr/mc.txt"); //mac address saved on a txt file previously
if (newmc != mc) //shutdown if the mac addresses dont match
{
System.Diagnostics.Process.Start("shutdown.exe", "-s -t 0");
}
}
static string GetMacAddress()
{
string macAddresses = "";
foreach (NetworkInterface nic in NetworkInterface.GetAllNetworkInterfaces())
{
if (nic.NetworkInterfaceType != NetworkInterfaceType.Ethernet) continue;
if (nic.OperationalStatus == OperationalStatus.Up)
{
macAddresses += nic.GetPhysicalAddress().ToString();
break;
}
}
return macAddresses;
}

System.Net.NetworkInformation.NetworkInterface class is in System.dll according to this: http://msdn.microsoft.com/en-us/library/system.net.networkinformation.networkinterface . Did you try adding a reference to System.dll when compiling? I believe it's the "-r" argument to mcs.
BTW, what version of Mono are you using. Debian is famous for shipping very old versions of Mono in the "stable" flavour. Mono 2.10.x or higher is recommended, nowadays, as stable.

System.Net.NetworkInformation.NetworkInterface was introduced .NET 2.0. You need to target .NET 2.0 profile or newer if you want to use it.
If you are compiling using command line compiler use gmcs or dmcs to compile your project.
If you are using MonoDevelop you need to set in project setting appropriate framework version.

This is how you might do this in Ruby.
begin
theMac = File.read("/usr/path/to/text/file.txt")
rescue Exception => e
puts e.message
puts e.backtrace.inspect
end
response = `ifconfig eth0`
mac = response.match(/HWaddr (.*?):(.*?):(.*?):(.*?):(.*?):(.*?) /)
if theMac == mac[0] then `sudo shutdown -h now`; end
f = File.open("/usr/path/to/text/file.txt", "w")
f.write(mac[0])
f.close()

Get effective executable filename

A .NET application (managed) runs on Windows 7 64 bit. It is actually running on a 64 bit environment.
The application inspect running process (for example, calc.exe) which is located in c:\windows\syswow64\calc.exe.
So, why the function
Process.MainModule.Filename
returns c:\windows\system32\calc.exe? Is it possible to get the effective executable main module location, when is unredirected from SYSWOW64 directory?
What are possible workarounds? The quickest I wrote is the following snippet:
bool iWindows = pFilename.StartsWith(#"c:\windows\", StringComparison.InvariantCultureIgnoreCase);
bool iWindowsSystem32 = pFilename.StartsWith(#"c:\windows\system32\", StringComparison.InvariantCultureIgnoreCase);
if ((iWindows == true) || (iWindowsSystem32 == true)) {
string pActualFileName;
if (iWindowsSystem32 == true)
pActualFileName = pFilename.Replace(#"c:\windows\system32\", #"c:\windows\syswow64\");
else
pActualFileName = pFilename.Replace(#"c:\windows\", #"c:\windows\syswow64\");
Am I missing something?

Try getting the assembly and then getting the assembly location, such as
System.Reflection.Assembly.GetExecutingAssembly().Location

Try to call Wow64DisableWow64FsRedirection before the usage of Process.MainModule.Filename. Verifying that the program are running on 64-bit operation system with IsWow64Process or Environment.Is64BitOperatingSystem (if you use .NET 4.0) before usage of Wow64DisableWow64FsRedirection is recommended.
UPDATED: I am sure that you have a small error in your code or the problem can be on .NET runtines which you have installed. I tested your problem with respect of the following test code
using System;
using System.Diagnostics;
namespace Win64ProcesPath {
class Program {
static void Main (string[] args) {
Process myProcess = new Process ();
try {
myProcess.StartInfo.UseShellExecute = false;
myProcess.StartInfo.FileName = "calc.exe";
myProcess.StartInfo.CreateNoWindow = true;
myProcess.Start ();
System.Threading.Thread.Sleep (1000);
Console.WriteLine ("{0}", myProcess.MainModule.FileName);
Process p = Process.GetProcessById (myProcess.Id);
Console.WriteLine ("{0}", p.MainModule.FileName);
//Process p32 = Process.GetProcessById (8048);
//Console.WriteLine ("{0}", p32.MainModule.FileName);
}
catch (Exception e) {
Console.WriteLine (e.Message);
}
}
}
}
with .NET 4.0 and Visual Studio 2010 installed on Vindows 7 64-bit (x64). On Vindows 7 64-bit there are two version of calc.exe: one 32-bit under C:\Windows\SysWOW64\calc.exe and another 64-bit under C:\Windows\system32\calc.exe. How can easy verify the files has different file size (776,192 and 918.528 bytes). If I compile the program as 64-bit program it starts C:\Windows\system32\calc.exe and Process.GetProcessById(processId).MainModule.FileName shows also correct file name. One can also use Process.GetProcessById() to get correct path of 32-bit version of calc.exe which are started separately (see commented lines). So 64-bit versin of this program has no problem in my envoronment.
If you do have 32-bit application you will be able to access to the full filesystem after the call of Wow64DisableWow64FsRedirection, but you will not be able to access the memory of 64-bit programs and Process.MainModule will throw the excepion System.ComponentModel.Win32Exception with the code NativeErrorCode: 299 and the Message: "A 32 bit processes cannot access modules of a 64 bit process." To be able to get the full filename of 64-bit application you should use API with get you results produced from a 64-bit operation system component (like WMI and so on). But it's already another probelm, because how you wrote your program is 64-bit program.