添加到 HKCU/Software/Classes 后无法通过 URI 启动 Windows 程序答案

【问题标题】：Failure to launch Windows program via URI after adding to HKCU/Software/Classes添加到 HKCU/Software/Classes 后无法通过 URI 启动 Windows 程序
【发布时间】：2014-06-19 12:05:52
【问题描述】：

我正在尝试在 Windows 上设置一个测试应用程序以通过“myapp://website.com”样式的 URI 启动。大多数情况下，我的基础是这样的教程：

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

虽然我在 HKEY_CLASSES_ROOT 中进行了初始设置，但新的限制是无需管理员访问即可进行安装。因此，我删除了 CLASSES_ROOT 中的所有更改，并决定重试注册表添加，而不是使用 HKEY_CURRENT_USER/Software/Classes/myapp 中的 HKEY_CURRENT_USER 分支。

这似乎被浏览器检测到，并显示确认对话框。但是，他们从未真正运行过该应用程序。 Internet Explorer 提供了最有用的错误消息，并带有一个对话框，显示“无法为 {uri} 打开此帮助应用程序。此地址中指定的协议无效。请确保地址正确，然后重试。

对于非管理员设置，我是否缺少某些注册表部分？这是我的更改作为 .reg 的导出。（破折号审查我的用户名）。 EditFlags 是作为猜测添加的，但没有它也无法工作。

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\""

【问题讨论】：

什么是 EditFlags 02000000？我在这里找不到它：msdn.microsoft.com/en-us/library/windows/desktop/… 无论如何也无济于事。
我认为您忘记定义默认操作（打开）：[HKEY_CURRENT_USER\Software\Classes\mailto\shell] @="open"。你能不能把你的 exe 也移到另一个文件夹？
我刚刚检查了我这边的 mailto 的“shell”键，它没有任何值（即 default="open"）。实际上，我有时可能会让这个工作，这可能与路径问题有关，但我不确定。似乎默认图标的任何问题都会阻止启动。 @SimonMourier 我认为我通过误读教程错误地写了 02.. 而不是 ..20，但其他方式也没有做任何事情。
如果您从“运行”菜单中输入 uri 会发生什么？
我刚刚在没有 EditFlags 或图标的 Windows 7 上尝试过，它运行良好。您使用的是什么操作系统？您是否有过时的机器范围设置（HKEY_CLASSES_ROOT）与您的每个用户设置发生冲突？您是否尝试过在新用户帐户下运行它？浏览器可能正在缓存有关您的新协议的一些信息。

标签： windows registry administrator uri-scheme

【解决方案1】：

您不能忽略 MSDN 文章告诉您的内容，在 HKCR 密钥中注册协议处理程序是一项硬性要求。

有一个很好的理由，在文章中也相当明确地指出，协议处理程序是危险的。它们允许任意网页在您的机器上启动程序。它们甚至可以在 Store 应用中工作，这是高度安全的运行时环境的另一个示例，它在沙箱内运行代码以阻止危险操作。

记录 HKCR 并不能解决这个问题，它适用于 16 位代码的 appcompat，而今天是一个别名。显示 HKCU 和 HKLM 键的合并视图。 HKLM 键与 HKCU 键不同，写入键值需要提升。只有可以获取提升的安全令牌的程序才能创建新值或更改它们，通常通过 UAC 提示获得。 HKCU 密钥的问题是任何程序都可以在那里写入密钥而无需提升。如果可以在 HKCU 密钥中注册协议处理程序，这将打开一个安全漏洞。所以这行不通，urlmon 根本不查看 HKCU 密钥来查找协议处理程序。

【讨论】：

