問題タブ [rebasing]

According to this article rebasing is not necessary for .NET assemblies due to JIT compilation of the code. The article states:

"JIT-compiled code does not have a rebasing problem since the addresses are generated at run time based on where the code is placed in memory. Also, MSIL is rarely affected by base address misses since MSIL references are token-based, rather than address-based. Thus when the JIT compiler is used, the system is resilient to base address collisions."

However, I have noticed that VS2008 assigns the default 0x0400000 base address to all assemblies (project properties > build > advanced) and if I do a listdlls /r for my process all my .NET assemblies are in fact rebased per default.

If I assign addresses myself, no rebasing is done.

My question is: What is rebased in this case and why?

EDIT: I should add that I am not talking about NGen'ed assemblies.

問題のコードは explorer.exe にフックされますが、コールバック関数へのエントリでクラッシュしていました。

コールスタック:

Visual Studio 2005 では、次の逆アセンブリが行われました。

そして0x548B0CC4あたりのメモリはすべて?????? マップされたメモリではないため、クラッシュします。

myCallWndProcRetCallback の開始時のマシン コードは次のとおりです。

ただし、Visual Studio では、この関数に対して次の逆アセンブリが提供される場合もあります。

これは正しい逆アセンブルのように見えますが、上記の逆アセンブルよりも 1 バイト遅れています。0x60055B58 以降の命令は同じであることがわかります。

そのため、リンカは関数が 0x60055B50 にあると言っているように見えますが、コードは実際には 0x60055B51 から始まります。前者は Windows フックに設定されたコールバックであることを確認しました。そのため、Windows が関数にコールバックすると、不正なコードが実行されます。

私が持っている質問は、リンカーがこれをどのように誤解する可能性があるかということです? 再構築を行ったところ、問題はなくなりました。ランダムなようです。/FORCE:MULTIPLE リンカー オプションが有効であった時点で、このコールバックに対してリンク エラーは報告されません。

遅い追加: これは、DLL の再配置またはリベースに関連している可能性がありますか? 再配置が 1 バイトずれていた場合、これが問題の原因になる可能性がありますか?

これはこの質問の続きです。

私は、.NET DLL をリベースするかどうかをテストしている最中です。これらを NGEN 化すると、ターミナル サーバーのメモリ内により多くの共有コードが提供されるようになります。

しかし、私の計画には欠陥があるようで、アドレスの作業セットを把握するための作業方法を見つけることができないようです。

私ができると思ったのは以下のようなものです。

1. すべてをビルドして NGEN にするだけ
2. プログラムを開始し、すべての DLL がロードされていることを確認します
3. LISTDLLS /R PROGRAMNAMEを使用して、実行中のインスタンスの現在使用中のアドレスのリストを取得します
4. これらの DLL の新しいベースアドレスとして再マップされた DLL のアドレスを使用します。
5. すべてを UN-NGEN し、1 からやり直す

ただし、一部の DLL をリベースすると、ロード順序が変更されるか、オペレーティング システムが他の DLL を再配置する方法が明らかに変わるため、これはシュレーディンガーの課題になりました。

たとえば、最初の実行後に、DLL A、B、および C がアドレス 1000、2000、および 3000 にある必要があるというリストがあるとします。DLL の一部でもある DLL D、E、および F については言及されていません同じシステム。おそらく、これらは現在のベースアドレスにロードされていると思われます。そうでなければ、LISTDLLS がそれについて教えてくれると思います。

そこで、A、B、C のアドレスを変更し、すべてを繰り返すと、DLL C、D、および E が再配置されました。A と B は OK になりました。E と F は移動しました。C はまだシャッフルされています。

私のマシンで何を理解しているかに関係なく、DLL が使用され、ターゲットのターミナル サーバーに挿入されると、この図が乱れる可能性があるため、この演習はやや無駄なものであることに気付きましたが、少なくともいくつかのことを確認できればDLL を所定のベース アドレスに配置すると、同じプログラムの複数のインスタンス間で共有されるコードの量が増加します。それを「思い出させる」必要がないように、ただ言っているだけです:)

すべての DLL の元のベース アドレスがデフォルトであったため、すべての DLL (おそらく最初にロードされたものを除く) が再配置され、ページ ファイルにマップされたため、0 を超える潜在的なゲインがあると思います。

何かアドバイス？

要求元の URL に応じて、既存の Web サイトのブランド変更 (ロゴ、色、画像など) を有効にするテーマを実装しています。私はそれを行う方法を理解しており、画像の URL に関連するいくつかの例外を除いて、スキンは正常に機能しています。

具体的には、スキンを適用できないというコントロール プロパティがあります。テーマを実装する前は、次のようになっていました。

明らかに、それはテーマでは機能しません。したがって、多くの試行錯誤と読書の後、私は次のように実装しようとしています:

しかし、それはうまくいきません。生成された html は次のようになります。

正しい方向への指針をいただければ幸いです。

デビッド

