How to determine which Dll dependency does not load in Windows Store / Universal Apps?

When I start the UWP project I'm working on, I get the following dialog box.

"Failed to activate the Windows Store application" MyAppsMangledName ". The process" MyExeName "started, but the activation request failed with the error" The application did not start. "

Visual Studio output has the following.

Stream 0x3d4c exited with code -1073741515 (0xc0000135). Stream 0x3b50 exited with code -1073741515 (0xc0000135). The program "MyExeName" came out with the code -1073741515 (0xc0000135) "Dependent dll was not found."

Event Viewer has 3 events that basically repeat the popup dialog in three different ways and no more.

The process monitor at startup indicates that many DLLs have loaded successfully, but nothing indicates failure, except for some NAMENOTFOUND events, which, unfortunately, do not show which name was not found.

In Win32, a useful dialog usually indicates which DLL cannot be loaded. And, of course, with .Net applications, merge logs make tracing very straightforward. But for Store / UWP applications, I cannot find a good way to track the dependent dependency.

+9
dll visual-c ++ native windows-store-apps win-universal-app
source share
1 answer

It just hit me on the project I'm working on. And after a lot of digging, one of my team was able to figure it out. So I decided to share it with others struggling with the same problem.

We do UWP with C ++ using VS2015. Therefore, bearing in mind, there is a program called gflags located for me in the folder C: \ program Files (x86) \ Windows Kits 10 \ Debuggers \ x64 \ gflags.exe

So, you need the cmd window with administrator and run the command gflags.exe -i your-program-name.exe + sls

Note: gflags was not in my path, so add the path or go to where it is before executing the command.

Just pass the name exe without directories. What it does is set a registry setting for VS, which includes sls (show loader snaps) for exe matching that name. Then run the application in VS and get a lot of information about loading the dll, including DLL names that do not load in the output window. In our case, it was:

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

Another quicker alternative way to test this (YMMV) is to compare the result with another build configuration that works. In our case, we can run release builds just fine, but debug creates barf. And the release output showed that vccorlib140_app.dll was loaded while there was no debugging.

+11
source share

All Articles