如何确定在Windows应用商店/通用应用程序中无法加载哪个Dll依赖关系? [英] How to Determine Which Dll Dependency is Failing to Load in Windows Store/Universal Apps?
问题描述
正在运行UWP项目时，我会收到以下对话框.
When running a UWP project I'm working on I receive the following dialog.
无法激活Windows应用商店应用程序'MyAppsMangledName'.'MyExeName'进程已启动，但是激活请求失败，错误为'应用程序未启动'."
"Unable to activate Windows Store app 'MyAppsMangledName'. The 'MyExeName' process started, but the activation request failed with error 'The App didn't start'."
Visual Studio输出具有以下内容.
The Visual Studio output has the following.
线程0x3d4c已退出，代码为-1073741515(0xc0000135). 线程0x3b50已退出，代码为-1073741515(0xc0000135). 程序"MyExeName"已退出，代码为-1073741515(0xc0000135)未找到相关的dll".
The thread 0x3d4c has exited with code -1073741515 (0xc0000135). The thread 0x3b50 has exited with code -1073741515 (0xc0000135). The program 'MyExeName' has exited with code -1073741515 (0xc0000135) 'A dependent dll was not found'.
事件查看器具有3个事件，这些事件基本上以3种不同的方式重现了弹出对话框，
The Event Viewer has 3 events that basically restate the popup dialog in 3 different ways and nothing else.
在启动过程中运行Process Monitor时，我看到许多dll已成功加载，但除了一些NAMENOTFOUND事件(不幸的是，这些事件未显示未找到的名称)之外，没有任何指示失败的信息.
Running Process Monitor during the startup shows me many dlls being successfully loaded but nothing indicating failure besides some NAMENOTFOUND events which unfortunately don't show what name wasn't found.
在Win32中，一个有用的对话框通常指示无法加载哪个dll.当然，对于.Net应用程序，融合日志使跟踪非常简单.但是对于商店/UWP应用程序，我似乎找不到找到跟踪违规依赖关系的好方法.
In Win32 a helpful dialog usually indicates which dll could not be loaded. And of course with .Net apps the fusion logs make tracing this very straight forward. But for Store/UWP apps I can't seem to find a good way to track down the offending dependency.
推荐答案
这对我正在从事的项目也很重要.经过大量的挖掘，我团队中的某个人得以弄清楚.因此，我想与其他在同一问题上苦苦挣扎的人分享一下.
This just hit me too on a project I'm working on. And after much digging, someone on my team was able to figure it out. So figured I'd share it for others struggling with the same issue.
我们正在使用VS2015用C ++进行UWP.因此，请记住，在我的C:\ program Files(x86)\ Windows Kits 10 \ Debuggers \ x64 \ gflags.exe中有一个名为gflags的程序
We're doing UWP with C++ using VS2015. So with that in mind, there is a program called gflags located for me at C:\program Files (x86)\Windows Kits 10\Debuggers\x64\gflags.exe
因此，您需要一个带有admin的cmd窗口，然后运行命令gflags.exe -i your-program-name.exe + sls
So you'll want a cmd window with admin, and run the command gflags.exe -i your-program-name.exe +sls
注意:gflags不在我的路径中，因此可以在执行命令之前添加路径或导航至路径.
Note: gflags wasn't in my path so either add the path or navigate to where it is before executing the command.
只需输入不带目录的exe名称即可.它的作用是为VS设置一个注册表设置，从而为exe匹配该名称的功能打开sls(显示加载程序快照).然后在VS中运行您的应用程序，您将获得大量的dll加载信息，包括无法在输出窗口中加载的dll的名称.在我们的例子中是这样:
Just pass in the name of the exe without directories. What it does is sets a registry setting for VS that turns on sls (show loader snaps) for exe's matching that name. Then run your application in VS and and you'll get a large amount of dll loading information including names of the dlls that fail to load in your output window. In our case it was this:
5038:34f4 @ 789320468-LdrpProcessWork-错误:无法加载DLL:"vccorlib140d_app.DLL"，父模块:"E:\ projects --- \ Source \ Builds \ vs2015_Debug_UWP_x64 \ AppX-.exe"，状态:0xc0000135
5038:34f4 @ 789320468 - LdrpProcessWork - ERROR: Unable to load DLL: "vccorlib140d_app.DLL", Parent Module: "E:\projects---\Source\Builds\vs2015_Debug_UWP_x64\AppX---.exe", Status: 0xc0000135
测试此(YMMV)的另一种更快的替代方法是将输出与另一个有效的构建配置进行比较.在我们的情况下，我们可以运行发行版构建，但是调试构建barf.并且发布输出显示vccorlib140_app.dll已加载，而调试缺少它.
Another quicker alternative way to test this (YMMV) was to compare the output with another build config that does work. In our case, we can run release builds just fine, but debug builds barf. And the release output showed vccorlib140_app.dll loaded while the debug had it missing.
这篇关于如何确定在Windows应用商店/通用应用程序中无法加载哪个Dll依赖关系?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
