PATIO さん、申し訳ないですが、対処法で行きたいと思います。
自分の環境では生じない現象で、原因究明はこのユーザーの協力がないとできないため
です。

現在、139個のコントロールを配置して、それを SW_HIDE/SW_SHOW で３通りに切り替え
ているやり方はスマートとは言えないので、ビューを切り替える方式があると知った
今、そちらに乗り換えたいです。

テーマを「アプリを終了してもプロセスタブから消えないのは何故？」としておきなが
ら、話をすり替えてしまうことになり、興味を持たれた諸先生方には申し訳ありませ
ん。

原因特定が理想だけど、ユーザの環境のせいとも考えられません？
10万ダウンロード中、ユーザの実数がどれ位あるのかわからないけど、
不具合報告は1件だけなんですよね？

原因究明のためにユーザに協力を求め続けるよりも、
そのユーザ向けに、残ったプロセスを再起動時に殺す仕組みを作ったりする方が
現実的ではないですか？いくらでも協力してくれるユーザさんかもしれませんが、
さんざん手伝わせて原因不明だと、やはり気が引けるのではないでしょうか。

それと、この現象を回避するだけの目的で、不慣れなFormViewの切り替えなどをすることは、
お勧めできません。ましてや原因不明なのに。
別の目的でリファクタリングするついでがあるなら別ですが。

# 新しいプロジェクトに多数のコントロールを貼り付けただけのプログラムで、
# 不具合発生ということは、多分そのユーザの環境のせいだと思うな。
# 変なライブラリを組み込んだりしていないなら。

　> 現在、139個のコントロールを配置して、それを SW_HIDE/SW_SHOW
> で３通りに切り替えているやり方はスマートとは言えないので、
> ビューを切り替え る方式があると知った今、そちらに乗り換えたいです。

確かにスマートではないけど、フォームビューじゃなくダイアログの
　環境ならあてはまるし、あちこちで切り替えずに1つところでスマートに
　きりかえるならいいと思います。

ん-？
　PATIOさんとたいちうさんの意見に賛成ですね。

　不具合は何件中何件でていますか？
　不具合は1人だけですか？

　もし1人だけで、ほんちゃんさんが気になるのなら、
　直接その人にあって不具合を確かめるのも手ですね。
　分かっていても、「こんな操作してるんだ」ってことも
　あると思います。
　とにかく、ほんちゃんさんのPCでも同じ不具合がでる
　ようにならないと対処法もうまくいかないと思います。
　
　僕は、ある程度原因が分かってから対処法を考えるのが
　得策だと思います。

