0

長い時間の研究/研究の結果、私は見つけました

アプリケーションは msvcr90d.dll/msvcp90d.dll -- 9.0.21022.8 を使用する必要がありますが、vs2008 でデバッグすると、常に msvcr90d.dll -- 9.0.30729.6161 が使用されます

STL 標準ベクトル例外 (サードパーティ DLL から) によるアプリのクラッシュの根本的な原因であると思います。vs2008 を使用して自分のマシンでアプリを正常に実行したことがあります。私のアプリに影響を与えた他のアプリに違いありません。

vs2008 を (何度も) 再インストールし、アプリのマニフェスト オプションを調整しましたが、何も変わりませんでした。アプリと一緒にクラッシュしました。（上司へのデモの準備をしている直前にアプリがクラッシュしました...）

私のマシンにもvs2010、vs2012があります。しかし、アプリが既に存在する場合、アプリはこれまで機能していました。アプリがクラッシュする前に覚えている唯一のことは、TeamViewer を使用して自分のマシンにリモート アクセスしたことです... 翌日、悪の日々が始まりました。

アプリの SxS を制御する方法は?

4

1 に答える 1

1

マニフェストで要求する DLL バージョン .21022.8 は、サイド バイ サイド キャッシュにも展開されている発行者ポリシー ファイルを介してリダイレクトされています。これにより、SP1 バージョンといくつかのセキュリティ パッチが適用されます。これは、Microsoft がランタイム DLL のセキュリティ ホールにパッチを適用できる主要なメカニズムです。

1 つ確かなことは、問題の原因が DLL のバージョンではないことです。このサード パーティの DLL が要求しているバージョンには、同じバージョン リダイレクト ルールが適用されます。簡単に確認できます。Debug + Windows + Modules ウィンドウを見て、msvcr90d.dll を探してください。複数がロードされたかどうかが表示され、バージョン番号が表示されます。そして、リリース バージョンの msvcr90.dll に注意してください。両方をプロセスにロードするのは本当に悪いことです。DLL のリリース ビルドにリンクすると発生する可能性があります。

クラッシュを引き起こす標準的な不一致の 1 つは_HAS_ITERATOR_DEBUGGING #defineです。反復子のデバッグは、C++ コレクション クラス オブジェクトのサイズを変更します。DLL がエクスポートされた関数を介してそのようなオブジェクトを公開し、この #define の異なる設定でコンパイルされた場合、これはうまくいきません。公開するオブジェクトのレイアウトが間違っています。サード パーティが DLL をコンパイルしたときに使用したものと同じ設定を使用していることを確認する必要があります。デバッグ ビルドではデフォルトでオンになっているため、プロジェクトの #define を 0 に設定することで簡単に解決できる可能性があります。不明な場合、または設定の変更を希望する場合は、ベンダーにお問い合わせください。また、DLL の境界を越えて C++ オブジェクトを公開することは悪い考えであることを指摘する良い機会でもあります。

于 2013-03-11T13:27:39.380 に答える