是时候写一篇日志进行这个问题的总结了，毕竟拖得时间太久，久到连 gOxiA 自己都要遗忘掉!背景是这样的，在某个案例中需要使用“start apps”调用某个应用，也就是说某个程序内部会通过 Windows 的 Start 命令调用一个应用程序，这个应用程序可能是 chrome 也可能是 msedge，这里以msedge 早期版本为例进行说明。

        当我们在 cmd 命令提示符下使用“start msedge”后，正常情况应该会默认启动基于 Chromium 开发的 Edge 浏览器，但是却遇到了错误提示，内容为“Windows 找不到文件 'msedge'，请确定文件名是否正确，再试一次”。当然现在的版本已经解决了这个问题，但是在某些极端环境下，不论是 msedge 还是 chrome ，甚至其他应用，也都可能会遭遇到该问题。

        起初发现这个问题时，首先想到的分析方法就是抓取轨迹进行分析。确实有所收获，gOxiA 发现在执行“Start msedge”时会遍历注册表，并最终读取“HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\msedige.exe”路径下定义的值，而结果是未能找到该值。

        此时，问题已经很明朗了，修复该路径定制的值，问题即可解决！但其实该问题却引出了更底层的一些知识，而且非常有价值。

        在早先的排错过程中，gOxiA 尝试了重装应用程序，排除了安装问题。由于最早遇到的类似案例就是基于 Chrome 的，所以是先对 Chrome 进行了分析。下图是当时对 Chrome 分析时的截图，会发现执行“Start chrome”后，会遍历注册表但最终会以“HKCU\Software\MicrosoftWindows\CurrentVersion\App Paths\chrome.exe”定义的值为准。

        此时，不论 HKLM 下如何定义都不会生效，但是 msedge 的情况却正好相反，HKCU 下有定义的数据，也无法被正常调用。

        难道是因为安装应用程序的模式导致的？！我们知道，常见的 msi 安装包默认都会以计算机配置模式进行安装，所以需要以管理员权限执行 msi 安装包，默认应用程序会被安装在 ProgramFiles 目录下，如果你下载了 chrome 的脱机安装包，那么你会发现其安装格式为 msi。

        而如果安装包是 exe 格式，以 chrome 和 msedge 为例，通过云下载数据到本地后，会启动一个真正的安装过程，而这个安装过程是面向用户配置的，也就是说当前用户即使不是管理员，也能够正常安装它们，因为应用程序数据写入到了当前用户配置文件下，而涉及注册表的部分会写入到 HKCU 下。

        那么两者的区别是什么呢？其实显然易见，排除目录不谈，重点说说注册表，面向用户配置的在 HKCU 下，面向计算机配置的在 HKLM 下。

        看起来执行"start msedge"时发生错误是因为它要去读 HKLM 下的定义数据，而 HKLM 下无数据，也就说明当先 msedge 应用实例是安装在计算机配置下，那么也论证了这是 msedge 的一个 bug。（PS：该问题仅发生在 msedge 早期的开发版本中，gOxiA 已经向产品组提交了 bug，目前已经修复！）

        而对于之前在 Chrome 上遭遇的此类问题，可论证不是产品 bug，因为该应用程序实例是安装在用户配置下的，所以会依据 HKCU 下的定义数据执行，而发生故障是因为 HKCU 下的定义数据被“流氓”软件破坏导致的，所以必须修复 HKCU 下的定义数据。

        综上，貌似这些执行机制是一个规范设计，那么就需要找出微软官方的依据进行论证。功夫不负有心人，在 Windows Shell 的官方文档中确实有相关的说明。

"Per-user default settings are specific to an individual user account on the system. If per-user default settings are present, they take precedence over corresponding per-computer defaults for that account."

具体可参考：https://docs.microsoft.com/en-us/windows/desktop/shell/vista-managing-defaults