既にホットパッチ適用済みの関数に誰かがホットパッチを適用しようとしたら

過去数日間、ホットパッチの仕組みについて簡単な調査を行いました。しかし、ホットパッチの設計は単一のホットパッチャーのみを想定しています。もし誰かが関数にホットパッチを適用しようとして、それが既にホットパッチ適用済みであることに気づいた場合、どうなるのでしょうか？ もし誰かが関数にホットパッチを適用しようとして、それが既にホットパッチ適用済みであることに気づいた場合、それは何かが間違っていることを意味します。ホットパッチの想定される対象は、ホットパッチをサポートするシステム上のWindows Updateです（現時点では、私の知る限り、Windows Serverと最近ではWindows 11 Enterpriseです）。その考え方は、Windows Updateが到着し、管理者がホットパッチをオプトインしており、アップデート内のファイルが「ホットパッチ可能」とマークされている場合¹、Windows Updateはホットパッチのために予約された領域を使用して、影響を受ける関数をオンザフライで置き換えるというものです。ホットパッチ領域を使用することが許可されているコードはWindows Updateのみであるため、システムは関数が既に他の誰かによってホットパッチ適用済みであるというケースに対処する必要がありません。他の誰かが許可されているコードは存在しないのです！ しかし、関数が許可されていない誰かによってデツアーされたり、その他の方法でパッチされたりした場合はどうなるでしょうか？ホットパッチのコードを読むと、ホットパッチコードが不正なパッチを検出した場合、そのファイルをホットパッチ不可能と宣言し、システムは再起動が必要になるとのことです。（これは顧客を不満にさせる傾向があります。） 競合状態が存在します。プリスキャンではすべての関数がパッチ可能と表示されるかもしれませんが、プリスキャンが完了した後に誰かが関数をパッチする可能性があります。その場合、パッチャーは途中で停止し、不正にパッチされた関数を発見し、身動きが取れなくなります。前進することもできず、確実にロールバックすることもできません（ロールバックもおそらくパッチが上書きされたために失敗するでしょう）。メモリ内には半パッチ状態のバイナリが残り、何が起こるかは誰にもわかりません。 ホットパッチ領域を使用するアプリケーションは、火災区域に駐車しているようなものです。消防車が到着するまで全て順調に見えますが、その後、消防車がそこに行けないために誰かの家が全焼してしまいます。 関連資料: アプリケーション互換性レイヤーは、プログラムのためではなく、顧客のために存在します。 ¹すべての変更がホットパッチ可能というわけではありません。例えば、データ構造のレイアウトや不変条件を変更する場合、ホットパッチ可能ではありません。なぜなら、ホットパッチ前に作成されたデータ構造のインスタンスは、ホットパッチ後に有効な状態ではなくなるからです。 私は、3回に1回のアップデートインストールには再起動が必要であるというハード要件があると考えています。これは文脈上理にかなっていますね。3回に1回、はい。 もしその「他の誰か」が、しばらく前のWindows Updateだったらどうなりますか？これは、Windowsが同じファイルに対して2つのアップデートをホットパッチしないという意味でしょうか？ 私は、Windows Updateが自身をうまく処理すると確信しています。これには2つの方法が考えられます。 1) Windows Updateは、パッチ履歴を確認し、ジャンプターゲットを更新することで、自分がパッチャーであることを認識します。 2) Windows Updateは、それが使用する形式であるかどうか（そしてオプションでジャンプターゲットがパッチ予約領域への妥当なポインタであるかどうか）をチェックし、ジャンプターゲットを更新します。 今予言しますが、やがてあなたは、アプリケーションが他のアプリに「付加価値」を注入するためにホットパッチを（誤）使用することによって引き起こされるクラッシュのデバッグに関する投稿を書くことになるでしょう。 2026年10月6日 なぜコンパイラは実行されないコードに対して、時にはud2を、時にはint 3を使用するのでしょうか？ レイモンド・チェン