loadlibrarywはnullptrを返し、getLasterRor（）は3221225619を返します

Question

私が抱えてきた問題を説明するには時間がかかりすぎますが、鋭い終わりの問題は次のとおりです。

1. LoadLibraryWは、有効なパスが与えられたときに失敗します（NULLPTRを返します）。

2. プロセスモニターは、疑わしい障害、またはDLLのロードに成功したときとは実際には異なるものを記録しません（別のコンテキストでは）。

3. DLLには非システムの依存関係がありません。

4. ...そして最悪の場合、GetLasterRorによって返されるWindowsエラーコードは3221225619です。

3221225619が有効なエラーコードではないと仮定すると、Windowsにエラーコードさえ持っていないほど間違っている可能性がありますか？

編集：

一部の人々は、失敗自体の詳細を望んでいると思います。

• それは入力ではないようです - それは動作バージョンと故障バージョンで同一であり、LoadLibraryWは入力文字列が切断されたときに「ファイルが存在しない」と正常に宣言しています。現在の入力にはハードコーディングがあり、エラーの余地はほとんどありません。
• DLLはリリースでコンパイルされ、デバッグの呼び出しコードがコンパイルされます。私はこれを問題なく18か月間行ってきましたが、あなたは決して知りません。
• プロセスモニターパッケージは、CreateFile、LoadImage、Regopenkeyなど、LoadLibraryW内で実行されている約30の内部操作を報告しています。これらは 同一 作業コールと失敗の呼び出しの場合、ファイルとメモリの場所のサイズまで。
• C ++オブジェクトにそれを呼び出す明らかなメモリの腐敗はありません。私が言ったように、プロセスモニターはどちらの場合も同じベース画像アドレスを提供します。
• 失敗は100％一貫しています - 同時に、毎回同じ場所。

Answer 1

申し訳ありませんが、これはそうではありません まさに 答えですが、問題は解決されました。

まず、ここで同様の質問に気づきました。 C ++ loadLibrary（）エラー3765269347. 。これはさらに詳細を提供していると思います。あなたが私と同じような立場にあるなら、見る価値があります。

@whozcraig、@danieldaranas、そして有益なコメントをしてくれた他のすべての人に感謝します。これを読んでいる他の人にとって、ウィキペディアでのポイントを拡張するHRESULTに関する良い記事があります。 http://en.wikipedia.org/wiki/hresult.

私の場合、問題はそれが生じたのと同じくらい神秘的に消えてしまいました。定期的にDLLを呼び出すためにC ++クラスを作成しました。私の当初の努力は、最初の呼び出しの直前にDLLをロードし、それをメモリでキャッシュしました。これは、原則として、1年以上にわたってどのように機能しているかについて同じです。これにより、上記の神秘的なエラーが発生しました。

建設中にDLLをロードするようにリファクタリングしましたが、実行時に機能を抽出するためだけに抽出しました。これは明らかに機能し、おそらくそれを行うより良い方法です（建設中にDLLをロードし、破壊中に解放します）。構造とDLLへの最初の呼び出しの間にはほとんど進行していないため、1つのメソッドがOSエラーを生成する理由がわかりません。