Having trouble opening a registry key

Richard Andrew x64

I have some simple code that worked when it was running on the .NET Framework 4.8, but after converting the project to .NET 8.0, the code is unable to open a subkey under HKLM because of an "UnauthorizedAccess Exception".

        try
        {
            using (RegistryKey BaseKey =
                   RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, RegistryView.Registry64)) // Does not throw any exception
            {
                using (RegistryKey SubKey = 
                    BaseKey.CreateSubKey("Software\\\\CompanyName\\\\ProductName")) // The code fails here with an UnauthorizedAccessException.
                {
                    DatabasePath = SubKey.GetValue("DBPath") as string;

                    SubKey.Close();
                    BaseKey.Close();

                    return Result.Success();
                }
            }
        }

FACTS: The registry key already exists when this code runs. The code is running under the LocalSystem account as a Windows Service. The initial open of the base key, HKLM apparently succeeds, but the BaseKey.Handle member is null immediately after the call to OpenBaseKey and before CreateSubKey. Please ask for more details.

The difficult we do right away... ...the impossible takes slightly longer.

Dave Kreskowiak

Got any anti-virus running? I've seen Trend get in the way like this before, though that was quite a bit ago.

Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles. Dave Kreskowiak

OriginalGriff

To be honest, you shouldn't really be using the Registry at all - access to it is going to get more restrictive rather than less as OS's advance. There are other ways to store info, particularly paths to DB that don't require the registry - here is the one I use: Instance Storage - A Simple Way to Share Configuration Data among Applications[^] I created it because I have multiple apps which need access to the same DB server and when I changed PC name I had to update loads of different apps. Now, they all use the same data on each machine and it's a single change on each PC to get the connection string. It may be a little overkill for you situation, but It's made my life a load easier! :-D

"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!

Richard Deeming

Richard Andrew x64 wrote:

The registry key already exists when this code runs.

In that case, why are you using CreateSubKey rather than OpenSubKey? CreateSubKey will attempt to create or open the key for write access. Since you're not writing to it, you should open it for read access instead. Also note that the RegistryView is only required if your app is compiled as 32-bit and needs to access the 64-bit registry, or vice-versa. Beyond that, you need to check the ACL on the specific registry key you're trying to open. It's possible that the system account has been denied (or has not been granted) access.

"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

Lost User

Richard Andrew x64 wrote:

The registry key already exists when this code runs.

The exception doesn't complain about it not existing.

Richard Andrew x64 wrote:

The code is running under the LocalSystem account as a Windows Service.

Which is, as documented, a limited account.

Richard Andrew x64 wrote:

The initial open of the base key, HKLM apparently succeeds, but the BaseKey.Handle member is null immediately after the call to OpenBaseKey and before CreateSubKey.

That might be a hint :thumbsup:

Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.

jochance

When the keys are little sandboxes only pertaining to your application, why wouldn't you want that centralized there and why wouldn't they make it work more like that? I don't really disagree and could see it going as you say... ditch the registry. I just don't get why IF the context is little sandboxed subsections of the registry instead of "you can edit anything or you can edit nothing".

OriginalGriff

That was the original idea: a single centralized depository for all config info. So it grew and grew, and bloated massively, slowed down everything and became a source of problems because there was no defined (or enforceable) separation of App A info from App B, much less system related info. It also added a route by which trojans could inject themselves into other apps very simply by modifying the config info. So it became depreciated as a centralized store for new apps because of the problems it caused, and security features evolved as UAC was introduced which deliberately made it harder to use. Those continue to become more restrictive as the OS evolves - at some point it will probably become off limits to all non-admin apps (it's only not at present for backward compatibility with legacy applications). If it had been designed as a sandbox environment in the first place, it could have been a really useful secure store - but it never was and that lack of foresight shows in the zombie version we currently have! :D

"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!