Come è possibile trovare l'origine di "Una procedura importata da" xxx.dll "non può essere caricata." eccezione?

Question

Ho seguito questa eccezione per la scorsa settimana.

situazione è:

Ho un'applicazione che è scritto in C# e costruito in Visual Studio 2010. L'applicazione include una DLL che è un involucro di una libreria di codice non gestito. Il codice non gestito è scritto in C++ e integrato in Visual Studio 2008. Questo è necessario perché il codice fa riferimento a librerie aggiuntive (Qt) e il codice target a WinCE versione 5 (necessario a causa di dispositivi supportati nel campo).

Ho provato molti dei suggerimenti che ho visto qui, incluso l'utilizzo di vari walker dipendenti (VS 2008 dipende, dependency_walker e Dependz) e altri strumenti come Reflector e Process Monitor di SysInternals.

Tutti gli strumenti non mostrano alcun problema (Reflector) o vecchie dipendenze che sono obsolete nel mio ambiente (Win 7) come DCOMP.DLL, GPSVC.DLL, & IESHIMS.DLL.

Nel debugger, posso scorrere il mio codice fino a quando non istanzia un oggetto che fa riferimento alla mia DLL Managed Wrapper. Non entra nell'istanza dell'oggetto, ma lancia immediatamente l'eccezione.

In Process Explorer (da SysInternals) È possibile visualizzare la DLL gestita caricata, insieme alle DLL sussidiarie necessarie. In Process Monitor (da SysInternals) al punto del problema non ci sono pile di messaggi non trovati. Fallisce

Qualsiasi idea o idea per trovare questo problema sarebbe apprezzata.

Answer 1

@Hans Passat - Grazie per il suggerimento su Global Flags.

Here è un eccellente post sul blog sull'utilizzo degli strumenti. Il programma gflags.exe a cui fa riferimento la maggior parte dei riferimenti Google a "Mostra stack caricatore" fa parte del kit di sviluppo driver di Windows (WinDDK) e gestisce le impostazioni del Registro di sistema citate in questo post.

L'output dell'esecuzione con "Mostra stack caricatore" ha identificato che un simbolo che avrebbe dovuto essere nella DLL non gestita non era nella DLL che stavo usando.

Si scopre che stavo creando la versione errata della DLL. Ciò era dovuto alla mia scarsa comprensione del processo di compilazione (troppe versioni costruite troppi modi diversi).

Answer 2

strumento standard per il lavoro: Dependency Walker