基本的には r さんの発言に同意。
> 無理がないとは言い切れないですね。
> タスクマネージャをどうにかしようなんて危ういことは避けたほうが無難。
> （何とかなりそうな気はするけど...）

まずは、適当な別のタブ付きダイアログで試すのが、切り分けの意味でも安全だとは思いますが。

＞ITO さん
# DLL の用途を限定するのは、定石的な正攻法という意味で正しい面もあると思いますが、
# DLL のポテンシャル自体はもっと高く広いものですし、インジェクションしてるような
# コードでそれを論じてもあまり意味がない気がします。

CreateDialog が失敗するのでしたら、
GetLastError() で何かわかりませんか？

TCN_SELCHANGEよりも前に発生するであろう、
TCN_SELCHANGINGでも騙しておかないと駄目かもしれない。

その他にもいろいろ障壁はあるかもしれない。
追加ダイアログから親ウィンドウへ送られるメッセージ類
（WM_INITDIALOGなど）は放っておいても大丈夫なんだろうかとか、
他のダイアログをShowWindowなどで操作することで内部矛盾が生じて
癇癪起こしたりしないんだろうかとか。
騙したい相手が画面をどのように管理してるのかわからないのだから、
どうすれば間違いなく動くのかという確証も決して得られはしないと思われ。

＃DLLインジェクションはシェル拡張みたいに公式な手法ではなく
＃騙しの手法だから、「良い子は真似をしないでね」の世界。
＃なので、アドバイス可能なのもせいぜいこの程度。
＃その先は何があろうと自力で何とかするご覚悟を。

みなさんアドバイスありがとうございます
やはりかなり難しいですね。。。
また進展がありましたら書き込みますのでよろしくお願いします

># DLL の用途を限定するのは、定石的な正攻法という意味で正しい面もあると思います
が、
># DLL のポテンシャル自体はもっと高く広いものですし、インジェクションしてるよう
な
># コードでそれを論じてもあまり意味がない気がします。
そうですね、DLLというとライブラリーという観点に立ってしまってまずいですね。
そういえば、共有プロセスの件の時もDLL使ってましたね。

DLL_PROCESS_ATTACH 内で CreateDialog() を実行しているので、
ダイアログ作成は LoadLibrary() を呼び出したスレッド
（たぶんリモートスレッド）のコンテキストで実行されている。
リモートスレッドがメッセージループを回さずに終了しているなら、
タブをクリックする前にダイアログは破棄されているだろう。
どのウィンドウがどのスレッドに属していて、どんな具合に動いて
いるのかが理解できていないと、進展は程遠い。
あと、DLL の生存期間を超えてサブクラス化したままだったら、
そこでお亡くなりになるだろう、ってことも容易に想像できる範囲。
このあたり、ちゃんと考えて制御してますか？

＃誰のゴリ押しでやるはめになってるのか知らないけど、
＃進展などできずにギブアップするほうが、幸せかも。

これらは、うまくいってますか？
>//タスクマネージャのインスタンスハンドルを取得
> g_hTaskManagerInst = (HINSTANCE)GetWindowLong(g_hTaskManager,
> GWL_HINSTANCE);
> //タスクマネージャプロシージャのサブクラス化
g_OriginalTaskManagerWndProc = (WNDPROC)SetWindowLong(g_hTaskManager,
> GWL_WNDPROC, (LONG)NewTaskManagerWndProc);