So ermitteln Sie, welche Dll-Abhängigkeit in Windows Store/Universal Apps nicht geladen werden kann

Question

Beim Ausführen eines UWP-Projekts, an dem ich gerade arbeite, erhalte ich den folgenden Dialog.

"Aktivierung der Windows Store-App 'MyAppsMangledName' nicht möglich. Der Prozess 'MyExeName' wurde gestartet, aber die Aktivierungsanforderung ist mit dem Fehler 'Die App wurde nicht gestartet' fehlgeschlagen."

Die Visual Studio-Ausgabe hat Folgendes.

Der Thread 0x3d4c wurde mit dem Code -1073741515 (0xc0000135) beendet. Der Thread 0x3b50 wurde mit dem Code -1073741515 (0xc0000135) beendet. Das Programm 'MyExeName' wurde mit dem Code -1073741515 (0xc0000135) 'Eine abhängige DLL wurde nicht gefunden' beendet.

Die Ereignisanzeige verfügt über 3 Ereignisse, die den Popup-Dialog auf drei verschiedene Arten und nichts anderes neu festlegen.

Running Process Monitor während des Startvorgangs zeigt mir, dass viele DLLs erfolgreich geladen wurden, aber nichts zeigt Fehler an, abgesehen von einigen NAMENOTFOUND-Ereignissen, die leider nicht anzeigen, welcher Name nicht gefunden wurde.

In Win32 zeigt ein hilfreicher Dialog normalerweise an, welche DLL nicht geladen werden konnte. Und natürlich machen die Fusion-Logs mit .Net-Apps diese Verfolgung sehr einfach. Aber für Store/UWP-Apps finde ich keinen guten Weg, die beleidigende Abhängigkeit aufzuspüren.

Answer 1

Das traf mich auch in einem Projekt, an dem ich gerade arbeite. Und nach vielem Graben konnte jemand in meinem Team es herausfinden. Ich dachte mir, ich würde es für andere teilen, die mit dem gleichen Problem kämpfen.

Wir machen UWP mit C++ mit VS2015. Also in diesem Sinne gibt es ein Programm namens gflags für mich unter C: \ Programme (x86) \ Windows-Kits 10 \ Debuggers \ x64 \ gflags.exe

So werden Sie ein cmd-Fenster mit Admin wollen , und führen Sie den Befehl gflags.exe -i Ihr-Programm-Name.exe + Sls

Hinweis: gflags war nicht in meinem Pfad, so entweder den Pfad hinzufügen oder navigieren Sie zu, wo es ist, bevor Sie den Befehl ausführen.

Geben Sie einfach den Namen der exe ohne Verzeichnisse. Was es tut, ist eine Registrierungseinstellung für VS, die sls (show loader snaps) für Exe aktiviert, die diesem Namen entsprechen. Dann führen Sie Ihre Anwendung in VS und und Sie erhalten eine große Menge von Dll-Lade-Informationen einschließlich Namen der DLLs, die nicht in Ihrem Ausgabefenster geladen werden können. In unserem Fall war es das:

5038: 34f4 @ 789320468 - LdrpProcessWork - ERROR: Unable DLL zu laden: "vccorlib140d_app.DLL", Eltern Modul: „E: \ Projekte --- \ Source \ Builds \ vs2015_Debug_UWP_x64 \ AppX ---. Exe ", Status: 0xc0000135

Eine andere schnellere alternative Möglichkeit, dies zu testen (YMMV) war, die Ausgabe mit einer anderen Build-Konfiguration zu vergleichen, die funktioniert. In unserem Fall können wir Release-Builds problemlos ausführen, aber Debug-Builds barf. Und die Release-Ausgabe zeigte vccorlib140_app.dll geladen, während das Debug hatte es fehlte.