Develop Reference

C# Winform Registry set and get functions appear to work, but don't actually change the registry

I'm trying to use this registry hack I found online:
;Disables F1 key - Help and Support - in Windows 10
;Ramesh Srinivasan, Winhelponline.com
[HKEY_CURRENT_USER\SOFTWARE\Classes\Typelib\{8cec5860-07a1-11d9-b15e-000d56bfe6ee}\1.0\0\win32]
#=""
[HKEY_CURRENT_USER\SOFTWARE\Classes\Typelib\{8cec5860-07a1-11d9-b15e-000d56bfe6ee}\1.0\0\win64]
#=""
When I run it as a .reg command via Windows Explorer and watch the registry with regedit, it works as intended. Removing it is another registry file that simply removes the \0 subkey (and win32 and 64 with it). I'm trying to emulate this function with C# in a Winform using .net CORE:
private void CheckF1()
{
// Registry data from ;Ramesh Srinivasan, Winhelponline.com
RegistryKey F1key = Registry.CurrentUser.OpenSubKey(#"SOFTWARE\Classes\TypeLib\{8cec5860-07a1-11d9-b15e-000d56bfe6ee}\1.0\0");
// EGADS! It's active!
if (F1key == null)
{
fckF1RestoreBtn.Enabled = false;
fckF1KillBtn.Enabled = true;
fckF1Status.Text = "That creepy bugger is waiting and watching.";
}
else
{
fckF1RestoreBtn.Enabled = true;
fckF1KillBtn.Enabled = false;
fckF1Status.Text = "The F1-Help function had been put in it's place.";
}
}
private void fckF1KillBtn_Click(object sender, EventArgs e)
{
Registry.CurrentUser.CreateSubKey(#"SOFTWARE\Classes\Typelib\{8cec5860-07a1-11d9-b15e-000d56bfe6ee}\1.0\0\win32");
Registry.CurrentUser.CreateSubKey(#"SOFTWARE\Classes\Typelib\{8cec5860-07a1-11d9-b15e-000d56bfe6ee}\1.0\0\win64");
CheckF1();
}
private void fckF1RestoreBtn_Click(object sender, EventArgs e)
{
Registry.CurrentUser.DeleteSubKeyTree(#"SOFTWARE\Classes\Typelib\{8cec5860-07a1-11d9-b15e-000d56bfe6ee}\1.0\0");
CheckF1();
}
Weirdly the code "sees" a setting and responds like it should. Even to the point that whichever toggle position it was in on close it remembers when I load the file again. It's almost like it's playing along to screw with me. Regardless, when I watch the registry, none of my code has any actual effect though by all appearances it seems to work otherwise (it doesn't actually of course because the registry change isn't happening).
NOTE: I have already updated my manifest file for the project to include elevated permissions:
<requestedExecutionLevel level="highestAvailable" uiAccess="false" />
Here's the breakpoint on the test statement to see if the subkeys are there that shows they are:
Meanwhile the registry location for the exact path shown in the debug doesn't have the 1.0\0 path at all:
I don't know how the code is reading phantom values. Someone closed my previous question pointing to another answer that didn't have any effect (Registry key deleted but still getting value from registry c#):
"Prefer 32 bit" was never checked for my project in the first place
Modifying my code as recommended had no effect
var key = RegistryKey.OpenBaseKey(RegistryHive.CurrentUser, RegistryView.Registry64)
.OpenSubKey(#"SOFTWARE\WOW6432Node\Classes\TypeLib\{8cec5860-07a1-11d9-b15e-000d56bfe6ee}\1.0\0");
Adding "Wow64Node" to the path makes no difference in execution.
EXPECTED BEHAVIOR
Checking to see if the HKEY_CURRENT_USER\SOFTWARE\Classes\Typelib{8cec5860-07a1-11d9-b15e-000d56bfe6ee}\1.0\0 path is present should return null if the \0 path is not present
Adding and removing the subkeys should show in the registry

So apparently HKEY_CURRENT_USERS is an alias. When the above code runs, it updates in HKEY_USERS under the specific logged in user. There's a question that talks about this behavior here: write registry to hkey_current_user instead of hkey_users
That said, the code appears to work, it's just that the registry doesn't update HKCU like when you run .reg commands. To verify it was working, I'd run the toggle that kills the keys then click them in Regedit and it would say they didn't exist. When I toggled back, I could click on them. So basically, it works (not sure if it required the "using" blocks as others suggested, but I see no reason to take them out).
Now my problem is that it points to the admin user and NOT the regular user because I'm running it and regedit as admin. It took forever to determine this based on running regedit as user in one case and admin in another. Bottom line, this won't work and I'll probably end up running .reg files in the command line instead.

C# webBrowser script error

I keep getting a script error when trying to load the page using webBrowser.Navigate("https://home.nest.com/"). It will pull up fine from my normal internet browser but not in my program.
Can anyone point me in the right direction?

as this link answer:
you must only add this line:
webBrowser.ScriptErrorsSuppressed = true;

The script errors happen all of the time in the integrated Internet Explorer WebBrowser control even when it's using version 11. Modern websites rely heavily on massive Javascript files and dynamic rendering. You can see that just by watching that page load in a regular browser. The control just can't cut it some of the times.
You might want to try some alternative browser controls. There are no guarantees that it will work with any of them, but at least it's something to try.
Awesomium : Originally based on Chromium. I don't know if they still integrate Chromium changes or if they've gone in their own direction. It's free for personal use as well as commercial making less than $100k.
DotNetBrowser : Embed a Chromium-based WPF / WinForms component into your .NET application to display modern web pages built with HTML5, CSS3, JavaScript, Silverlight etc.
geckofx : An open-source component for embedding Mozilla Gecko (Firefox) in .NET applications.
Xilium.CefGlue : A .NET/Mono binding for The Chromium Embedded Framework (CEF) by Marshall A. Greenblatt.
BrowseEmAll : BrowseEmAll.Cef (Chrome), BrowseEmAll.Gecko (Firefox), BrowseEmAll Core API (Chrome,Firefox,IE - COMMERCIAL)
There are probably others, but this should give you a start with some of the more popular active projects if you want to pursue this route.

The WebBrowser control is capable of rendering most web pages, but by default it attempts to render pages in compatibility mode (pretty much IE7, hence the issues). If you are building your own page, it's simple, just add the following tag to the header and it should render fine...
<meta http-equiv="X-UA-Compatible" content="IE=Edge" />
However, if you are trying to render a third party site you cannot add tags to, things get more difficult. As mentioned above, you can use a registry key (HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION) if it's just on your own machine.
If neither of these options are a possible solution, using a different browser control (again, great suggestions above) is pretty much your only option.
There's a great blog on controlling the browser control compatibility mode at https://learn.microsoft.com/en-gb/archive/blogs/patricka/controlling-webbrowser-control-compatibility

You should add your program name to the register HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION
for using the latest feature as same as your normal internet browser.
as for me, value 8000 (0x1F40) - IE8 mode can solve many script error problem.
Ref:
Use latest version of Internet Explorer in the webbrowser control

private void Form1_Load(object sender, EventArgs e)
{
var appName = Process.GetCurrentProcess().ProcessName + ".exe";
SetIE8KeyforWebBrowserControl(appName);
webBrowser1.ScriptErrorsSuppressed = true;
}
private void SetIE8KeyforWebBrowserControl(string appName)
{
RegistryKey Regkey = null;
try
{
// For 64 bit machine
if (Environment.Is64BitOperatingSystem)
Regkey = Microsoft.Win32.Registry.LocalMachine.OpenSubKey(#"SOFTWARE\\Wow6432Node\\Microsoft\\Internet Explorer\\Main\\FeatureControl\\FEATURE_BROWSER_EMULATION", true);
else //For 32 bit machine
Regkey = Microsoft.Win32.Registry.LocalMachine.OpenSubKey(#"SOFTWARE\\Microsoft\\Internet Explorer\\Main\\FeatureControl\\FEATURE_BROWSER_EMULATION", true);
// If the path is not correct or
// if the user haven't priviledges to access the registry
if (Regkey == null)
{
MessageBox.Show("Application Settings Failed - Address Not found");
return;
}
string FindAppkey = Convert.ToString(Regkey.GetValue(appName));
// Check if key is already present
if (FindAppkey == "8000")
{
MessageBox.Show("Required Application Settings Present");
Regkey.Close();
return;
}
// If a key is not present add the key, Key value 8000 (decimal)
if (string.IsNullOrEmpty(FindAppkey))
Regkey.SetValue(appName, unchecked((int)0x1F40), RegistryValueKind.DWord);
// Check for the key after adding
FindAppkey = Convert.ToString(Regkey.GetValue(appName));
if (FindAppkey == "8000")
MessageBox.Show("Application Settings Applied Successfully");
else
MessageBox.Show("Application Settings Failed, Ref: " + FindAppkey);
}
catch (Exception ex)
{
MessageBox.Show("Application Settings Failed");
MessageBox.Show(ex.Message);
}
finally
{
// Close the Registry
if (Regkey != null)
Regkey.Close();
}
}

You may even set the registry value to 11000 to have the latest version of IE!!

System.DirectoryServices.AccountManagement.PrincipalContext broken after Windows 10 update

I've been using this little function without any issue for the past few years to validate user credentials. The createPrincipalContext method returns a PrincipalContext with ContextType.Machine and the machine name.
public static bool ValidateCredentials(string username, string password, string domain = null) {
try {
using (var principalContext = createPrincipalContext(username, domain)) {
username = GetLoginInfo(username).Username;
// validate the credentials
if (principalContext.ValidateCredentials(username, password)) {
//once valid check if account is enabled
using (UserPrincipal user = UserPrincipal.FindByIdentity(principalContext, username)) {
return user.Enabled.GetValueOrDefault(false);
}
}
}
} catch (PrincipalOperationException e) {
traceError(e);
} catch (Exception e) {
traceError(e);
}
return false;
}
My development machine automatically updated to the latest version of Windows 10 this recently, and since then, principalContext.ValidateCredentials has been throwing the following exception.
System.IO.FileNotFoundException: The system cannot find the file specified.
Other than the machine update nothing else was changed. I've spend the last few days searching the net for what may have caused the issue.
Does anyone have any experience in identifying what may have been the cause and if possible, a solution?

One final Google before I started rolling back my machine to the previous build and I found this
https://connect.microsoft.com/IE/feedback/details/1904887/windows-10-insider-preview-build-10565
the problem is caused by missing registry entries in HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion, specifically: RegisteredOwner and RegisteredOrganization
EDIT:
Run the Registry Editor by pressing Windows R and typing regedit.exe. Browse to the location above
Just right click on the CurrentVersion in the Registry Editor and select New > String Value. After you add each entry ( RegisteredOwner and RegisteredOrganization ) edit their values. You can use your username and company name respectively.

Uncheck the Prefer 32-bit checkbox in your project's properties window under the Build tab, it is checked by default - see screenshot. This fixed it for me! Checking the checkbox again will cause the exceptions you describe to re-appear. I'm guessing this will force it to run in 64-bit mode if possible, and therefore use the 64-bit registry path rather than the WOW6432Node registry path and hence it will find the correct keys it needs.
Uncheck 'Prefer 32-bit' screenshot

Try change your build platform target to "AnyCPU", i found that if my platform target is x86, I have this issue!
Why, yet have no idea, seems like win 10 bug!!!

C# - Load existing system environment variables when the current process don't have them loaded

On Windows, I have a C# assembly that is COM visible. It references other assemblies to control an application in the machine. It works fine.
However, under Apache Web Server and using CGI, it doesn't work. After doing some debuging, I found out that the problem is that, while running under Apache's CGI, the environment variables SYSTEMROOT and SYSTEMDRIVE, which aparently are needed by the referenced assemblies, are not loaded.
I can configure Apache to pass those environemtn variables too, but before doing so, I'd really like to know if there's some command I can put on my C# COM visible assembly to make it load environment variables as if it was, let's say, the SYSTEM user or something like that, so it doesn't have to relay on the environment passed by the starting application.
How do you force loading an existent system environment variable in C#, when IT IS NOT SET in the current process (or it was process-deleted by the launching process)?
Thanks in advance for any suggestions!
EDIT 1 - ADDED INFO: Just to make it more clear (as I see in the current answers it's not so clear): Apache intendedly deletes a lot of environment variables for CGI processes. It's not that Apache cannot see them, it can, but it won't pass them to CGI processes.

This should do the trick:
Environment.GetEnvironmentVariable("variable", EnvironmentVariableTarget.Machine);
I did a small test and it is working:
//has the value
string a = Environment.GetEnvironmentVariable("TMP");
Environment.SetEnvironmentVariable("TMP", null);
//does not have has the value
a = Environment.GetEnvironmentVariable("TMP");
//has the value
a = Environment.GetEnvironmentVariable("TMP", EnvironmentVariableTarget.Machine);

SOLUTION: Marco's answer was great and technically answered my question - except that I found out that the environment variables SYSTEMROOT and SYSTEMDRIVE are not really set in the registry where all environment variables are set, so, the chosen answer works for all variables except those two, which I specified in the OP.
SYSTEMROOT is defined on the registry in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot, and apparently (after more research), SYSTEMDRIVE is generated as a substring of SYSTEMDRIVE.
So, to get SYSTEMDRIVE and SYSTEMROOT from registry and load them into the environment:
using Microsoft.Win32;
namespace MySpace
{
public class Setup
{
public Setup()
{
SetUpEnvironment();
}
private void SetUpEnvironment()
{
string test_a = Environment.GetEnvironmentVariable("SYSTEMDRIVE", EnvironmentVariableTarget.Process);
string test_b = Environment.GetEnvironmentVariable("SYSTEMROOT", EnvironmentVariableTarget.Process);
if (test_a == null || test_a.Length == 0 || test_b == null || test_b.Length == 0)
{
string RegistryPath = "HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion";
string SYSTEMROOT = (string) Registry.GetValue(RegistryPath, "SystemRoot", null);
if (SYSTEMROOT == null)
{
throw new System.ApplicationException("Cannot access registry key " + RegistryPath);
}
string SYSTEMDRIVE = SYSTEMROOT.Substring(0, SYSTEMROOT.IndexOf(':') + 1);
Environment.SetEnvironmentVariable("SYSTEMROOT", SYSTEMROOT, EnvironmentVariableTarget.Process);
Environment.SetEnvironmentVariable("SYSTEMDRIVE", SYSTEMDRIVE, EnvironmentVariableTarget.Process);
}
}
}
}
Then you can just call Setup setup = new Setup(); from other classes. And that's it. :-)

Environment.GetEnvironmentVariable
see reference here.
e.g.
Environment.CurrentDirectory = Environment.GetEnvironmentVariable("windir");
DirectoryInfo info = new DirectoryInfo(".");
lock(info)
{
Console.WriteLine("Directory Info: "+info.FullName);
}

Are the variables set as system wide?
If they are not, that is what you need to do, otherwise create user variables for the user the COM is running under.

Thank you. I cannot state with any certainty that this has once and for all driven a stake through the heart of the vampire, but amazingly enough, the error has disappeared (for now). The odd thing is that access to the statement
Environment.GetEnvironmentVariable("variable", EnvironmentVariableTarget.Machine);
is a real oddity in the debugger. It does not show up in Intellisense and does not even appear to fire, which leads me to suspect, which you all knew already, that this is some sort of magic runtime object Environment that has no instantiation in the debugger but also can be benignly jumped over. Oh well.
Oh and I should mention that after you see that error, you will note oddities in your Windows OS, which is worrisome. In particular, you will see, if you try to use the Control Panel /System/Advanced Properties (whatever) that it cannot load the dialog for the environment variables any more, indicating that %windir% has been seriously hosed (compromised) across all applications. Bad bad bad....

Registry access exception problem

I'm currently building a registry explorer, mostly because I want to support some much better searching operations. Like 'find all' and regular expressions. One problem I'm facing is that some keys throw a security exception when opening. I HAVE TRIED running the app with administrator priviledges, my user account is an administrator also. I embedded a manifest with "requireAdministrator" requested priviledges. I have also tried setting the ClickOnce security settings to Full trust, which is incompatible with requireAdministrator, or so Visual Studio tells me.... Nothing seems to help with avoiding this exception.
I would just like to iterate over all of the keys. I do not wish to add/delete keys. If a user wishes to delete a key and does not have permission to do so, it would display an error message. I just want to be able to have unrestricted READ access. Is this possible?
FTR: I'm on Win7 x64 and using Vs2010u and project is written in C# on .net 4.0. If regedit is capable of reading all keys even if it doesn't let you edit some of them. It would seem appropriate that we too can make an app to do the same thing. Though I'm finding it very difficult, and there doesn't seem to be any real help on the www. Only link-link circles, yay.
[EDIT]
Here's the code that reads the keys:
private void IterateSubKeys(RegistryKeyModel key) {
var subKeys = key.Key.GetSubKeyNames();
var values = key.Key.GetValueNames();
foreach (var valuename in values) {
try {
var valueKind = key.Key.GetValueKind(valuename);
var value = key.Key.GetValue(valuename);
key.Values.Add(new RegistryValueModel(valuename, value, valueKind));
}
catch { }
}
foreach (var keyname in subKeys) {
try {
var subkey = key.Key.OpenSubKey(
keyname,
RegistryKeyPermissionCheck.ReadSubTree,
RegistryRights.ReadKey);
key.SubKeys.Add(new RegistryKeyModel(subkey));
}
catch { Console.WriteLine("Error reading key: {0}", keyname); }
}
}

This is by design. There are lots of security related keys that can only accessible to the System account. You can't use that account. Regedit can't read these keys either, they are just not visible. Avoiding the expensive exception is going to require pinvoke.