Beim Ausführen eines UWP-Projekts, an dem ich gerade arbeite, erhalte ich den folgenden Dialog.
"Die Windows Store-App kann nicht aktiviert werden" MyAppsMangledName '. Der Prozess' MyExeName 'wurde gestartet, aber die Aktivierungsanforderung ist mit dem Fehler' Die App wurde nicht gestartet 'fehlgeschlagen. "
Die Visual Studio-Ausgabe enthält 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 formulieren.
Wenn ich den Prozessmonitor während des Startvorgangs lese, werden mir viele DLLs erfolgreich geladen, aber nichts weist auf Fehler hin, 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 keine gute Möglichkeit, die problematische Abhängigkeit aufzuspüren.
Das trifft 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. In diesem Sinne gibt es ein Programm namens gflags, das sich für mich unter C: \ Programme (x86) \ Windows Kits 10 \ Debuggers \ x64 \ gflags.exe
befindetSie werden also ein cmd-Fenster mit admin brauchen und den Befehl gflags.exe -i Ihr-Programmname.exe + sls
ausführenHinweis: gflags befand sich nicht in meinem Pfad. Fügen Sie also entweder den Pfad hinzu oder navigieren Sie dorthin, wo er sich befindet, bevor Sie den Befehl ausführen.
Geben Sie einfach den Namen der exe ohne Verzeichnisse ein. Was es tut, ist eine Registrierungseinstellung für VS, die sls (show loader snaps) für Exe aktiviert, die mit diesem Namen übereinstimmen. 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 - FEHLER: DLL konnte nicht geladen werden: "vccorlib140d_app.DLL", übergeordnetes Modul: "E: \ projekte --- \ Source \ Builds \ vs2015_Debug_UWP_x64 \ AppX ---. exe", Status: 0xc0000135
Ein anderer schnellerer alternativer Weg, 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 Debugging fehlte.
Tags und Links dll visual-c++ win-universal-app windows-store-apps native