C++ の環境構築で、コンパイル実行にエラーが出ないのに、成果物（out.exe）がどこにも存在しない……。
この“画面上は成功したように見えるのに、実際には何も生成されていない”という状況は、MinGW-w64 で発生するトラブルの中でも最も厄介な部類です。

今回寄せられた状況はかなり再現度が高く、
・g++ --version は正しく動く
・test.cpp も正しい
・エラーも表示されない
・しかし out.exe がどこにも無い
という“成功に見せかけた失敗”です。

こんな時、何を疑えばよいのか？
どこから問題が始まっているのか？
公式もまとまっておらず、ネットの断片情報だけでは解決しないケースなので、この記事では 原因・再現事例・対処法・他ユーザー報告 をまとめ、フォーラム風で読みやすい構造にして解説します。

2025年11月公開

何が起きているのか？まず現象を正確に整理しよう

あなたが示してくれた状況をひとつずつ整理すると、次のようになります。

・g++ は動作しバージョンも取得できる → PATH 設定は正しい
・test.cpp は普通の Hello World → コンパイル不能な要素は無い
・g++ out test.cpp を実行してもエラー無し → g++ 自体は正常終了と判断している
・しかし出力 out.exe が生成されない → OS かディスクか MinGW の異常

つまり、

“コンパイル処理が開始されたが、出力ファイルの書き込みが OS に阻止されている”

という構造です。

これが発生するのは Windows に特有で、
MinGW 側ではなく、Windows の I/O 保護・ファイル仮想化・安全機能が原因になります。

同じ症状は他にもある？ユーザー事例から見える共通点

ネットでもこの現象に悩む人は多く、報告には次の共通点があります。

・出力先フォルダに書き込み権限が無い
・OneDrive と同期しているフォルダで発生
・PowerShell が実行を仮想化している
・C直下、Dropbox直下、Program Files 直下などで操作している
・アンチウイルスが出力バイナリを自動削除している
・MinGW の展開先に全角文字 or 変な構造がある
・SEH/UCRT版 mingw の一部で write failure が出る

あなたのケースで特に怪しいのが、OneDrive／Dropbox／デスクトップ／Document で試したという点です。
これらはすべて“仮想化フォルダ”になりやすく、MinGW の生成した exe が Windows によって サイレント削除 されることがあります。

この現象の技術的背景：Windows の「Controlled Folder Access（フォルダ保護）」が犯人の可能性が高い

Windows Defender には
Controlled Folder Access（フォルダ保護）
というセキュリティ機能があります。

実はこの機能、知らないプログラム（g++）が exe を書き出すと、無言で削除します。

しかも「ブロックした」というログを出さない場合もあり、
“エラーなし → でもファイルなし”
という今回そっくりの挙動になります。

あなたが試した対策の中で「Defender を切った」とありましたが、
Defender を切っても、この機能は裏で動くケースがあります。

原因は1つではない：考えられる主要因を全て洗い出す

ここでは、あなたの現象に該当する原因を網羅します。

原因1：出力先フォルダに書き込み権限がない

特に以下のフォルダでは危険です。

C:\
C:\Users\xxx\Desktop
C:\Users\xxx\Documents
Dropbox内
OneDrive内

MinGW は“古い”プログラムなので、Windows のアクセス保護と相性が悪いです。

原因2：アンチウイルスが out.exe を即削除

McAfee を使っていると高確率で発生します。

生成
→ McAfee が「怪しい exe」と判断
→ 即削除
→ ユーザーは「生成されていない」と見える

ログは深層メニューに隠れていることが多いです。

原因3：実行場所が PowerShell の仮想パスになっている

PowerShell では
LS
cd
g++
の後に、実際のファイルパスが意図した場所と違うことがよくあります。

例：
C:\ と思っていたが実際には
C:\Users\xxx\AppData\Local\VirtualStore
に保存されるケース。

原因4：MinGW の展開先が不適切（全角・スペース・長すぎ）

今回の解凍先は
C:\x86_64-15.2.0-release-posix-seh-ucrt-rt_v13-rev0

名前が長すぎて、MinGW 内部が参照エラーすることがあります。

原因5：UCRT-SEH版 MinGW の一部ビルドにある既知のバグ

niXman 版 MinGW（あなたが使ったもの）は非常に良質ですが、
SEH + UCRT の組み合わせでは
出力 exe の書き込み時にエラーが出ないのに生成されない
というバグ報告が数件あります。

解決策：上から順に試せば 99％修復可能

最短ルートで直す方法を挙げます。

【解決策1】実行フォルダを C:\Dev などの“普通のフォルダ”にする（最重要）

まずは通常のフォルダで実行してください。

(1) C: に Dev フォルダを作る
例： C:\Dev

(2) test.cpp をそこへ移す
例： C:\Dev\test.cpp

(3) PowerShell で
cd C:\Dev
g++ -o out.exe test.cpp

これだけで生成されることが非常に多いです。

【解決策2】Defender の「フォルダ保護」を明示的にオフにする

手順：

(1) Windows セキュリティを開く
(2) ウイルスと脅威の防止
(3) ランサムウェア保護
(4) Controlled folder access → オフ
(5) 再度 g++ 実行

これをオフにしないと、exe は生成しても消されます。

【解決策3】MinGW のフォルダ名を短くする（互換性改善）

今のフォルダ名は長すぎます。

おすすめは：

C:\mingw64

この中に bin を置くだけ。

【解決策4】PowerShell ではなく CMD を使用する

PowerShell より CMD の方が MinGW との相性が安定しています。

cmd
cd C:\Dev
g++ -o out.exe test.cpp

【解決策5】SEH版ではなく SJLJ版又は Win32 Thread版を使う

niXman版 MinGW の中でも
posix-seh-ucrt 版は exe 書き込みバグの報告が存在
するため、

x86_64-15.2.0-release-posix-sjlj
または
x86_64-15.2.0-release-win32-sjlj

を推奨します。

【解決策6】McAfee を終了するだけではダメ → 例外設定が必要

McAfee は disable してもバックエンドが動くことがあります。

C:\Dev を例外フォルダに追加してください。

これでも直らない場合の“最終診断ポイント”

次の項目を確認すると突破できます。

WIndowsの仮想化フォルダに生成されていないか？
コマンド後に out.exe を検索したか？
MinGW 内の g++.exe が壊れていないか？
パスに複数の MinGW が混在していないか？
VSCode の拡張が勝手に別コンパイラを呼び出していないか？

特に
複数の MinGW が PATH に入っている
は超ありがちな原因です。

まとめ：エラーなし・exeなし状態は「OS側が exe を阻止している」時に必ず起きる

今回の現象の本質はこうです。

最重要結論：MinGW が壊れているのではなく、Windows 側の保護機能・フォルダ制御・パスの問題で out.exe が無言削除されている。

対策としては：

・C:\Dev で作業
・フォルダ保護OFF
・McAfee例外
・CMDで実行
・フォルダ名短縮
・MinGWの別ビルドを試す

このあたりを順に試せば、ほぼ確実に復旧します。

フォーラム風コメント欄：あなたの環境ではどの解決策が効きました？

同じ症状で困っている人のために、以下を共有してみてください。

MinGW のどのビルドを使いました？
McAfee や Defender の例外設定をしましたか？
C:\Dev に移したら動きました？
PowerShell → CMD で改善しました？
VSCode 側でも同症状でした？

あなたの一言が、同じ問題で悩んでる人の助けになります。