注入されているDLLがホストプロセスをクラッシュさせるのはなぜですか？

Question

私のソフトウェアの新しいリリースのベータテストでは、いくつかのユーザーがアプリの実行中に例外を報告しました。いずれの場合も、「アプリケーションを正しく起動できませんでした（0xc0000142）」。私も0xc0000005と見てきました。私もこのエラーのあるローカルシステムを見つけ、デバッガの下で実行すると "datamngr.dll"にアクセス違反があり、ヒープに割り当てられませんでした。私はすぐに "datamngr.dll"がスパイウェアであり、システムのAppInitのように読み込まれていることを発見しました。

私がAppInitレジストリキーをクリアすると、この問題は解決されました。私はプロセスモニタを介してそれをチェックし、このDLLが注入されていたときはいつでも、私のアプリケーションがクラッシュしました。私はそれがひどく書かれたスパイウェアだと思ったが、私は同じことをしている他のDLL（正当なソフトウェアであるacaptuser32.dllなど）を見つけた。私にとって奇妙なのは、以前のバージョンのソフトウェアがクラッシュしないということです。 2つのバージョンの間には多くの、多くの変更がありましたので、それが何であるか言うのは難しいです。

ここから始めますか？いくつかのオンライン探索では、FirefoxのようなアプリケーションがLoadLibraryを置き換えてブラックリストDLLを注入することを示しています。しかし、より基本的なものから始めたいのですが、アプリケーションが今までになかったときにクラッシュするのはなぜですか？

これは非常に曖昧ですが、それはかなり避けられないことです。私が間違ってやっているプロジェクトのプロパティに明らかなことがあることを願っています。私はASLRのオン、オフ、DEPのオン/オフを試しました...私はuser32.dllの遅延読み込みを試み、手動でLoadLibrary（エラーを無視するように設定されたSetErrorMode）をロードしましたが、何も私のために働いていません。これはWindows XPとWindows 7（32ビットと64ビット）で発生することがわかりました。

どこから始めるべきかについてのご意見をお待ちしております。誰かが他の詳細を必要とするならば、できる限り多くの情報を提供します。

乾杯

Answer 1

修正が見つかりました。私はプロセスモニタを使用して、DLLインジェクタの有無にかかわらず、DLLロードの順序を比較しました。一つ目は、私が打ち負かしたのは、C++のDLLで、.NETをロードする（LoadLibrary経由で）ことが最初に含まれていたことです。 CLRはそのような大きな獣なので、私はそのDLLとすべての.NET DLLを遅延ロードしようと決めました。それだけで済む - 私の問題は消え去った。

Raymond Chenが言ったように、注文は壊れやすいものです。他の人がこの問題に遭遇した場合は、DLLの読み込み順序を調整することをお勧めします。