Come determinare quale dipendenza delle DLL non viene caricata in Windows Store/Universal Apps?

Question

Quando si esegue un progetto UWP su cui sto lavorando, viene visualizzata la seguente finestra di dialogo.

"Impossibile attivare l'app di Windows Store" MyAppsMangledName ". Il processo" MyExeName "è stato avviato, ma la richiesta di attivazione non è riuscita con errore" L'app non è stata avviata "."

L'output di Visual Studio presenta quanto segue.

Il thread 0x3d4c è terminato con il codice -1073741515 (0xc0000135). Il thread 0x3b50 è terminato con il codice -1073741515 (0xc0000135). Il programma 'MyExeName' è terminato con il codice -1073741515 (0xc0000135) 'Non è stata trovata una dll dipendente'.

Il Visualizzatore eventi ha 3 eventi che sostanzialmente riaffermano la finestra di dialogo popup in 3 modi diversi e nient'altro.

L'esecuzione di Process Monitor durante l'avvio mostra che molte DLL sono state caricate con successo ma che non indica alcun errore oltre ad alcuni eventi NAMENOTFOUND che sfortunatamente non mostrano quale nome non è stato trovato.

In Win32 una finestra di dialogo utile di solito indica quale DLL non può essere caricata. E naturalmente con le app .Net i registri di fusione rendono la traccia molto semplice. Ma per le app Store/UWP non riesco a trovare un buon modo per rintracciare la dipendenza offensiva.

Answer 1

Questo mi ha colpito anche per un progetto su cui sto lavorando. E dopo aver scavato molto, qualcuno della mia squadra è riuscito a capirlo. Quindi ho pensato di condividerlo per gli altri che lottano con lo stesso problema.

Stiamo eseguendo UWP con C++ utilizzando VS2015. Con questo in mente, c'è un programma chiamato gflags per me in C: \ program Files (x86) \ Windows Kits 10 \ Debuggers \ x64 \ gflags.exe

Quindi vorrai una finestra cmd con admin ed esegui il comando gflags.exe -i tuo -programma-nome.exe + sls

Nota: gflags non era nel mio percorso, quindi aggiungi il percorso o naviga dove si trova prima di eseguire il comando.

Basta inserire il nome dell'exe senza directory. Quello che fa è impostare un'impostazione di registro per VS che attiva sls (mostra gli snap caricatori) per il nome corrispondente di exe. Quindi esegui l'applicazione in VS e otterrai una grande quantità di informazioni di caricamento della DLL, inclusi i nomi delle DLL che non vengono caricate nella finestra di output. Nel nostro caso è stato questo:

5038: 34f4 @ 789.320.468 - LdrpProcessWork - ERRORE: Impossibile caricare la DLL: "vccorlib140d_app.DLL", Modulo principale: "E: \ progetti --- \ Source \ Builds \ vs2015_Debug_UWP_x64 \ AppX ---. Exe ", Stato: 0xc0000135

Un altro modo più rapido per testare questo (YMMV) era confrontare l'output con un'altra configurazione di build che funziona. Nel nostro caso, possiamo eseguire le build di rilascio in modo corretto, ma eseguiamo il debug di build barf. E l'output di rilascio mostrava vccorlib140_app.dll caricato mentre mancava il debug.