LoadLibraryW restituisce nullptr e getLasterror () restituisce 3221225619

Question

Descrivere i problemi che ho avuto richiederebbe troppo tempo, ma il problema alla fine è:

1. LoadLibraryW fallisce (restituisce nullptr) quando viene dato un percorso valido.

2. Il monitoraggio del processo non registra errori sospetti, o in effetti qualcosa di diverso da quando riesce a caricare la DLL (che può in un altro contesto).

3. La DLL non ha dipendenze non sistemi.

4. ... e, peggio ancora, il codice di errore di Windows restituito da GetLasterror è 3221225619.

Supponendo che 3221225619 non sia un codice di errore valido, cosa potrebbe andare così male che Windows non ha nemmeno un codice di errore per questo?

MODIFICARE:

Penso che alcune persone abbiano desiderato maggiori dettagli sul fallimento stesso:

• Non sembra essere l'input: è identico nella versione funzionante e in fallimento, e LoadLibraryW ha dichiarato "Il file non esiste" quando la stringa di input è stata mutilata. L'attuale input lo ha codificato, lasciando poco spazio per errori.
• La DLL viene compilata in rilascio e il codice chiamante in Debug. Lo faccio da 18 mesi senza problemi, ma non lo sai mai.
• Il pacchetto di monitoraggio di processo riporta circa 30 operazioni interne in esecuzione all'interno di LoadLibraryW, tra cui CreateFile, LoadImage, Regopenkey. Questi sono identico Per la chiamata di lavoro e la chiamata di fallimento, fino alle dimensioni dei file e delle posizioni di memoria.
• Non esiste un ovvio corruzione della memoria nell'oggetto C ++ che lo chiama e, come ho detto, il Process Monitor fornisce lo stesso indirizzo di immagine di base in entrambi i casi.
• Il fallimento è coerente al 100% - stesso tempo, stesso posto ogni volta.

Answer 1

Scusa, questo non è Esattamente Una risposta, ma il problema è stato risolto.

Per cominciare, ho appena notato una domanda simile qui: Errore C ++ LoadLibrary () 3765269347. Penso che questo fornisca maggiori dettagli e vale la pena dare un'occhiata se sei in una posizione simile a quello che ero.

Grazie a @whozcraig, @danieldaranas e tutti gli altri che hanno fatto commenti utili. Per altre persone che leggono questo, c'è un buon articolo su Hresult che si espande sui loro punti su Wikipedia: http://en.wikipedia.org/wiki/hresult.

Nel mio caso, il problema è andato via misteriosamente quanto è sorto. Ho creato una classe C ++ per chiamare la DLL su base regolare. Il mio sforzo originale ha caricato la DLL immediatamente prima della prima chiamata e l'ha memorizzata nella memoria. Questo è lo stesso in linea di principio a come ha funzionato per oltre un anno. Ciò ha comportato il misterioso errore sopra.

L'ho refactorto per caricare la DLL durante la costruzione, ma per estrarre la funzione da essa solo in fase di esecuzione. Questo apparentemente funziona, ed è probabilmente un modo migliore per farlo (caricando la DLL durante la costruzione, liberandola durante la distruzione). Dato che c'è molto poco da fare tra la costruzione e la prima chiamata alla DLL, non riesco a capire perché un metodo dovrebbe produrre un errore del sistema operativo e l'altro no.