Failure to launch Windows program via URI after adding to HKCU/Software/Classes

Question

I'm trying to set up a test application on Windows to launch via a "myapp://website.com"-style URI. Mostly, I'm basing myself off of tutorials like this:

http://msdn.microsoft.com/en-us/library/ie/aa767914(v=vs.85).aspx

While I got the initial setup working inside HKEY_CLASSES_ROOT, a new constraint is for the installation to happen without requiring administrator access. So, I deleted all changes in CLASSES_ROOT, and decided to retry the registry additions, instead using the HKEY_CURRENT_USER branch, at HKEY_CURRENT_USER/Software/Classes/myapp.

This appears to be detected by the browsers, and they display their confirmation dialog. However, they never actually run the app. Internet Explorer gives the most helpful error message, with a dialog saying "Unable to open this helper application for {uri}. The protocol specified in this address is not valid. Make sure the address is correct, and try again.

Is there some part of the registry I'm missing for a non-administrator setup? This is an export of my changes as a .reg. (Dashes censoring my username). EditFlags was added as a guess, but didn't work without it either.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Classes\myapp]
"URL Protocol"=""
@="URL:David Protocol"
"EditFlags"=dword:02000000

[HKEY_CURRENT_USER\Software\Classes\myapp\DefaultIcon]
@="C:\\Users\\------\\AppData\\Roaming\\-----s Stuffs\\URISchemeTest.exe,1"

[HKEY_CURRENT_USER\Software\Classes\myapp\shell]

[HKEY_CURRENT_USER\Software\Classes\myapp\shell\open]

[HKEY_CURRENT_USER\Software\Classes\myapp\shell\open\command]
@="\"C:\\Users\\-------\\AppData\\Roaming\\------s Stuffs\\URISchemeText.exe\" \"%1\""

Answer 1

Now that I have this working, I can't be perfectly certain of what it was that was causing problems, but I can at least give an account of what I tried to do differently in the hopes this helps future researchers.

%-sign directory accessors might not be supported by the path declaration. If they are, they may need to be encoded a certain way. Lower down In the article linked in the question, it mentions how Internet Explorer may decode certain URL parameters, but other browsers may not. Either way, if you've been specifying the command line as "%APPDATA%/MyProgram.exe", it may be more reliable starting from "C:/" until you can work through that issue.

EDIT: One other thing I just noticed, if the Paste from my question is correct: My working version of the registry changes set the default key of the root to "URI :David Protocol". Note "URI", not "URL". It's possible that mis-naming that (easy since another value is declared as "URL Protocol") could break the resulting effects.

While you might not have to specify a DefaultIcon, you may want to be careful that you're not referring to an invalid one. For safety, I set up mine to point specifically to a .ico file, rather than ".exe,1"

As some other commenters mentioned, I don't think EditFlags is really necessary, and might not be related.

A cautionary rebuttal to the highly-voted answer near this one, though: This. Works. No UAC access necessary. From the outset of my research, I personally would have believed an explanation that it's too risky to allow without a UAC admin prompt, etc. However, I took the time to test it, and could write a simple program with a button that sets itself up under HKCU/Software/Classes, and is accessible to the browser. I then tested it from the computer of a developer who had never taken part in any of my research (clean environment), and without any admin prompts, it worked fine. (Obviously, this program will only be accessible to the current user)

(For easy reading, a reminder: HKCU = HKEY_CURRENT_USER. HKCR = HKEY_CLASSES_ROOT. HKLM = HKEY_LOCAL_MACHINE)

Anything that could write to the user's HKCU registry already has non-admin binary access. Furthermore, all browsers will show a warning message about launching the program before opening it (perfectly understandable, given that it's local code). Several of them even give the full folder path of the executable you'll be launching.

I know the tutorial said to put the key in HKCR; and that this is known to come from HKLM/Software. However, it's worth reading up the whole story here:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms724475(v=vs.85).aspx

This key is partially derived from the HKCU hive - and in fact, the user's settings will override the local machine settings. There is nothing specifically indicating that HKLM will override HKCU when displaying this type of key inside of HKCR.

Answer 2

You cannot ignore what the MSDN article tells you, registering the protocol handler in a HKCR key is a hard requirement.

There's a good reason for that, also fairly explicitly stated in the article, protocol handlers are dangerous. They allow an arbitrary web page to start a program on your machine. They even work inside a Store app, another example of a heavily secured runtime environment that runs code inside a sandbox that stops dangerous operations.

Documenting HKCR doesn't help much unravel this, it was meant for appcompat with 16-bit code and today is an alias. Shows a merged view of both HKCU and HKLM keys. The HKLM keys are different from HKCU keys, writing key values require elevation. Only a program that can acquire a elevated security token can create new values or alter them, normally obtained by going through the UAC prompt. The problem with HKCU keys is that any program can write keys there without elevation. Which would open up a security hole if protocol handlers could be registered in a HKCU key. So this cannot work, urlmon simply doesn't look at the HKCU keys to find the protocol handler.