C++/CLI を介して C#.NET 2.0 DLL でビルドされたインプット メソッド (IME) プログラムがあります。IME は常に別のアプリケーションに接続しているため、C#.NET DLL はイメージ アドレスのリベースを回避できないようです。

ngen を適用してその C#.NET 2.0 DLL のネイティブ イメージを作成し、グローバル アセンブリ キャッシュにインストールしましたが、あまり改善されず、約 12 秒かかりました。9秒まで。遅い PIII レベルの PC で。

したがって、起動時に C#.NET DLL によって参照されるすべてのコンポーネントをロードする小さなアプリケーションを使用して、その DLL のネイティブ イメージを "ウォームアップ" します。読み込み時間を 0.5 秒に短縮することは問題なく機能します。

しかし、それはしばらくの間しか機能しませんでした。約30分 後で、再び「クールダウン」するようです。

GAC またはネイティブ イメージの動作を常に「ホット」に制御する方法はありますか? これはまさにイメージアドレスのリベースの問題ですか?

私たちのアプリケーションには多くの .NET アセンブリがあり、これまで NGen スクリプトを使用してデプロイされていなかったため、実行時に常に JIT されます。

私たちのアプリケーションは通常、ターミナル サーバーに展開されるため、Windows でコードのバイナリ イメージを共有することがおそらく現在の方法よりも最適であるため、ベース アドレスの設定とアセンブリの NGen 化を検討しています。

そこで、NGen をまったく使用せずにプログラムを実行し、[SysInternals の listdlls][1] を使用してそれぞれのサイズを見つけ、それを次のクラスのサイズ (つまり、xxxx --> 10000) に増やしました。次に、すべてのアセンブリのメモリ リストをレイアウトし、それらすべてのベース アドレスを調整しました。

これまでのところlistdlls、実行時にアセンブリがリベースされていないことがわかりました。

しかし、2 つのインスタンス間で実際に共有されているメモリの量を測定するにはどうすればよいでしょうか? 基本的に、アセンブリで NGEN を実行せずにプログラムの 2 つのインスタンスを開始し、NGEN を実行した後にもう一度実行するとします。

実際の効果を見つけるには、どのような数値をどのツールから見ればよいでしょうか?

たとえば、アセンブリをリベースする行為自体が、使用しているサード パーティのアセンブリ (たとえば、DevExpress コンポーネント) を移動させて、突然リベースしなければならなくなり、すべてがウォッシュになるという事実を認識しています。

では、どこからどの数字を読むのでしょうか? 同様に、タスク マネージャーのワーキング セットを使用しますか? プライベートメモリー？コミットサイズ？前後にメモリを解放しますか？

何かアドバイス？

1つの小さな.exeと3つの小さな.Dllで構成される.net4で実行されている小さなテストソリューションに基づいてDLLをリベースして実験しています。アセンブリ参照は正しく設定されており、プログラムは正常にコンパイルおよび実行されます。

この演習の目的は、リベースがどのように機能するかを調べて、それをngenと結び付け、作業中の大規模なプロジェクトでパフォーマンスを向上させることです。

Dllをリベースするさまざまな方法を試し、VisualStudioモジュールデバッガウィンドウおよびプロセスエクスプローラーであるvmmapを使用して結果を監視しました。これまでのところ成功したものはありません。

1. Dll1.dll、Dll2.dll、Dll3.dllの[ビルド]->[詳細設定]->[DLLベースアドレス]設定をそれぞれ0x41000000、0x42000000、0x43000000に設定しました。これらのアドレスは、各DLLの優先ベースアドレスとして確実に保存されましたが、実行ごとに、DLLはイメージをメモリ内のさまざまな場所に不規則にリベースしました。

2. このアプリケーションを使ってみました。それが生成するログは、DLLが実際に（私が選択した）優先ベースアドレスを組み込んでいることを示していますが、実行時の結果は依然として不安定です

3. ngenを使ってみました。これにより、.niバージョンのDLLが元のDLLと一緒にロードされ、6つすべてのDLLのメモリ位置が、私が要求したものの近くに不規則になります。

4. GACに画像を貼り付けてみました。DllのGACバージョンのみがロードされたのを見るのは心強いものでしたが、それらのメモリ位置は依然として不安定でした。

5. 私は上記のすべての組み合わせのように感じるものを試しました。失敗。

VMMapを使用して実行時に調べてみると、0x10000000と0x50000000の間のアドレス空間に使用可能なメモリの大きなギャップがあることがわかります。したがって、衝突やDLLリベースの必要はありません。DLLも非常に小さく、それらの間に残している0x01000000のギャップは非常に大きいため、互いに衝突しないようにする必要があります。

私は何が欠けていますか？

この演習での私の主な参考資料は、非常に有益なこの記事ですが、2006年に.Net2用に作成されました。当時と現在の間に何か根本的な変化がありましたか？

私はそれが大きな違いを生むことを真剣に疑っていますが、念のために使用しているコードは次のとおりです。

Program.cs：

Class1.cs：

Class2.cs：

Class3.cs：