Thanks for the report.

That's very strange, as the DeleteSubKeyTree line only runs if the subkey is found:

Could you please check these paths in regedit and screenshot them for us? (They might not both exist.) Hopefully that would give us enough information to start investigating:

HKEY_LOCAL_MACHINE\Software\Classes\ckan
HKEY_CURRENT_USER\Software\Classes\ckan

Very strange indeed.

There are no entries for CKAN under current user, but I've attached a screenshot of the entries under local machine. Let me know if you need anything else.

Thanks!

Can you please try this test build? I reworked that function a bit to try to re-use the originally successful return value of the Open call to also do the deletion. Hopefully this will at least give us an exception that's different in an informative way.

• (link removed, see below)

Sure. The test build prompts me to add a handler upon launch. The console window then prompts for the rights to make changes, and throws the same error. I ran it twice to check if it was setting the handler, same result the second time.

12186 [1] ERROR CKAN.URLHandlers (null) - There was an error while registering the URL handler for ckan:// - Cannot write to the registry key.
12200 [1] ERROR CKAN.URLHandlers (null) -    at System.ThrowHelper.ThrowUnauthorizedAccessException(ExceptionResource resource)
   at Microsoft.Win32.RegistryKey.EnsureWriteable()
   at Microsoft.Win32.RegistryKey.DeleteSubKeyTree(String subkey, Boolean throwOnMissingSubKey)
   at CKAN.URLHandlers.RegisterURLHandler_Win32()
   at CKAN.URLHandlers.RegisterURLHandler(Configuration config, IUser user)

Thanks! Not to nitpick, but that's not quite the same error. It switched from:

Cannot delete a subkey tree because the subkey does not exist.

to:

Cannot write to the registry key.

So I think your user can't modify HKEY_LOCAL_MACHINE for whatever reason. If you're comfortable making changes in regedit, could you please try deleting HKEY_LOCAL_MACHINE\Software\Classes\ckan manually? Then we can check whether CKAN recreates it in the same place or not.

Yeah, you're right. Sorry, I was doing something else and didn't even read the error the second time, just copied it. I've deleted the registry entry and got a new error:

10769 [1] ERROR CKAN.URLHandlers (null) - There was an error while registering the URL handler for ckan:// - Access to the registry key 'HKEY_CLASSES_ROOT\ckan' is denied.
10783 [1] ERROR CKAN.URLHandlers (null) -    at Microsoft.Win32.RegistryKey.Win32Error(Int32 errorCode, String str)
   at Microsoft.Win32.RegistryKey.CreateSubKeyInternal(String subkey, RegistryKeyPermissionCheck permissionCheck, Object registrySecurityObj, RegistryOptions registryOptions)
   at Microsoft.Win32.RegistryKey.CreateSubKey(String subkey)
   at CKAN.URLHandlers.RegisterURLHandler_Win32()
   at CKAN.URLHandlers.RegisterURLHandler(Configuration config, IUser user)

Did you get the "CKAN requires permission to add a handler for ckan:// URLs." dialog that time? That would tell us whether CKAN is attempting to elevate permissions in order to set the key.

Yes, I did get a permissions prompt. I just ran the test build again and received no prompt to register the handler (and thus no error message in the console). There are no CKAN entries under either current user or local machine classes.

Edit: Entering ckan: in the browser also attempts to open the app so it appears to be set.

Edit 2: Running the stable version of CKAN still produces the same original error on launch.

OK, I was being a bit dense there. The main (unelevated) process catches the unauthorized access exception, handles it fully (user prompt, retry with elevated permissions, etc.), and then re-throws it for no reason:

... which means that the error you're seeing now will be printed every time CKAN tries to register its URL handler as a normal user, regardless of whether it's ultimately successful. It's a red herring.

Here's a new test build with that re-throw statement removed:

• (Link removed, get https://github.com/KSP-CKAN/CKAN/releases/latest)

If that looks better, we can try making this change in the main code.

Okay, that seems to work, at least partially.

I tried running the new build from a new location on my drive, without deleting the previous registry entries. It prompted for setting the handler on startup, prompted for permissions in the console, and then didn't throw any errors, but upon launching it again, it prompted for setting the handler again, and ckan: in the browser was still attempting to open the now missing previous test build.

After deleting the registry entry again, it now sets the handler without throwing an error. Relaunching works as expected, and launching via the browser works as expected.

So there is still the issue of it not deleting/resetting previously set registry entries, but it can set a new entry without throwing any errors.