[DotNetBook]ストリームスタック。 その編集とストリームクローン

この記事では、引き続き一連の記事を公開します。その結果、.NET CLRおよび.NET全般の作業に関する本になります。 本全体がGitHubで利用可能になります（記事の最後のリンク）。 したがって、問題とプルリクエストはいつものように歓迎されます:)

会話がほとんど発生しないメモリ領域があります。 ただし、この領域はおそらくアプリケーションの操作における主要な領域です。 最も一般的に使用されるもので、インスタント割り当てとメモリの解放が非常に制限されています。 この領域は「ストリームスタック」と呼ばれます。 さらに、それへのポインタは、ストリームのコンテキストに入るプロセッサレジスタによって本質的にエンコードされるため、ストリームの実行内でストリームスタックは独自のものになります。 なぜ必要なのですか？ DOSプログラムからWindows 10上にインストールされた.NET Frameworkまで、すべてが機能する基礎に基づいて、低レベル構造の世界に突入しましょう。

それでは、基本的なコードの例を分析しましょう。

void Method1() { Method2(123); } void Method2(int arg) { // ... } 

このコードでは注目すべきことは何も起こりませんが、通過させませんが、その逆も同様です。できる限り詳しく調べます。

ご注意

Habréで公開されている章は更新されておらず、おそらくすでに古いものです。 そのため、最新のテキストについては元に戻してください。

• CLR Book： GitHub、目次
• CLR Book： GitHub、章
• リリース0.5.2の書籍、PDF： GitHubリリース

`Method1`がany` Method2`を呼び出すと、そのような呼び出しはすべて（.NETだけでなく、他のプラットフォームでも）次の操作を実行します。

1. JITによってコンパイルされたコードが最初に行うことは、メソッドパラメーターをスタックに保存することです（3番目から開始）。 この場合、最初の2つはレジスタを介して送信されます。 インスタンスメソッドの最初のパラメーターは、メソッドが動作するオブジェクトにポインターを渡すことを覚えておくことが重要です。 すなわち ポインター `this`。 そのため、これらの（ほとんどすべての）場合、レジスターにはパラメーターが1つだけ残ります。 そして、他の皆のために-スタック;
2. 次に、コンパイラは「call」メソッドを呼び出す命令をプッシュし、メソッドからのリターンアドレスをスタックにプッシュします。「call」命令に続くアドレスです。 したがって、メソッドは呼び出し元のコードが機能し続けることができるように、どこに戻る必要があるかを知っています。
3. すべてのパラメーターが渡され、メソッドが呼び出された後、スタックで占有されているバイトをカウントすることを気にしたくない場合は、メソッドを終了する場合にスタックを復元する方法を何らかの方法で理解する必要があります。 これを行うために、EBPレジスタの値を保存します。これは、現在のフレームフレーム（つまり、呼び出された特定のメソッドの情報が保存されているセクション）の先頭へのポインターを常に保存します。 このレジスタの値を各呼び出しで保存することにより、スタックフレームの単純に接続されたリストを実際に作成します。 しかし、実際にはスペースなしで次々とはっきりと移動することに注意してください。 ただし、フレームの下からのメモリの解放を簡素化し、アプリケーションをデバッグできるようにするために（デバッガはこれらのポインタを使用してスタックトレースを表示します）、単一リンクリストが作成されます。
4. メソッドを呼び出すときに最後に行うことは、ローカル変数にメモリを割り当てることです。 コンパイラーは必要な量を事前に知っているため、必要なバイト数だけポインターをスタックの最上部（SP / ESP / RSP）に移動してすぐに実行します。
5. 最後に、5番目の段階で、メソッドコードが実行され、便利な操作が行われます。
6. メソッドが終了すると、スタックの最上部がEBP（現在のスタックフレームの先頭が保存されている場所）から復元されます。
7. 次に、最後のステップは `ret`ステートメントを介してメソッドを終了することです。 それは、スタックから「呼び出し」命令によって以前に慎重に残された戻りアドレスを取り去り、このアドレスに移行します。

同じプロセスを画像で見ることができます：



また、スタックは最上位アドレスから最下位アドレスへと「成長」することに注意してください。 反対方向に。

これをすべて見てみると、大部分ではない場合、プロセッサが行っているすべての操作の少なくとも半分は、ペイロードではなくプログラム構造のメンテナンスであるという結論に、あなたは思わず思いつきます。 すなわち メソッド呼び出しのサービス、型を相互に導く能力のチェック、一般的なバリエーションのコンパイル、インターフェイステーブルでのメソッドの検索...特に、最新のコードがインターフェイスを介して動作し、独自のメソッドを実行する多くの小さなメソッドに分割されていることを思い出す場合...また、基本的な型とインターフェイスまたは相続人への型キャストを同時に行うことがよくあります。 これらのすべての新しい条件により、インフラストラクチャコードの無駄に関する結論は十分に成熟する可能性があります。 これについて私に言えることは、JITを含むコンパイラには、より生産的なコードを作成できる多くのテクニックがあります。 可能な場合-メソッドを呼び出す代わりに、その本体全体が挿入され、可能であれば、VSDインターフェイスでメソッドを検索する代わりに、直接呼び出しが行われます。 悲しいことに、インフラストラクチャの負荷を測定するのは非常に困難です。インフラストラクチャコードの作業場所の前後にJITterまたはコンパイラが何らかのメトリックを挿入する必要があります。 すなわち メソッドが呼び出される前、およびスタックフレームの初期化後のメソッド内。 メソッドを終了する前、メソッドを終了した後。 コンパイル前、コンパイル後。 などなど。 しかし、悲しいことについて話すのではなく、受け取った情報を使って何ができるかについて話しましょう。

例外について少し

メソッドコードの内部を見ると、ストリームスタックで機能する別の構造に気付くでしょう。 自分で判断する：

 void Method1() { try { Method2(123); } catch { // ... } } void Method2(int arg) { Method3(); } void Method3() { try { //... } catch { //... } } 

`Method3`から呼び出されたメソッドのいずれかで例外が発生した場合、制御は` Method3`メソッドの `catch`ブロックに返されます。 さらに、例外が処理されない場合、その処理はメソッド `Method1`で開始されます。 しかし、何も起こらない場合、 `Method3`は作業を完了し、制御はメソッド` Method2`に渡され、例外も発生する可能性があります。 ただし、自然な理由により、「Method3」ではなく「Method1」で処理されます。 このような便利な自動化の問題は、例外ハンドラーのチェーンを形成するデータ構造が、それらが宣言されているメソッドのスタックフレームにもあることです。 例外自体については個別に説明しますが、ここでは、.NET Framework CLRとCore CLRの例外モデルが異なるとだけ言います。 CoreCLRは異なるプラットフォームで異なるように強制されるため、例外モデルは異なり、異なる実装のPAL（Platform Adaption Layer）レイヤーを介してプラットフォームに応じて表示されます。 大規模な.NET Framework CLRはこれを必要としません。Windowsプラットフォームのエコシステムに存在し、長年にわたってSEH（構造化例外処理）と呼ばれる有名な例外処理メカニズムが存在していました。 このメカニズムは、さまざまなプログラミング言語で記述されたモジュール間のエンドツーエンドの例外処理を提供するため、ほぼすべてのプログラミング言語（最終コンパイル用）で使用されます。 次のように機能します。

1. tryブロックに入ると、最初のフィールドが前の例外処理ブロック（たとえば、try-catchもある呼び出しメソッド）、ブロックタイプ、例外コード、およびハンドラーアドレスを指す構造がスタックに配置されます。
2. スレッドのTEB（スレッド環境ブロック、本質的にはスレッドのコンテキスト）では、例外ハンドラーのチェーンの現在のトップのアドレスが、作成したものに変更されます。 したがって、ブロックをチェーンに追加しました。
3. tryが終了すると、逆の操作が実行されます。古い頂点がTEBに書き込まれるため、ハンドラーがチェーンから削除されます。
4. 例外が発生した場合、頂点がTEBから取得され、次に、チェーン内でハンドラーが呼び出され、例外がそれらに特に適しているかどうかを確認します。 その場合、処理ブロックが実行されます（catchなど）。
5. TEBでは、例外を処理したメソッドの前にスタック上にあるSEH構造のアドレスが復元されます。

ご覧のとおり、難しいことではありません。 ただし、これらの情報はすべてスタック上にもあります。

スレッドスタックの不完全性について

セキュリティの問題と、理論的に発生する可能性のある問題について少し考えてみましょう。 これを行うために、基本的に通常の配列であるストリームスタックの構造をもう一度見てみましょう。 フレームが構築されるメモリ範囲は、端から端まで成長するように編成されます。 すなわち 後のフレームは前のアドレスに配置されます。 また、すでに述べたように、フレームは単一のリンクリストで接続されています。 これは、フレームサイズが固定されておらず、デバッガーによって「読み取られる」必要があるためです。 同時に、プロセッサはフレームを区別しません。必要に応じて、どのメソッドでもメモリ領域全体を読み取ることができます。 そして、実際にメモリが割り当てられているセクションに分割されている仮想メモリにいることを考慮すると、スタックの任意のアドレスで特別なWinAPI関数を使用して、この '' csharpアドレスが配置されている割り当てられたメモリの範囲を取得できます さて、単一リンクリストを整理することは技術の問題です：

  //     int x; //     ,    MEMORY_BASIC_INFORMATION *stackData = new MEMORY_BASIC_INFORMATION(); VirtualQuery((void *)&x, stackData, sizeof(MEMORY_BASIC_INFORMATION)); 

これにより、呼び出したメソッドのローカル変数としてのすべてのデータを取得および変更できます。 アプリケーションがサンドボックスを何らかの方法で構成しない場合、アプリケーションの機能を拡張するサードパーティライブラリが呼び出されるフレームワーク内で、サードパーティライブラリは、提供するAPIがこれを意味しない場合でもデータを盗むことができます。 この手法は、あなたにとってはとんでもないように思えるかもしれませんが、スタックに攻撃権限が設定されたAppDomainのような美しいものがないC / C ++の世界では、これがハッキングアプリケーションから見られる最も典型的なものです。 それだけでなく、リフレクションを介して必要なタイプを確認し、自宅でその構造を繰り返し、スタックからオブジェクトへのリンクをたどって、VMTアドレスを私たちのものに置き換え、特定のインスタンスのすべての作業を私たちにリダイレクトします。 ところで、SEHはアプリケーションのハッキングにも使用されています。 また、例外ハンドラのアドレスを変更して、OSに悪意のあるコードを実行させることもできます。 しかし、これらすべての結論は非常に簡単です。アプリケーションの機能を拡張するライブラリを使用する場合は、常にサンドボックスを構成してください。 もちろん、あらゆる種類のプラグイン、アドオン、その他の拡張機能を意味します。

素晴らしい例：ストリームクローニング

読んだ内容すべてを細部まで覚えるには、いくつかの側面からトピックを取り上げるという問題に取り組む必要があります。 ストリームスタックに対してどのような例を構築できるのでしょうか。 別のメソッドを呼び出しますか？ マジック...もちろんそうではありません。1日に何度もこれを行います。 代わりに、実行のフローを複製します。 すなわち 1つのスレッドの代わりに特定のメソッドを呼び出した後、2つのスレッドを作成できるようにしましょう：私たちのスレッドと新しいスレッドの2つですが、クローンメソッドの呼び出し時点からコードを実行し続けます。 そして、次のようになります。

 void MakeFork() { //         : //              var sameLocalVariable = 123; var sync = new object(); //   var stopwatch = Stopwatch.StartNew(); //   var forked = Fork.CloneThread(); //       . // forked = true   , false   lock(sync) { Console.WriteLine("in {0} thread: {1}, local value: {2}, time to enter = {3} ms", forked ? "forked" : "parent", Thread.CurrentThread.ManagedThreadId, sameLocalVariable, stopwatch.ElapsedMilliseconds); } //         , //   MakeFork(), ..        , //    . } //  : // in forked thread: 2, local value: 123, time to enter = 73 ms // in parent thread: 1, local value: 123, time to enter = 77 ms 

同意し、コンセプトは興味深いです。 もちろん、このようなアクションの適切性については多くの議論がありますが、この例のタスクは、このデータ構造の操作の理解に弾丸を置くことです。 クローン作成方法 この質問に答えるには、別の質問に答える必要があります。一般的にフローを決定するものは何ですか？ また、フローは次のデータ構造と領域によって決定されます。

• プロセッサレジスタのセット。 すべてのレジスタは、命令実行ストリームの状態を決定します。現在の実行命令のアドレスから、ストリームスタックのアドレスおよびそれが動作するデータまで。
• [スレッド環境ブロック]（https://en.wikipedia.org/wiki/Win32_Thread_Information_Block）またはTIB / TEB。例外ハンドラーのアドレスを含むシステム情報をスレッドごとに保存します。
• レジスタSS：ESPによってアドレスが決定されるストリームのスタック。
• ストリームのプラットフォームコンテキスト。ストリームのローカルデータを含みます（リンクはTIBから取得されます）

まあ、確かに私たちが知らないかもしれない何か。 はい。たとえば、すべてを知る必要はありません。このコードは産業用にはなりませんが、トピックを理解するのに役立つ優れた例として役立ちます。 したがって、彼はすべてを考慮せず、最も基本的なものだけを考慮します。 そして、それが基本的な形で機能するためには、レジスタのセットを新しいストリームにコピーする必要があります（SSはESPを修正することで、スタックが新しくなるため）。また、スタック自体を編集して、必要なものが正確に含まれるようにします。

だから。 フロースタックが、どのメソッドが呼び出され、どのデータを操作するかを本質的に決定する場合、これらの構造を変更することで、メソッドのローカル変数がメソッドをスタックから切断する方法を変更したり、メソッドを別のメソッドに変更したり、追加したりできることがわかりますチェーン内の任意の場所。 さて、これに決めました。 次に、いくつかの擬似コードを見てみましょう。

 void RootMethod() { MakeFork(); } 

MakeFork（）が呼び出されたとき、トレースのスタックに関して何を期待しますか？ 親スレッドのすべてが変更されずに残り、子がスレッドプールから（速度のために） MakeForkれ、ローカル変数とともにMakeForkメソッドの呼び出しをシミュレートし、コードはメソッドの最初からではなく、呼び出しに続くポイントから実行されますCloneThread 。 すなわち ファンタジーのスタックトレースは次のようになります。

 // Parent Thread RootMethod -> MakeFork // Child Thread ThreadPool -> MakeFork 

最初は何がありますか？ ストリームがあります。 また、そこでコードを実行して、新しいスレッドを作成したり、スレッドプールでタスクをスケジュールしたりすることもできます。 また、ネストされた呼び出しに関する情報は呼び出しスタックに格納され、必要に応じて操作できることも理解しています（たとえば、C ++ / CLIを使用）。 さらに、規則に従って、スタックの最上部にあるret命令のリターンアドレス、EBPレジスタの値を入力し、ローカルにスペースを割り当てる（必要な場合）ことにより、メソッド呼び出しをシミュレートできます。 C＃からストリームスタックに手動で書き込むことは可能ですが、それらを非常に慎重に使用するためにレジスタが必要になるため、C ++のままにしておくことはできません。 ここで私の人生で初めて（個人的には）CLI / C ++が助けになり、混合コードを書くことができます：命令の一部は.NETにあり、一部はC ++にあり、時にはアセンブラレベルにさえなります。 まさに必要なもの。

コードがMakeForkを呼び出すと、スレッドスタックはどのようになりますか？MakeForkはCloneThreadを呼び出し、CloneThreadはアンマネージCLI / C ++の世界に入り、クローンメソッド（実装自体）を呼び出します-そこに？ スキームを見てみましょう（スタックが最上位アドレスから最下位アドレスに成長することを思い出します。右から左へ）。



シート全体をスキームからスキームにドラッグしないようにするために、不要なものを破棄して単純化します。



スレッドを作成するか、スレッドプールから準備が整ったスレッドを取得すると、スキームにまだ初期化されていない別のスタックが表示されます。



ここでのタスクは、新しいスレッドでFork.CloneThread()メソッドの開始をシミュレートすることです。 これを行うには、スレッドスタックの最後に一連のフレームを追加する必要があります：ThreadPoolに渡されたデリゲートからFork.CloneThread()が呼び出され、そこからC ++マネージラッパーコードのラッパーを介してCLI / C ++メソッドが呼び出されました。 これを行うには、スタックの必要なセクションをアレイにコピーするだけです（フレームチェーンの構築を提供するEBPレジスタのコピーは、傾斜したセクションから古いセクションに「見える」ことに注意してください）。



さらに、前の山に傾斜したセクションのコピー操作後のスタックの整合性を確保するために、「EBP」フィールドのアドレスが新しい場所にあるアドレスを事前に計算し、すぐにコピー上で直接修正します。



最後のステップでは、非常に慎重に、最小限のレジスタを使用して、子ストリームのスタックの最後に配列をコピーし、その後、ESPおよびEBPレジスタを新しい場所にシフトします。 スタックの観点から、これらすべてのメソッドの呼び出しをシミュレートしました。



しかし、まだコードに関してはそうではありません。 コードの観点から、作成したばかりのメソッドに入る必要があります。 最も簡単な方法は、メソッドから抜け出す方法を単純にシミュレートすることです： ESPをEBPに復元し、 EBPでポイントするものを入れてretステートメントを呼び出し、ストリームクローニングのC ++メソッドと呼ばれるはずのC ++メソッドからの出口を開始します。 MakeFork()制御を返しますが、子スレッド内にあります。 テクニックはうまくいきました。

それでは、コードを見てみましょう。 最初に行うことは、CLI / C ++コードが.NETストリームを作成する機能です。 これを行うには、.NETで作成する必要があります。

 extern "C" __declspec(dllexport) void __stdcall MakeManagedThread(AdvancedThreading_Unmanaged *helper, StackInfo *stackCopy) { AdvancedThreading::Fork::MakeThread(helper, stackCopy); } 

パラメータの種類についてはまだ注意を払っていません。 これらは、スタックのどの部分を親ストリームから子ストリームに描画する必要があるかに関する情報を転送するために必要です。 スレッド作成メソッドは、デリゲートでアンマネージメソッドへの呼び出しをラップし、データを転送し、スレッドプールによる処理のためにデリゲートをキューに入れます。

 [MethodImpl(MethodImplOptions::NoInlining | MethodImplOptions::NoOptimization | MethodImplOptions::PreserveSig)] static void MakeThread(AdvancedThreading_Unmanaged *helper, StackInfo *stackCopy) { ForkData^ data = gcnew ForkData(); data->helper = helper; data->info = stackCopy; ThreadPool::QueueUserWorkItem(gcnew WaitCallback(&InForkedThread), data); } [MethodImpl(MethodImplOptions::NoInlining | MethodImplOptions::NoOptimization | MethodImplOptions::PreserveSig)] static void InForkedThread(Object^ state) { ForkData^ data = (ForkData^)state; data->helper->InForkedThread(data->info); } 

そして最後に、クローン作成方法自体（または、.NET部分）：

 [MethodImpl(MethodImplOptions::NoInlining | MethodImplOptions::NoOptimization | MethodImplOptions::PreserveSig)] static bool CloneThread() { ManualResetEvent^ resetEvent = gcnew ManualResetEvent(false); AdvancedThreading_Unmanaged *helper = new AdvancedThreading_Unmanaged(); int somevalue; // * helper->stacktop = (int)(int *)&somevalue; int forked = helper->ForkImpl(); if (!forked) { resetEvent->WaitOne(); } else { resetEvent->Set(); } return forked; } 

このメソッドがスタックのフレームチェーンのどこにあるかを理解するために、自分用にスタック変数（*）のアドレスを保存します。 このアドレスは、以下で説明するクローン作成方法で使用します。 また、何が問題なのかを理解できるように、スタックコピーに関する情報を保存するために必要な構造のコードを示します。

 public class StackInfo { public: //    int EAX, EBX, ECX, EDX; int EDI, ESI; int ESP; int EBP; int EIP; short CS; //    void *frame; //   int size; //     , //           int origStackStart, origStackSize; }; 

: . — — , , .

. すなわち . それでは始めましょう。 Fork.CloneThread() , ( debugger assistants). .NET : C++ : .

 int AdvancedThreading_Unmanaged::ForkImpl() { StackInfo copy; StackInfo* info; 

, - . , `goto` `CloneThread` . « » `JmpPointOnMethodsChainCallEmulation` : « » 0.

  // Save ALL registers _asm { mov copy.EAX, EAX mov copy.EBX, EBX mov copy.ECX, ECX mov copy.EDX, EBX mov copy.EDI, EDI mov copy.ESI, ESI mov copy.EBP, EBP mov copy.ESP, ESP // Save CS:EIP for far jmp mov copy.CS, CS mov copy.EIP, offset JmpPointOnMethodsChainCallEmulation // Save mark for this method, from what place it was called push 0 } 

, `JmpPointOnMethodsChainCallEmulation` : `0`? , : `NonClonned`. `0`, `1`, «» , `1` goto ( goto ). `CloneThread` , .

 JmpPointOnMethodsChainCallEmulation: _asm { pop EAX cmp EAX, 0 je NonClonned pop EBP mov EAX, 1 ret } NonClonned: 

, , . , . EBP: «Next» . , , . , . managed CloneThread : . , .

  int *curptr = (int *)copy.EBP; int frames = 0; // // Calculate frames count between current call and Fork.CloneTherad() call // while ((int)curptr < stacktop) { curptr = (int*)*curptr; frames++; } 

managed CloneThread , CloneThread MakeFork . MakeFork ( ), : *(int *)curptr . .

  // // We need to copy stack part from our method to user code method including its locals in stack // int localsStart = copy.EBP; // our EBP points to EBP value for parent method + saved ESI, EDI int localsEnd = *(int *)curptr; // points to end of user's method's locals (additional leave) byte *arr = new byte[localsEnd - localsStart]; memcpy(arr, (void*)localsStart, localsEnd - localsStart); 

, — , . , . , :

  // Get information about stack pages MEMORY_BASIC_INFORMATION *stackData = new MEMORY_BASIC_INFORMATION(); VirtualQuery((void *)copy.EBP, stackData, sizeof(MEMORY_BASIC_INFORMATION)); // fill StackInfo structure info = new StackInfo(copy); info->origStackStart = (int)stackData->BaseAddress; info->origStackSize = (int)stackData->RegionSize; info->frame = arr; info->size = (localsEnd - localsStart); // call managed ThreadPool.QueueUserWorkitem to make fork MakeManagedThread(this, info); return 0; } 

: . , , . , MakeFork , , , .

 void AdvancedThreading_Unmanaged::InForkedThread(StackInfo * stackCopy) { StackInfo copy; 

MakeFork . . SS:ESP .

  short CS_EIP[3]; // Save original registers to restore __asm pushad // safe copy w-out changing registers for(int i = 0; i < sizeof(StackInfo); i++) ((byte *)&copy)[i] = ((byte *)stackCopy)[i]; // Setup FWORD for far jmp *(int*)CS_EIP = copy.EIP; CS_EIP[2] = copy.CS; 

— EBP , . , .

  // calculate ranges int beg = (int)copy.frame; int size = copy.size; int baseFrom = (int) copy.origStackStart; int baseTo = baseFrom + (int)copy.origStackSize; int ESPr; __asm mov ESPr, ESP // target = EBP[ - locals - EBP - ret - whole stack frames copy] int targetToCopy = ESPr - 8 - size; // offset between parent stack and current stack; int delta_to_target = (int)targetToCopy - (int)copy.EBP; // offset between parent stack start and its copy; int delta_to_copy = (int)copy.frame - (int)copy.EBP; 

.

  // In stack copy we have many saved EPBs, which where actually one-way linked list. // we need to fix copy to make these pointers correct for our thread's stack. int ebp_cur = beg; while(true) { int val = *(int*)ebp_cur; if(baseFrom <= val && val < baseTo) { int localOffset = val + delta_to_copy; *(int *)ebp_cur += delta_to_target; ebp_cur = localOffset; } else break; } 

, . . , . . .

  CHECKREF(EAX); CHECKREF(EBX); CHECKREF(ECX); CHECKREF(EDX); CHECKREF(ESI); CHECKREF(EDI); 

, . , MakeFork ( return ). . MakeFork . RestorePointAfterClonnedExited , call , EBP , . `push` , `MakeFork` . !

  // prepare for __asm nret __asm push offset RestorePointAfterClonnedExited __asm push EBP for(int i = (size >> 2) - 1; i >= 0; i--) { int val = ((int *)beg)[i]; __asm push val; }; 

, .

  // restore registers, push 1 for Fork() and jmp _asm { push copy.EAX push copy.EBX push copy.ECX push copy.EDX push copy.ESI push copy.EDI pop EDI pop ESI pop EDX pop ECX pop EBX pop EAX 

0 0 . 1 jmp ForkImpl . , . , ForkImpl MakeFork , , RestorePointAfterClonnedExited , .. `MakeFork` . « TheadPool», , .

  push 1 jmp fword ptr CS_EIP } RestorePointAfterClonnedExited: // Restore original registers __asm popad return; } 

? — :



:



, MakeFork . — .

, 4 . . , . . ? 4 . , , . , : .. 2 . , : 1 , 1 .

, : ESP . , , , StackOverflowException: ( ), , Guard Page, , StackOverflow , .NET, StackOverflowException .NET .

, : . . すなわち API API - . .

• CLR Book: GitHub
• 0.5.0 , PDF: GitHub Release