运行我正在处理的 UWP 项目时,我收到以下对话框。
“无法激活 Windows 应用商店应用程序“MyAppsMangledName”。“MyExeName”进程已启动,但激活请求失败,并出现错误“应用程序未启动”。”
Visual Studio 输出如下。
线程 0x3d4c 已退出,代码为 -1073741515 (0xc0000135)。 线程 0x3b50 已退出,代码为 -1073741515 (0xc0000135)。 程序“MyExeName”已退出,代码为 -1073741515 (0xc0000135)“未找到依赖的 dll”。
事件查看器有 3 个事件,基本上以 3 种不同的方式重述弹出对话框,仅此而已。
在启动期间运行进程监视器显示许多 dll 已成功加载,但除了一些 NAMENOTFOUND 事件之外没有任何指示失败的信息,不幸的是,这些事件没有显示未找到的名称。
在 Win32 中,一个有用的对话框通常会指示无法加载哪个 dll。当然,对于 .Net 应用程序,融合日志使跟踪变得非常简单。但对于 Store/UWP 应用程序,我似乎找不到一种好方法来追踪有问题的依赖项。
这对我正在从事的项目也产生了影响。经过大量挖掘,我团队中的某个人找到了答案。所以我想我会把它分享给其他遇到同样问题的人。
我们正在使用 VS2015 使用 C++ 开发 UWP。因此,考虑到这一点,有一个名为
gflags
的程序适合我,位于 C:\Program Files (x86)\Windows Kits 10\Debuggers\x64\gflags.exe
。
所以你需要一个带有管理员的
cmd
窗口,然后运行命令gflags.exe -i your-program-name.exe +sls
。
注意:
gflags
不在我的路径中,因此请在执行命令之前添加路径或导航到它所在的位置。
只需传入 EXE 的名称,不带目录。它的作用是为 VS 设置一个注册表设置,为匹配该名称的 EXE 打开 sls(显示加载程序快照)。然后在 VS 中运行您的应用程序,您将获得大量 DLL 加载信息,包括输出窗口中无法加载的 DLL 的名称。在我们的例子中是这样的:
5038:34f4 @ 789320468 - LdrpProcessWork - 错误:无法加载 DLL:“vccorlib140d_app.DLL”,父模块:“E:\projects---\Source\Builds s2015_Debug_UWP_x64\AppX---.exe”,状态:0xc0000135
测试此功能的另一种更快的替代方法(YMMV)是将输出与另一个有效的构建配置进行比较。在我们的例子中,我们可以很好地运行发布版本,但调试版本却会失败。发布输出显示
vccorlib140_app.dll
已加载,而调试却丢失了。