手元では普通に動いていたMFCアプリが、配布先のPCではmfc100u.dllが見つからないと言って起動しません。
mfc100u.dll が見つからないため、コードの実行を続行できません。
プログラムを再インストールすると、この問題が解決する場合があります。必要なのはVisual C++ 2010の再頒布可能パッケージです。2012や2013のパッケージ、いまのv14のパッケージでは代わりになりません。
| 出ているDLL名 | 読む記事 |
|---|---|
| mfc100.dll / mfc100u.dllだけ直したい | この記事：VC++ 2010専用の手順 |
| mfc120.dll / mfc120u.dll | VC++ 2013の再頒布パッケージの特定と導入 |
| mfc140.dllなど複数世代をDLL名から判別したい | DLL名から再配布パッケージを特定する早見表 |
mfc100u.dllという名前の意味（mfc100はVC++ 2010、末尾uはUnicode）
mfc100u.dllという名前は、前半と後半で別のことを言っています。前半のmfc100はMFCのバージョン10.0を指します。Visual C++ 2010 / Visual Studio 2010世代のランタイムだという印です。後半のuはUnicodeビルドのほうです。命名規則はMicrosoftのMFC Library Versionsに載っています。MFCversion.DLLがANSI / MBCS版、MFCversionU.DLLがUnicode版です。
| DLL名 | 文字セット | 備考 |
|---|---|---|
| mfc100u.dll | Unicode | 共有DLL版のUnicode Releaseビルドが依存する名前 |
| mfc100.dll | ANSI / MBCS | 文字セットが「マルチバイト」の古い設定 |
| mfc100ud.dll / mfc100d.dll | —（末尾d） | Debug版。再頒布できない |
mfc100u.dllとmfc100.dllは、どちらで止まっても入れるパッケージは同じです。ただ、名前は一度よく見ておいてください。末尾にdが付いていたら話が変わります。mfc100ud.dllやmfc100d.dllで止まっているなら、配ったのがDebugビルドです。Debug版のDLLは再頒布できません。まずReleaseでビルドし直してください。
公式が求めているのは、ビルドに使った版と同じ（matchingな）MFCのDLLを配ることです。版が違えば代わりになりません。Visual Studio 2026などに付いてくる新しいパッケージも、2010とは別の世代です。公式の呼び方は「Visual C++ v14 Redistributable」で、Visual Studio 2017〜2026で共通です。2012や2013のパッケージも同じで、世代ごとに別々に配布されています。
以降の実測はVisual Studio 2026 / Debug / x64 / Unicodeで確認しました。直す対象のランタイムはVisual C++ 2010です。
手順1：x86かx64か（OSではなくアプリのビット数）
VC++ 2010の再頒布パッケージはx86（32bit）とx64（64bit）に分かれています。公式の言い方は「再頒布可能パッケージのアーキテクチャは、アプリの対象アーキテクチャと一致していなければならない」です。見るのはOSのビット数ではありません。mfc100u.dllを要求している実行ファイルのほうです。ソースが手元にあるなら、Visual Studioの構成プラットフォームで分かります。C++ プロジェクトのプラットフォーム名はWin32とx64です。Win32はx86を指します。
手順2：VC++ 2010 SP1再頒布可能パッケージを入れる
mfc100u.dll / mfc100.dllは、MicrosoftのVisual C++ 2010 SP1再頒布可能パッケージ（MFCセキュリティ更新） に入っています。手順1で決めたビット数に合わせて、32bitアプリならvcredist_x86.exe、64bitアプリならvcredist_x64.exeを、エラーが出ているPCで実行します。終わったらアプリをもう一度起動してみてください。
この2つのDLLが本当に入っているかは、検証機で中身を開いて確かめました。パッケージはインストールせず、展開しただけです。x86版・x64版のどちらにもMFC100U.DLLとMFC100.DLLが入っていました。vc_red.cabのほうが10.0.40219.1、同梱のパッチ（KB2565063）のほうが10.0.40219.325です。
DLLを持ち歩きたくないならMFCを静的リンクする
配布先ごとに再頒布パッケージを入れて回るのが面倒なら、DLLへの依存そのものをやめる手もあります。プロジェクトのプロパティで［全般］の［MFCの使用］を［スタティック ライブラリでMFCを使用する］に変えます。こうするとMFCがexeに取り込まれ、MFCのDLLを配らずに済みます。
この設定はよく「/MTにする」と言われます。ただ、/MTは別の場所です。［C/C++］→［コード生成］→［ランタイム ライブラリ］のスイッチで、選んでいるのは静的なCRT（LIBCMT.lib）のほうです。MFCのDLLへの依存を外すのは［MFCの使用］で、2つは別の設定だと思ってください。
自分のexeがどのMFC DLLを読んでいるかは、動かしている最中にロード済みのDLLを数えると分かります。MFCを共有DLLでリンクしたままVisual Studio 2026で動かしたところ、次の1件が出ました。
ロード済み MFC DLL（1 件）
- C:\WINDOWS\SYSTEM32\mfc140ud.dll共有DLL版のexeは、起動のたびにMFCのDLLを読みに行きます。この検証はVisual Studio 2026（v14xツールセット）のDebugビルドです。だから名前はUnicode Debug版のmfc140ud.dllでした。Visual Studio 2010でビルドすると、同じ規則でDebugがmfc100ud.dll、Releaseがmfc100u.dllになります。外へ配るのはReleaseビルドです。配布先で問題になるのはmfc100u.dllのほうです。依存名だけなら、Visual Studioのコマンド プロンプトからdumpbin /DEPENDENTSアプリ名.exeを実行しても読めます。
ただ、静的リンクを配布の常道にはしないでください。MicrosoftのRedistribute the MFC Libraryは、テストや社内配布でなら動くかもしれないと書いています。そのうえで、MFCの再頒布の手段としては勧めないとしています。外に配る本番ビルドは、再頒布可能パッケージを入れるほうが公式の道です。
「見つからない」ではなく0xc000007bで止まるとき
ここまでの手順は、mfc100u.dllのように名前を名指しで言ってくる止まり方が対象です。DLL名が出ず0xc000007bだけで止まるときは、「0xc000007bでアプリが起動しない」のほうを見てください。
まとめ
- mfc100はVC++ 2010世代、末尾uはUnicode版。どちらで止まっても、入れるのはVC++ 2010 SP1再頒布可能パッケージ。末尾dが付いていたらDebugビルドを配っている。Releaseでビルドし直す。
- 再頒布パッケージは世代ごとに別物。要るのは2010のもの。2012 / 2013や新しいv14は代わりにならない。
- パッケージのアーキテクチャはアプリの対象に合わせる。見るのはOSではなくアプリのビット数。DLL名が出ず0xc000007bだけのときは別の記事へ。
- DLLを持ち歩きたくないなら［MFCの使用］で静的リンクする（/MTは［ランタイム ライブラリ］の別のスイッチ）。ただし外部配布の公式手段は再頒布可能パッケージ。