>①
MFCのウィザードで作っていたら
CxxxApp::InitInstance(){}
の最後のほうに、
**************
// メイン ウィンドウが初期化されたので、表示と更新を行います。
m_pMainWnd->ShowWindow(SW_SHOW);
m_pMainWnd->UpdateWindow();
*************
こういうのがあるはずです。
これの前に
((CMainFrame*)m_pMainWnd->OnViewChange();　//関数名は勝手
を加えればいけます

>②
CMainFrameのメッセージに「WM_DESTROY」があるので、そこで
CView *view = GetActiveView();
view->DestoryWindow();
#しなくてもいいと思うが、しなくてもいいと言い切れるソースがなかったので・・・
#すいません。

対処法も大いに結構ですが…

原因追求の為にログをファイルへ出力する様に仕掛けを作り、
そのアプリを該当ユーザに使用して貰い、不具合が出る手順(？)をお願いしてみる。

そこで出力されたログファイルを元に調査をしてみては如何でしょうか？

rin さん、ありがとうございました。
うまく出来ました。
これで３つのサブフォームビュー（それぞれに、60, 57, 22個のコントロールを配置）
を持つテストプログラムを作って、テストして貰います。
なお、
> (CMainFrame*)m_pMainWnd->OnViewChange();　//関数名は勝手
これではビルドのときエラー「CWndのメンバーではありません」となったので、
CMainFrame *pMainFrame;
pMainFrame = STATIC_DOWNCAST(CMainFrame, theApp.GetMainWnd());
pMainFrame->OnViewChange();
としました。

ITO さん
> 不具合は何件中何件でていますか？
> 不具合は1人だけですか？
１０万ダウンロード中、一人だけです。
> 直接その人にあって不具合を確かめるのも手ですね。
ネット上のユーザーでメールをくれた方で、どこの誰か判りません。

たいちう さん
> さんざん手伝わせて原因不明だと、やはり気が引けるのではないでしょうか。
そうなんです。すでにガッカリさせています。
「問題点の目星はついたけれど、原因は不明なのですね。」と。
このユーザーさんは好奇心のある方のようで、よく協力してくれました。
「私のＰＣの調子が悪いだけなのでは？と思わなくもありません。
他のフリーソフトでエラーが出てしまうものがひとつあったりするので…
リカバリした方が…とか思ったりもします。」とも言っています。

ログを仕込むと言っても、フォームビューのSDIのスケルトンに、コントロールをリソー
スで貼り付けただけのプログラム。それを起動して終了するだけですから。
ウインドウは消えているので、CMainFrame は終わっている？
Komatta.cpp が残っている？ （Komatta はプロジェクト名）
それが判ったとして、このユーザーの Windows XP Home Edition +SP3 の環境で、何故
そうなるのか、メールのやりとりだけで解明するのは難しいでしょう。

カッコが足りなかったです
> (CMainFrame*)m_pMainWnd->OnViewChange();　
↓
((CMainFrame*)m_pMainWnd)->OnViewChange();　
#こういう方法もあるということで…

>Komatta.cpp が残っている？ （Komatta はプロジェクト名）
Mutexの話題のときに、CKomatta;;ExitInstanceまでたどり着いてることは確認してまし
たから、ネットの向こうの環境に対し、これ以上は探るのは難しいと思います

rin さん
そっかー
最初は
> ((CMainFrame*)m_pMainWnd->OnViewChange();　//関数名は勝手
括弧が一つ多いと思った、わたしが悪いのよ。(^_^;) 足りないと気づかなくちゃ。
ごめんなさい。

> １０万ダウンロード中、一人だけです。

あら、そんなにレアケースなのですね。
そうなると御本人も御自分の環境を疑っておられるようだし、
環境を再構築する事を進めるのも手かなと思いますねぇ。
現実にオンラインソフトの作者さんであまりに不可解な内容の場合は、
再構築を進めるケースは珍しく有りませんし。

個人的には気になる所なので追求したいのも人情なんですけど。
結果的にはその方の環境が壊れている可能性も高いですね。
他のソフトでもおかしくなると言う話であれば、なおさらですけど。

うーん、ライブラリか何かが壊れていて偶々ソフトの終了時に
それが表に出てきているだけだとすると、今回の修正で直るかどうかは
博打になるかもしれませんね。
これで駄目なら再構築をと言うもの手かと。

Windowsは定期的に再構築した方が調子が良い状態を保てると言う人も
少なく無いですしねぇ。

rin さん
このユーザーさんから回答があり、ＡＢＣ３つのサブフォームビュー（それぞれに、
60, 57, 22+9個のコントロールを配置）を持つテストプログラムのテスト結果は、どの
ような終了をしても、すべてプロセスタブに残留することはなかったということです。
（Ａで終わる、Ｂで終わる、Ｃで終わる、切り替えて終わる、タイトルバーのＸ印で終
わる、アプリケーションの終了で終わる、タスクバーから終わる）
成功です！
これでフリーソフトを作り直します。
ご教授まことにありがとうございました。

関心を持って戴いてアドバイスしてくださった先生方、どうも有り難うございました。

> 成功です！
> これでフリーソフトを作り直します。

あなたのプログラムなんだから、どうなさっても結構なのですが、
間違っていないですか？
作り直すというのが、そのユーザーさん向けに作ることを指すのか、
頒布用のプログラムのバージョンアップを指すのか読み取れませんが、
後者であるならば（大きなお世話ですが）反対です。

不具合の真の原因が、1フォームあたりのコントロール数だとすると、
サブフォームに分割する修正で解決しますが、コントロール数が真の原因とは
私には思えません。真の原因があなたのプログラムにあるとも限りません。

別の原因が何らかの異常を発生させていて、コントロール数が多いときには
プロセスが残るという症状が見られているのだと私は思います。
コントロール数が少ないときに、症状が見られないからといって、
異常が発生していないとは言えないでしょ？

今回の対策ですと、コントロールを分割したスケルトンの場合には
症状が見られなくても、スケルトンに肉付けしたら同じ症状が発生したり、
別の症状が発生したりすることは、十分ありえることと思います。

なお、修正のために労力をかけるのも、プログラムに責任を持つのも
私ではないことは承知しています。差し出がましいことを書いているのは
申し訳なく思っています。私の書いたことをまだ検討されてないようでしたら、
こんな考え方もあるかも、と一応ご検討ください。

既に書きましたが、別の目的でリファクタリングするなら話は別です。
プログラムの品質が向上し、ついでにそのユーザーさんの問題も
解決するかもしれないので、存分になさって下さい。

> 別の原因が何らかの異常を発生させていて、コントロール数が多いときには
> プロセスが残るという症状が見られているのだと私は思います。
> コントロール数が少ないときに、症状が見られないからといって、
> 異常が発生していないとは言えないでしょ？

これについては私も同感です。
結局、真の原因と読んでも差し支えない所まで突き詰め切れていませんから。
なので、症状が治まったと言うだけの話で本当の意味で異常が解消されたか
というとそれは分からないでしょうねぇ。
もしかしたら偶々プロセスが終了しないと言う形で現れていた症状が
隠れてしまって本当の異常は内包したままと言う可能性も有りますからね。

但し、これに関しては御本人の判断次第かなと私も考えています。
もしこれが仕事で一緒に仕事をしている立場なら当然NGを出します。
なぜなら今の内容では症状を無くすことにはなっても不具合の解消には
なっていない可能性があるからです。

たいちう さん、PATIO さん
ご忠告有り難うございます。
皆さん、よく考えてくださると、ほんとに感心しています。もちろん感謝もです。

問題を整理すると、
１．原因が判っていない
２．作り直すことのメリット／デメリット（リスク）

１．
原因（異状）は、①プログラムの肉付けの部分にあるか、②このユーザーの環境にある
か、③両方の相乗効果であるか、いずれかです。
作り直したら（肉付けが済んだら）このユーザーにテストして貰います。
ＯＫであれば、①は消えます。
今回の現象は極めてレアケースと考えていますので、①が消えれば「よし」とします。
②③の追求・解決は、何度も言いますが、無理です。
ＯＫでなければ、そこで考えます。

２．
頒布用に作り直します。
次のバージョンは、若干の機能追加を予定しています。

> この現象を回避するだけの目的で、不慣れなFormViewの切り替えなどをすることは、
> お勧めできません。
> 別の目的でリファクタリングするついでがあるなら別ですが。
よく判ります。
仕事なら、実績のあるベースを変えるようなことは、私も経験上（プログラミングでは
なく、ある高度な製品開発を長年してきました）決してしません。

ですが、このソフトは趣味で作っていますので、FormViewの切り替えの方がスマートだ
と思った今、これで作りたくてしょうがありません。(^o^)

FormViewの切り替えの方がスマートだと思っているのでしたら、
例え業務でされているのだとしても、反対する理由は全然ありません。
頑張ってください、というか、楽しんでください。