【MFC】LNK1104 / LNK2019 / LNK2001 ビルドエラー解決フロー：最短の確認順

2026年3月30日2026年7月14日

久しぶりに古いプロジェクトを開いたら、出力ウィンドウがリンクエラー（LNK〜）で埋まっていた、という経験は珍しくありません。
この記事では、むやみに設定をいじる前に見るべき場所を順番にまとめています。

LNKエラーの原因切り分け：エラー番号で見るべき場所が決まる

まず、エラー一覧の一番上に出ている番号を確認してください。これで対応が二つに分かれます。

エラー	何が起きてる？	最初に疑う場所
LNK1104	ファイル自体がない / 開けない	MFCのインストール忘れ、パス設定、権限/ロック
LNK2019 / LNK2001	参照している関数/変数の定義が見つからない	定義側の未リンク（.cpp / .lib の漏れ）、MFC設定、サブシステムとエントリポイント

以下、この順番でチェックしていきます。

手順1：まずは「構成」のズレを疑う

LNKエラーは「コードは悪くないのに設定がズレている」パターンが多いです。ここがズレていると、後の手順をいくら頑張っても直りません。

プロジェクトのプロパティを開くと、上部に「構成」と「プラットフォーム」のドロップダウンがあります。右上の「構成マネージャー」ボタンから、ソリューション全体の対応も確認できます。

Visual Studio 2026 プロパティページ上部の構成ドロップダウンと構成マネージャーボタン

Debug / Release は合っていますか？
x86(Win32) / x64 は合っていますか？

よくある事例：

x64でビルドしようとしているのに、参照しているライブラリが32bit(x86)版のまま
Debugの設定だけ直して満足し、Releaseビルドでもエラーが出る

設定を触るときは、必ず「構成」と「プラットフォーム」をセットで確認してください。迷ったら「すべての構成 / すべてのプラットフォーム」を選んで一括設定するのが確実です。

手順2：LNK1104「ファイルを開けません」の原因と対処

mfcxxxud.lib や xxx.lib が開けないと言われているパターンです。

① MFCコンポーネントが入っていない

エラーのファイル名が mfcxxx.lib や mfcxxxud.lib 系なら、まずここを疑ってください。

Visual StudioはデフォルトでMFCをインストールしません。「C++によるデスクトップ開発」を選んだだけでは入っていないことがあります。

直し方：

Visual Studio Installer を起動
「変更」→「個別のコンポーネント」タブへ
検索窓に「MFC」と入力
使用中のツールセットに合う「〜ビルドツール用 C++ MFC」コンポーネント（対象CPUが合うもの。通常は x86 & x64）にチェックを入れてインストール

② ライブラリのパス／指定が足りない

MFC以外のライブラリ（自社ライブラリ等）でこれが出る場合、リンカーがファイルを見つけられていません。「フォルダは合っているのに…」という場合は、.lib自体の指定漏れも確認してください。

プロジェクトのプロパティ → リンカー → 全般 → 追加のライブラリディレクトリ
→ .lib が入っているフォルダのパスがあるか確認します
プロジェクトのプロパティ → リンカー → 入力 → 追加の依存ファイル
→ xxx.lib 自体が列挙されているか確認します（なければ追加）

※ 同期ソフトやウイルス対策でファイルがロックされてLNK1104になるケースもあります。

手順3：LNK2019 / LNK2001「未解決の外部シンボル」の場合

リンカーが、参照されている関数や変数の定義をどこからも見つけられていない状態です。コードの書き間違いとは限らず、定義を持つ .cpp や .lib がリンクされていないだけのことも多いです。どのシンボル（関数）でエラーが出ているかを見ると原因が絞れます。

① 自作の関数名・変数名で出ている

一番多いパターンです。宣言（ヘッダー）はあるのに、定義を持つファイルがリンクされていません。実際のエラーはこう出ます。

symbol_main.obj : error LNK2019: 未解決の外部シンボル "void __cdecl PrintGreeting(void)" (?PrintGreeting@@YAXXZ) が関数 _main で参照されました

定義を書いた .cpp がビルド対象に入っているか（「ビルドから除外」になっていないか）を確認します
定義が別ライブラリにあるなら、手順2で見た「追加の依存ファイル」にその .lib があるかを確認します
宣言と定義で引数や呼び出し規約が食い違っていないかも見てください（C の関数を C++ から呼ぶ場合は extern "C" が必要です）

② `CWinApp`、`CDialog`、`CString` などで出ている

MFC のクラスばかりで出ている場合は、プロジェクトが MFC を使う設定になっていない可能性が高いです。

プロジェクトのプロパティ → 詳細 → MFCの使用 を開きます
「標準Windowsライブラリを使用する」になっていたら、「共有 DLL で MFC を使用」（またはスタティック）へ変えます

多くの場合はこれで解消します。直らない場合は、Debug 用と Release 用のライブラリが混在していないか、リンクしている .lib が別世代の MFC でビルドされたものでないかも疑ってください。

③ `_WinMain@16` や `_wWinMain` で出ている

エントリポイント（入口関数）が見つかっていません。主因はサブシステムとコードの組み合わせです。たとえば main() しかないコンソール向けのコードを Windows (/SUBSYSTEM:WINDOWS) でリンクすると、こうなります。

MSVCRTD.lib(exe_winmain.obj) : error LNK2019: 未解決の外部シンボル _WinMain@16 が関数 "int __cdecl invoke_main(void)" (?invoke_main@@YAHXZ) で参照されました

次の順に確認してください。

プロパティ → リンカー → システム → サブシステム。ウィンドウを持つアプリなら Windows (/SUBSYSTEM:WINDOWS)、コンソールなら コンソール (/SUBSYSTEM:CONSOLE) で、コードの入口関数（WinMain / main）と対応しているかを確認します
プロパティ → リンカー → 詳細設定 → エントリポイント。ここに wWinMainCRTStartup などが明示指定されていて、対応する wWinMain がコードに無いと、_wWinMain 側が未解決になります（古い MFC Unicode プロジェクトに多い設定です）。通常は空欄（既定）で問題ありません
エントリポイントを明示指定している場合のみ、プロパティ → 詳細 → 文字セット との対応も確認します（wWinMainCRTStartup は Unicode 用の入口です）

なお、現行の Visual Studio では、エントリポイントが既定（空欄）なら、リンカーが定義済みの WinMain / wWinMain に合わせて入口を選ぶため、文字セットの設定と入口関数の書き方が食い違っているだけではエラーになりません。文字セットを疑うのは、エントリポイントを明示指定しているプロジェクトの場合です。

最終手段：それでも原因が分からない場合

「設定は合っているはずなのに直らない」という場合は、リンカーに何をどう探して、なぜ弾いたかを全部出力させます。

プロパティ → リンカー → 全般 → 進行状況の表示を「詳細情報をすべて表示 (/VERBOSE)」に変更
リビルドする
出力ウィンドウに大量のログが出るので、エラーになったシンボル名や .lib 名で検索
どの .lib をどの順で検索し、どの .obj を読み込んだかが「○○.lib を検索中:」「○○.lib(○○.obj) を読み込みました。」の形で流れるため、エラーになったシンボルを誰が参照し、どこまで探して見つからなかったかを特定できます

※ 解決したら /VERBOSE は戻してください。ビルドが遅くなります。