I am prepairing an Windows form application which will show the Bitness of currently installed office(2016). I have placed a Button(ChkBtn) and a Label(BitnessLbl) in my form, that will help to accomplish my task. The problem is that even though I can find the value of the 'Bitness'('x64' in my case) by searching in the registary, the program fails to locate the specified registary. I have added an image that will further explain my problem. And the code that I am using is as follows
using System;
using System.Windows.Forms;
using Microsoft.Win32;
namespace GetOfficeBitness
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void ChkBtn_Click(object sender, EventArgs e)
{
var arg = @"SOFTWARE\Microsoft\Office\16.0\Outlook";
var key = Registry.LocalMachine.OpenSubKey(arg, false);//OpenSubKey(arg);
/*var p = Registry.LocalMachine.GetSubKeyNames();
var l = Registry.LocalMachine.OpenSubKey(@"SOFTWARE\Microsoft\Office\16.0\Common");
var n = l.GetSubKeyNames();*/
if (key != null)
{
if (key.GetValue("Bitness").ToString() == "x86" || key.GetValue("Bitness").ToString() == "X86")
BitnessLbl.Text = @"32 Bit Office";
//Environment.Exit(1);
}
else
{
//Environment.Exit(0);
BitnessLbl.Text = @"64 Bit Office";
}
}
}
}
Image link goes here:- https://i.sstatic.net/XUcuX.png
As I indicated in a comment, when your code is running as a 32-bit process, you're experiencing the effects of the Registry Redirector.
When it looks like your code is accessing HKEY_LOCAL_MACHINE\Software
, it is in fact accessing HKEY_LOCAL_MACHINE\Software\Wow6432Node
.
To counter the effects, make sure you open your key using an appropriate method/overload that accepts a RegistryView
and request the 64-bit view. E.g. you may need to use OpenBaseKey
rather than using the built-in LocalMachine
property as your starting point.
So, something along the lines of:
var key = RegistryKey.OpenBaseKey(RegistryHive.LocalMachine
,RegistryView.Registry64).OpenSubKey(arg, false);