谷歌浏览器在没有管理员权限的情况下就做到了，至少在它刚问世时是这样。如果您在收到管理员提示时单击“取消”，那么您仍然可以设置 http、https 和 ftp 以由其处理。所以不，这是不正确的。
由浏览器选择是否使用 urlmon api。当然，像 Chrome 这样的跨平台浏览器不会太热衷于只为一个平台编写特殊代码。从事实而不是假设工作。您可以使用 SysInternals 的 Process Monitor 来查看浏览器正在探测注册表。
这是一个欺骗性的帖子，并且由于获得的声誉而被赋予了更多的权重。 MSDN 文章在任何地方都说写信给 HKCR 是一项硬性要求，这完全是不真实的。文章中陈述的唯一硬性要求是关于必须创建的注册表项的结构。在 HKCU\Software\Classes 中注册一个 URI 方案对于每个用户的应用程序来说非常有效。
我不认为在 HKCU\Software\Classes 中注册 URI 方案有效——这是事实。我在这里发表评论是为了防止人们对您的实事求是的回答感到气馁。我不知道为什么 OP 一开始就有问题（后来他们解决了），这就是为什么我没有发布答案。
这篇文章中的信息充其量是不准确的，而且在很多方面都是错误的。 msdn.microsoft.com/en-us/library/windows/desktop/… HKEY_CLASSES_ROOT 是 HKEY_LOCAL_MACHINE\SOFTWARE\Classes 和 HKEY_CURRENT_USER\Software\Classes 与本地计算机中当前用户配置单元覆盖值的优先组合。

【解决方案2】：

现在我有了这个工作，我不能完全确定是什么导致了问题，但我至少可以说明我尝试做不同的事情，希望这对未来的研究人员有所帮助。

%-sign 目录访问器可能不受路径声明的支持。如果是，它们可能需要以某种方式编码。在问题中链接的文章中，它提到了 Internet Explorer 如何解码某些 URL 参数，但其他浏览器可能不会。无论哪种方式，如果您一直将命令行指定为“%APPDATA%/MyProgram.exe”，那么从“C:/”开始可能会更可靠，直到您可以解决该问题。

编辑：我刚刚注意到的另一件事，如果我的问题中的粘贴是正确的：我的注册表更改的工作版本将根的默认键设置为“URI：大卫协议”。注意“URI”，而不是“URL”。错误命名（很容易，因为另一个值被声明为“URL 协议”）可能会破坏产生的效果。

虽然您可能不必指定 DefaultIcon，但您可能需要注意不要引用无效图标。为了安全起见，我将我的设置为专门指向 .ico 文件，而不是“.exe,1”

正如其他一些评论者所提到的，我认为 EditFlags 并不是真正必要的，并且可能不相关。

对这个问题附近投票率很高的答案的警告性反驳：这个。有效。 无需 UAC 访问。从我的研究开始，我个人会相信这样一个解释，即如果没有 UAC 管理员提示等，风险太大而不允许这样做。但是，我花时间对其进行了测试，并且可以编写一个带有设置自身按钮的简单程序在 HKCU/Software/Classes 下，浏览器可以访问。然后，我从一位从未参与过我的任何研究（清洁环境）的开发人员的计算机上对其进行了测试，并且没有任何管理员提示，它运行良好。（很明显，这个程序只有当前用户可以访问）

（为了方便阅读，提醒一下：HKCU = HKEY_CURRENT_USER.HKCR = HKEY_CLASSES_ROOT.HKLM = HKEY_LOCAL_MACHINE）

任何可以写入用户 HKCU 注册表的内容都已经具有非管理员二进制访问权限。此外，所有浏览器都会在打开程序之前显示有关启动程序的警告消息（完全可以理解，因为它是本地代码）。其中一些甚至提供了您将要启动的可执行文件的完整文件夹路径。

我知道教程说要把密钥放在 HKCR 中；并且已知这来自 HKLM/Software。但是，值得在这里阅读整个故事：

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

此键部分源自 HKCU 配置单元 - 事实上，用户的设置将覆盖本地计算机设置。在 HKCR 中显示这种类型的键时，没有明确表明 HKLM 将覆盖 HKCU。

【讨论】：