Visual Studio 2022 CommunityでMFCダイアログベースアプリを作成するとHRESULT E_FAILが出て、.rcやダイアログデザイナーが開けない。原因切り分けからログ取得、拡張機能・セキュリティ・パス問題の対処まで、最短で直す手順をまとめます。
起きている症状を整理する（ビルドできるのにデザイナーだけ壊れる）
このトラブルは、見た目がやや特殊です。プロジェクト自体はフォルダーに生成され、開き直せばビルド・実行もできるのに、Visual Studio上で「統合」が途中で止まったような状態になります。その結果、リソース編集に必要な機能が動かず、.rcやダイアログデザイナーが使えません。
| 項目 | よくある状態 | 判断ポイント |
|---|---|---|
| ウィザード完了時のエラー | 「error hresult-e fail has been returned from a call to a Com component」 | 作成直後に出る（作成処理の最後で落ちている） |
| フォルダー/ファイル | プロジェクト一式は存在する | .sln/.vcxproj/.rcなどは作られている |
| ビルド/実行 | できることが多い | MSBuild/コンパイラは動くが、IDE統合が壊れる |
| Resource（.rc） | 開けない／テキストでしか開けない／リソースビューが出ない | 「ダイアログデザイナー」が起動しない |
原因の考え方：ウィザードの「作成後処理（post-creation）」でCOM連携が失敗している
MFCのアプリケーションウィザードは、ファイル生成だけでなく「作成後の後処理（IDEへの登録・設定）」も行います。ここでCOM関連の呼び出しが失敗すると、プロジェクト自体はできているのに、Visual Studioの統合処理が最後まで走らず、リソースデザイナー周りが正常に使えない状態になりがちです。Microsoft Q&Aでも、テンプレートが基本部分は作るが、COM関連のpost-creationで失敗し、原因特定は簡単ではないという趣旨の回答がされています。
このタイプの問題は、コードやMFC/ATLのバージョンというより、次のような「環境要因」で起きやすいのが特徴です。
- 拡張機能（Extensions）がウィザードやデザイナーの処理に干渉している
- セキュリティソフト（AV/EDR）やWindowsの保護機能が、生成直後のファイル操作やCOMアクティベーションをブロックしている
- パス条件（長すぎる、特殊文字、ネットワーク/同期フォルダー、権限が絡む場所）が原因で後処理が失敗している
- Visual Studio側のキャッシュ破損やインストール不整合（修復で直ることがある）
最短で直すための切り分け（効果が出やすい順）
ポイントは「原因を当てに行く」よりも、まず再現条件を崩して復旧させ、その後に原因を絞り込むことです。下の表の上から順に試すと、遠回りになりにくいです。
| 試すこと | 狙い | 具体的なやり方 | 成功のサイン |
|---|---|---|---|
| 作成場所を単純なパスへ | パス/権限/同期/リポジトリ配下の影響を排除 | C:\temp などに新規でMFCダイアログベースを作成 | 作成完了時にE_FAILが出ない、.rcがデザイナーで開く |
| 拡張機能を無効化 | テンプレート後処理やデザイナーを邪魔している拡張を排除 | Extensions > Manage Extensions でInstalledを一時無効/アンインストール | 新規作成で正常化、Resource Viewが復活 |
| Visual Studioをセーフモード起動 | 「拡張が原因かどうか」を高速判定 | devenv.exe /SafeMode で起動して新規作成を試す | セーフモードでは成功する（=拡張要因が濃厚） |
| セキュリティソフトを一時停止 | 生成直後のファイル生成/COM呼び出しブロックを排除 | AV/EDRを一時無効化して再作成（オフライン推奨） | 停止中だけ成功する（=例外設定が必要） |
| Visual StudioのRepair（修復） | インストール不整合・破損をまとめて直す | Visual Studio Installer から Repair | 通常起動でも再現しなくなる |
特に「C:\tempなどに作ると成功する」場合、プロジェクトを作っている場所が原因の可能性が一気に高まります。リポジトリ直下、OneDrive/Dropboxなどの同期フォルダー、ネットワークドライブ、権限が強い場所（例：Program Files配下）などは、見えない制約が増えます。
セーフモード（/SafeMode）で切り分けする手順
Visual Studioのセーフモードは、起動時にサードパーティ製VSPackageの読み込みを抑止し、安定した状態で起動するためのスイッチです。拡張機能が原因かどうかを切り分けるのに向いています。
Developer Command Prompt for VS 2022（または通常のコマンドプロンプト）で次を実行します。
devenv.exe /SafeModeセーフモードで新規に「MFC アプリケーション（ダイアログベース）」を作成し、エラーが消えるなら、まず拡張機能を疑って良い状況です。問題の拡張を特定するコツは「全部無効 → 半分ずつ戻す（分割統治）」です。
拡張機能を疑うときの現実的な進め方
- まずはC++/MFCに関係しそうな拡張（コード解析、デザイナー補助、プロジェクトテンプレート系、AI補助系）を優先して無効化
- その後、問題が消えたら「一つずつ戻す」より、影響の大きいものから戻して原因を絞る
- Visual Studio更新直後や拡張更新直後から起きたなら、ほぼそのタイミングがヒント
セキュリティソフト（AV/EDR）を疑うときの注意点
Microsoft Q&Aでも、プロジェクト作成場所の変更や、セキュリティ管理ソフトを一時的に無効化して切り分ける提案がよく出ます。
- 無効化は短時間・オフラインを基本にし、再現確認が終わったら必ず戻す
- 原因だと判明したら「無効化し続ける」のではなく、devenv.exeや作業フォルダーを例外設定に入れる方向で調整する
「.rcにアクセスできない」を深掘り：デザイナーとビルドの役割が違う
ビルドが通るのにリソースデザイナーが壊れるのは、珍しくありません。理由はシンプルで、ビルド時は主にMSBuildやrc.exe（リソースコンパイラ）が動けば成立しますが、ダイアログデザイナーやResource ViewはIDE側（Visual StudioのパッケージやCOM）に強く依存するためです。ウィザードの後処理が途中で止まると、IDE統合だけが破綻して見えます。
補足：.rcを「プロジェクト外」で開くと別のエラーになることがある
.rcファイルをエクスプローラーから単体で開くなど、C++プロジェクトの文脈が無い状態だと、Windows SDKのインクルード設定が確立しておらず、RC1015など別のエラーになってテキストとして開いてしまうケースがあります。今回の現象とは別ですが、切り分け中に混乱しやすいポイントです。
プロジェクトが作れているのにIDEがおかしいときに効く「キャッシュ系」対処
ウィザードやデザイナーが不安定なときは、Visual Studioやソリューションが持つキャッシュが壊れている場合があります。ここは「副作用が比較的小さく、戻しやすい順」で潰すのが安全です。
ソリューション単位：.vsフォルダーを削除して再生成させる
プロジェクトのルート（.slnと同じ階層）にある「.vs」フォルダーは、ローカルキャッシュの塊です。これが壊れると「開けない」「変な状態が残る」などが起きます。.vsを削除して開き直すと改善する例は多いです。
- Visual Studioを閉じる
- 対象ソリューション配下の「.vs」フォルダーを削除
- Visual Studioで.slnを開き直す
Visual Studio全体：ComponentModelCacheなどをクリアする
Visual Studioは拡張や構成要素の情報をキャッシュします。これが破損すると、COM連携やパッケージ読み込みが連鎖的に失敗し、テンプレート作成やデザイナーに波及することがあります。Microsoft Q&AではComponentModelCacheの削除手順が案内されています。
代表例（ユーザー名やインスタンスIDは環境で変わります）:
%LOCALAPPDATA%\Microsoft\VisualStudio\17.0_<インスタンスID>\ComponentModelCache削除前の注意点:
- 必ずVisual Studioを完全終了し、タスクマネージャーでdevenv.exeが残っていないことを確認する
- 削除後の初回起動はキャッシュ再構築が走るため、いつもより起動が遅くなることがある
ログで原因を特定する（調査フェーズ）
切り分けで改善しない場合は、ログを見て「どのCOM呼び出しが落ちているか」を把握すると、次の打ち手が具体的になります。Microsoftの回答でも、イベントログ確認やVisual Studioの/log起動が提案されています。
Visual StudioのActivityLog.xmlを取得する（/log）
Visual Studioは /log で詳細ログ（ActivityLog.xml）を出力できます。既定の保存場所は、%APPDATA%\Microsoft\VisualStudio\<Version>\ActivityLog.xml です。
実行例（任意の場所に出す場合）:
devenv.exe /log C:\temp\ActivityLog.xmlログ取得の流れ:
- /log付きで起動
- MFCダイアログベースの新規作成を実行してエラーを再現
- Visual Studioを閉じる
- ActivityLog.xmlを開いて、Error/WarningやCOM関連の行を探す
| 探すキーワード例 | 意図 | 次のアクションのヒント |
|---|---|---|
| E_FAIL / HRESULT | 失敗の核となる例外 | 直前のPackage/Component名を特定 |
| COM / CreateInstance / CLSID | COMアクティベーション失敗の痕跡 | 権限・レジストリ・セキュリティソフトを疑う |
| Package Load / VSPackage | IDE拡張（パッケージ）の読み込み失敗 | 拡張機能無効化、キャッシュクリア、修復 |
| Wizard / Template | テンプレート作成後処理の失敗位置 | 作成場所・パス条件・プロジェクト名条件を見直す |
Windowsのイベントログも確認する
COM関連の失敗は、Windows側のイベントログ（特にアプリケーションログ）に痕跡が残ることがあります。Microsoftの回答でもイベントログ確認が提案されています。
- イベントビューアーを開く
- 「Windowsログ」→「アプリケーション」を中心に、エラー発生時刻付近を確認
- Visual Studio、.NET Runtime、Application Error、DistributedCOMなどが手掛かりになることがある
改善しない場合に試す「環境リセット」
ここからは「作業時間は増えるが、効くと一気に直る」系です。すべてを一度にやるのではなく、切り分け結果に合わせて選びます。
Visual Studio設定をリセットする（/ResetSettings）
/ResetSettings は、Visual Studioの既定設定に戻すためのスイッチです。拡張や設定の影響で挙動が壊れている場合の「全体リセット」として有効です。
devenv.exe /ResetSettings設定リセットの前に、必要なら設定のエクスポート（バックアップ）も検討してください。リセット後はテーマやキーバインドなどが戻ります。
新しいWindowsユーザーで再現するか確認する
同じPCでも「別ユーザーでは再現しない」なら、ユーザープロファイル配下のキャッシュや権限、同期設定が原因になっている可能性が上がります。逆に別ユーザーでも再現するなら、マシン全体（インストールやセキュリティ、OS側）に原因が寄っていきます。
どうしても直らないとき：Microsoftに調査依頼する（Report a Problem）
切り分け・修復・ログ取得までやっても改善しない場合、Microsoft側に正式に調査してもらうのが最短になることがあります。Microsoft Q&Aでも、解決しない場合はReport a Problemで技術情報を添付して報告する流れが案内されています。
報告の質を上げるために、次をセットで用意すると通りやすいです。
| 添付・記載すると強い情報 | 具体例 | 狙い |
|---|---|---|
| 再現手順 | VSの版、OS、作成テンプレ、保存先パス、プロジェクト名 | 再現性を担保して調査を進めやすくする |
| ActivityLog.xml | /logで取得したログ | どのパッケージ/COMが落ちたかを特定 |
| イベントログの該当箇所 | エラー時刻付近の記録 | OS側ブロック/権限/COM起動失敗を裏取り |
| セーフモード結果 | /SafeModeだと成功するか | 拡張要因かどうかを明確化 |
よくある質問（ハマりやすいところだけ）
ビルドできるのに、なぜリソースデザイナーだけ使えない？
ビルドは主にコンパイラとリソースコンパイラが動けば成立します。一方、リソースデザイナーはIDEのパッケージ読み込みやCOM連携に依存するため、ウィザードの作成後処理がCOMで失敗すると「設計時機能だけ壊れる」状態が起きます。
再インストールしても直らないのはなぜ？
拡張機能、ユーザープロファイル配下のキャッシュ、セキュリティソフトのポリシー、作業フォルダーの制約などが原因だと、アンインストール/インストールだけでは残る要素があり、直りません。このため「Repair」や「セーフモードでの切り分け」「作成場所変更」が先に効くことがあります。
OS要因はあり得る？
多くはVisual Studio周りの環境要因で解決しますが、同種のCOM E_FAIL問題で、特定の環境ではOS変更（例：Windows 11→10）で解消したという報告も存在します。ただしこれは最終手段に近いので、まずは拡張・パス・セキュリティ・修復・ログ確認をやり切るのが現実的です。
再発を防ぐコツ（実務向け）
- MFC/Win32のテンプレートを使う作業は、まずローカルの短いパス（例：C:\work）に作る
- 拡張機能は「必須だけ」に絞り、更新タイミングを把握できるようにする
- セキュリティソフトが強い環境では、開発用フォルダーとdevenv.exe周りの例外設計を最初に整える
- 不具合が出たら、最初に /SafeMode と /log を回して“原因が拡張か否か”を即判定する
「MFCプロジェクトは作れるが、.rcやダイアログデザイナーだけ使えない」という状態は、テンプレート後処理の失敗が疑わしいサインです。上の切り分けフローで、まずは“正常に作れる状態”を取り戻し、ログで原因を潰し込むのが最短ルートです。
コメント