Lastlibraryw gibt nullptr zurück und getLasterror () rendite 3221225619 zurück

Question

Die Probleme, die ich hatte, würden zu lange dauern, aber das Problem am scharfen Ende ist:

1. LastlibraryW fällt (Rückgabe nullptr zurück), wenn ein gültiger Pfad gegeben ist.

2. Process Monitor erfasst keine verdächtigen Fehler oder etwas anderes als das Laden der DLL (die sie in einem anderen Kontext kann).

3. Die DLL hat keine Nicht-System-Abhängigkeiten.

4. ... und am schlimmsten von allen, der von getLasterror zurückgegebene Windows -Fehlercode beträgt 3221225619.

Unter der Annahme, dass 3221225619 kein gültiger Fehlercode ist, was könnte so falsch sein, dass Windows nicht einmal einen Fehlercode dafür hat?

BEARBEITEN:

Ich denke, einige Leute wollten mehr Details zum Scheitern selbst:

• Es scheint nicht die Eingabe zu sein - es ist in der Arbeits- und fehlenden Version identisch, und LoadLibraryW hat erfolgreich deklariert. Der aktuelle Eingang hat es hart codiert, was wenig Raum für Fehler lässt.
• Die DLL wird in der Veröffentlichung und dem Anrufcode in Debug zusammengestellt. Ich mache das seit 18 Monaten ohne Probleme, aber du weißt es nie.
• Das Prozessmonitor -Paket meldet etwa 30 interne Vorgänge, die in LoadLibraryW ausgeführt werden, einschließlich CreateFile, LoadImage, Regopenkey. Diese sind identisch Für den Arbeitsanruf und den fehlerhaften Anruf bis hin zu den Größen von Dateien und den Speicherorten.
• Es gibt keine offensichtliche Speicherbeschäftigung im C ++ - Objekt, das sie aufruft, und wie ich bereits sagte, gibt der Prozessmonitor in beiden Fällen die gleiche Basisbildadresse an.
• Der Fehler ist 100% konsistent - gleichzeitig, jedes Mal gleicher Stelle.

Answer 1

Entschuldigung, das ist nicht exakt Eine Antwort, aber das Problem wurde gelöst.

Zunächst habe ich hier gerade eine ähnliche Frage bemerkt: C ++ loadlibrary () Fehler 3765269347. Ich denke, dies gibt mehr Details und ist einen Blick wert, wenn Sie in einer ähnlichen Position wie ich waren.

Mein Dank geht an @whozcraig, @danieldaranas und alle anderen, die hilfreiche Kommentare abgegeben haben. Für andere Leute, die dies lesen, gibt es einen guten Artikel über Hresult, der ihre Punkte auf Wikipedia erweitert: http://en.wikipedia.org/wiki/hresult.

In meinem Fall ist das Problem genauso mysteriös verschwunden wie es entstand. Ich habe eine C ++ - Klasse erstellt, um die DLL regelmäßig aufzurufen. Mein ursprünglicher Aufwand lud die DLL unmittelbar vor dem ersten Anruf und zwischengespeichert sie. Dies ist im Prinzip der gleichen, wie es über ein Jahr lang funktioniert. Dies führte zu dem mysteriösen Fehler oben.

Ich habe es neu gestaltet, um die DLL während der Konstruktion zu laden, um die Funktion jedoch nur zur Laufzeit zu extrahieren. Dies funktioniert anscheinend und ist wahrscheinlich eine bessere Möglichkeit, dies zu tun (laden Sie die DLL während der Bauarbeiten, befreit sie während der Zerstörung). Da zwischen der Konstruktion und dem ersten Aufruf der DLL nur sehr wenig vorhanden ist, kann ich nicht verstehen, warum eine Methode einen OS -Fehler erzeugen sollte, und die andere nicht.