MFC プロジェクトに外部の .cpp や .c を追加した瞬間、突然 C1010 や C1853 が出ることがあります。
fatal error C1010: プリコンパイル ヘッダーを検索中に予期しない EOF を検出しました。include pch.h をソースに追加しましたか?
fatal error C1853: 'Debug\\MyApp.pch' は以前のコンパイラ バージョンのプリコンパイル済みヘッダー ファイルか、C++ のプリコンパイル済みヘッダーが C から使用されています。
結論から言うと、この 2 つはどちらも PCH(プリコンパイル済みヘッダー)の使い方が、ファイルごとの実態と噛み合っていない ときに起きます。stdafx.h 時代のプロジェクトでも、近年の pch.h プロジェクトでも本質は同じです。
| 症状 | 原因 | 最短の対処 |
| C1010 | そのファイルだけ /Yu なのに pch.h / stdafx.h を先頭で読んでいない | 自前コードならヘッダーを先頭に追加。外部コードならそのファイルだけ PCH を使用しない |
| C1853 | 古い .pch が残っている、または .c / /TC が C++ 用 PCH を使おうとしている | まず クリーン → リビルド。.c が原因ならそのファイルだけ PCH を使用しない |
この記事では、Visual Studio 2026 での確認結果をもとに、何を見れば原因が切り分けられるか と 最小の修正でどう直すか を順番に整理します。
まず理解したい: PCH は「全ファイル共通ルール」ではない
PCH(Precompiled Header)は、巨大なヘッダー群を毎回パースし直さないための高速化機構です。MFC では afxwin.h などの重量級ヘッダーを毎回読むとビルドが重くなるため、通常は以下の形になっています。
pch.cppまたはstdafx.cppがpch.h/stdafx.hから.pchを作る(/Yc)。- 他の
.cppはその.pchを使う(/Yu)。 - ただし、外部から持ち込んだ純粋な
.cppや.cは、このルールと噛み合わないことがある。

ここで重要なのは、「プロジェクト全体では PCH を使うが、特定ファイルだけ例外にできる」 という点です。C1010/C1853 は、この例外設定を入れるべきファイルに、全体ルールをそのまま押し付けたときに起きやすいエラーです。
C1010 の正体: /Yu のままなのに pch.h を読んでいない
C1010 は、そのファイルが PCH を使う設定なのに、先頭で対応ヘッダーを読んでいない ときに出ます。典型例は、外部からコピーした sha256.cpp や json_reader.cpp を MFC プロジェクトに追加したケースです。
// third_party_cpp.cpp
int ThirdPartyCpp()
{
return 7;
}
このファイルは単体では何も悪くありません。しかしプロジェクト側が /Yu"pch.h" なら、コンパイラは「最初に #include "pch.h" が来るはずだ」と期待します。そこで EOF まで探して見つからないと C1010 になります。
対処 1: 自分で管理する cpp なら先頭に pch.h を入れる
そのファイルがプロジェクト内の通常コードで、MFC 側のヘッダーも参照して問題ないなら、単純に先頭へ追加すれば直ります。
#include "pch.h"
int MyFeature()
{
return 42;
}
旧プロジェクトでは pch.h ではなく stdafx.h です。名前が違うだけで判断基準は同じです。
対処 2: 外部ライブラリの cpp なら、そのファイルだけ PCH を切る
こちらが本命です。サードパーティーのソースに pch.h を書き足すと、アップデート時に差分管理が崩れます。外部コードは汚さず、そのファイルだけ「プリコンパイル済みヘッダーを使用しない」 にするのが安全です。
- ソリューション エクスプローラーで対象の
.cppを右クリックし、プロパティを開く C/C++>プリコンパイル済みヘッダーを選ぶプリコンパイル済みヘッダーを 使用しない に変更する

.vcxproj では次の設定に相当します。
<ClCompile Include="third_party_cpp.cpp">
<PrecompiledHeader>NotUsing</PrecompiledHeader>
</ClCompile>
この方法なら、プロジェクト全体のビルド速度は維持したまま、例外ファイルだけ素通しでコンパイルできます。
C1853 の正体 1: 古い .pch が残っている
C1853 は「C から C++ の PCH を使った」場合だけでなく、今ある .pch が現在のコンパイラや設定と噛み合っていない ときにも出ます。Visual Studio の更新直後や、ツールセット変更後、ブランチ切り替え後に起きやすいパターンです。
- まず
ビルド>クリーンを実行する - 続けて
リビルドを実行する - それでも直らない場合は、エラーメッセージに出ているファイルが
.cか、ファイル単位で/TCになっていないか確認する
この 3 手で直るなら、原因は「古い中間生成物」です。ここで深追いしてコードを触る必要はありません。
C1853 の正体 2: .c ファイルが C++ 用 PCH を使おうとしている
クリーン後も C1853 が残り、問題のファイルが .c ならこちらです。MFC プロジェクトの PCH は通常 C++ として作られているため、C ソースからそのまま使うことはできません。
// legacy_c_module_broken.c
#include "pch.h"
int LegacyCModuleBroken(void)
{
return 0;
}
この状態で .c をビルドすると、「C++ のプリコンパイル済みヘッダーが C から使用されています」という C1853 になります。
推奨対処: .c は .c のままにして、そのファイルだけ PCH を切る
外部 C ライブラリを取り込んだだけなら、無理に C++ 化しない方が安全です。.c 側から pch.h / stdafx.h を外し、さらに そのファイルだけ「プリコンパイル済みヘッダーを使用しない」 にします。

修正後のイメージはこうです。
// legacy_c_module_fixed.c
int LegacyCModuleFixed(void)
{
return 0;
}
どうしてもそのファイルを C++ として扱いたいなら、ファイルのプロパティで コンパイル言語の選択 を C++ コードとしてコンパイル (/TP) に変える方法もあります。ただし、C ライブラリの文法差分で別エラーが増えやすいので、最初の選択肢にはしない方が無難です。
迷ったときの判定フロー
- C1010 が出たら、そのファイルの先頭に
pch.h/stdafx.hがあるかを見る - 外部コードなら、まず「そのファイルだけ PCH を使用しない」を試す
- C1853 が出たら、最初に クリーン → リビルド で古い
.pchを疑う - まだ直らず問題のファイルが
.cなら、pch.hを読ませず、そのファイルだけ PCH を切る /TPでの C++ 強制は最終手段にする
「全部で使う」ではなく「例外ファイルだけ外す」 という考え方を持つと、MFC プロジェクトでも外部コードを無理なく共存させられます。C1010 と C1853 が出たら、PCH の前提とファイルごとの設定が一致しているかを確認してください。
