Windows 11 をクリーンインストールしたら、今まで使えていた .NET Framework 3.5 依存の WinForms ツールが突然起動時に落ちる——特に ZTE リチウム電池の校正ツールのような古いサードパーティアプリで、こうしたトラブルは珍しくありません。本記事では、アップグレード環境では動くのにクリーンインストール環境では落ちる原因と、現実的な解決手順を詳しく解説します。
Windows 11 クリーンインストールで .NET 3.5 アプリが落ちる典型的なケース
ここで扱うのは、ZTE リチウム電池の校正用サードパーティツール（WinForms アプリ、.NET 2.0/3.5 相当）を Windows 11 で使おうとしたところ、
- Windows 10 からアップグレードした Windows 11：問題なく起動して動作
- Windows 11 をクリーンインストールした端末：起動直後に落ちる
という現象が起きるパターンです。ログ上は、フォームのロードイベントである login_Load で System.NullReferenceException が発生しており、
mscorlib 2.0.50727System.Windows.Forms 2.0.50727
などが読み込まれているため、.NET Framework 3.5（含む 2.0/3.0）はちゃんと有効化されていることが分かります。にもかかわらず NullReferenceException で落ちるのは、多くの場合「アプリが前提としている環境がクリーンインストール環境では揃っていない」ことが原因です。
ログや状況から読み取れるヒント
| 観測された事象 | 詳細 | 示唆されるポイント |
|---|---|---|
NullReferenceException at login_Load | フォームのロード時（初期化処理）で必須オブジェクトが生成されず、null のまま使用 | 設定ファイルや外部 DLL、レジストリ値など、前提リソースが取得できていない可能性が高い |
| .NET 2.0/3.5 系アセンブリが読み込まれている | mscorlib 2.0.50727 など | .NET Framework 3.5 自体は有効化されているので、問題は別の依存関係にある |
| 実行パスに文字化け/非 ASCII 文字が含まれる | …∩%AB╡τ… のような文字列 | 古い ANSI ベースの API や外部 DLL が ASCII パス前提の場合、ファイル参照に失敗しやすい |
| アップグレード環境では正常動作 | Windows 10 から Windows 11 へのアップグレード | 旧 OS からの 設定・ランタイム・言語パックが引き継がれているため条件を満たせている |
つまり、.NET 3.5 を有効化しただけでは足りず、インストール先パス・ロケール・ランタイム・権限など複数の条件が噛み合わないと、アプリ内部の初期化で NullReferenceException が誘発されると考えられます。
想定原因の整理（優先度順）
インストール先パスの問題（非 ASCII / 長すぎるパス）
.NET 2.0 世代のアプリやネイティブ DLL では、ファイルパスを Unicode ではなく ANSI（マルチバイト）前提で扱っていることがあります。この場合、
- パスに日本語・中国語などの非 ASCII 文字が含まれる
- パスが極端に長い（MAX_PATH を超えるなど）
といった条件が揃うと、
- 設定ファイル（
.iniや.xml）が開けない - 外部 DLL を
LoadLibraryできない
などの障害が発生し、結果的に「必要なオブジェクトが生成されないまま login_Load で null アクセス」→ NullReferenceException という形で表面化します。
システムロケール／文字コード設定の不整合
ZTE ツールのような中国製アプリでは、内部で 中国語（簡体字）ロケール や中国語文字コード（GBK 等）を前提にした実装がされていることがあります。Windows 11 クリーンインストール直後は、
- システムロケール（非 Unicode アプリ用の言語）が日本語のまま
- .NET Framework 3.5 の中国語言語パックが入っていない
- もしくは「Beta: ワールドワイド言語サポートで Unicode UTF-8 を使用」が有効になっている
といった状況になっていることがあり、これが ANSI ベースの文字列処理と噛み合わず、ファイル読込や文字列操作に失敗して例外を誘発します。
VC++ 再頒布可能パッケージやドライバ不足
ツール本体は .NET アプリでも、同梱のネイティブ DLL が VC++ ランタイムに依存しているケースが非常に多いです。特に、
- Visual C++ 2008 SP1（x86）
- Visual C++ 2010（x86）
- Visual C++ 2013（x86）
- Visual C++ 2015–2022（x86）統合ランタイム
などがインストールされていないと、USB 通信系 DLL やデバイス制御 DLL がロードに失敗し、その結果として .NET 側でヌル参照が発生する、という流れがよく見られます。また、USB–シリアル変換チップ（FTDI、CH340、CP210x など）のドライバが入っていない場合も、初期化処理でこけやすくなります。
権限 / UAC・書き込み先の問題
古いアプリほど、
- 実行フォルダ直下にログや設定ファイルを書き込む
HKEY_LOCAL_MACHINEのような管理者権限必須のレジストリキーへ書き込む
といった作りになっていることがあります。Windows 11 の標準ユーザー権限ではこれらが失敗し、初期設定が完了しないままオブジェクトを使ってしまい NullReferenceException になるパターンです。
.NET Framework 3.5 の言語パックや従属機能不足
本体の .NET 3.5 機能は有効化されていても、
- 対象アプリの言語（例：
zh-CN）リソースがない - 一部の従属コンポーネントが破損・未構成
といった状態になることがあります。特にオフラインで機能を有効にした場合や、途中で Windows Update が止まっていた場合は要注意です。
解決の全体方針と優先度
時間を無駄にしないために、まずは影響度が大きく再現性が高い順番で対処していくのがおすすめです。以下の表の順に作業することで、短時間で原因を切り分けやすくなります。
| 優先度 | 作業内容 | 狙い | 目安時間 |
|---|---|---|---|
| 高 | インストール先を英数字のみ・短いパスに変更 | ANSI パス制限や長パス問題を排除 | 5～10 分 |
| 高 | システムロケールを中国語（簡体字）に変更、UTF-8 ベータを無効化 | 非 Unicode アプリの文字コード不整合を解消 | 10～20 分（再起動含む） |
| 中 | VC++ 再頒布可能パッケージ（x86）と必要ドライバを導入 | ネイティブ DLL のロード失敗を防ぐ | 20～30 分 |
| 中 | 管理者として実行＋互換モード設定 | 権限不足や互換性の問題を軽減 | 5 分 |
| 中 | .NET 3.5 を DISM で再有効化 | フレームワークの破損・不足を解消 | 10～20 分 |
| 低（最終手段） | Windows 10 / 別 VM 上での運用 | 作業を止めないための暫定回避策 | 環境構築に 30 分～ |
ステップ 1：インストール先を英数字のみ・短いパスへ変更
まずは最も効果が高いインストールパスの見直しから行います。実際に「パス変更だけで直った」ケースは非常に多くあります。
推奨するフォルダ構成
C:\ZTE\FB100C-C2\C:\Tools\ZTEBattery\
のように、以下の条件を満たすことを目標にしてください。
- ドライブ直下または 2 階層程度まで
- 半角英数字とアンダースコア、ハイフンのみ
- スペース・全角文字・絵文字などは使用しない
具体的な手順
- 現在のツールフォルダを別の場所（例：デスクトップ）にコピーしてバックアップしておく。
C:\ZTEフォルダを新規作成。- ツール一式を
C:\ZTE\FB100C-C2のようなフォルダへコピー。 - ショートカットがある場合はパスを修正するか、新規に作り直す。
- この新しいパスの EXE をダブルクリックして起動確認。
これで改善する場合、原因はほぼ パス文字列の問題と見てよいでしょう。
ステップ 2：ロケール設定と UTF-8 ベータの見直し
次に、非 Unicode アプリ用のシステムロケールと、問題になりやすい「UTF-8 ベータオプション」を確認します。
システムロケールを中国語（簡体字）に変える
ZTE ツールが中国語アプリである場合、以下の手順でシステムロケールを変更して動作確認してみてください。
- 設定アプリを開き、「時刻と言語 > 言語と地域」を開く。
- 右側の「管理用の言語の設定」をクリック（従来の「地域」コントロールパネルが開く）。
- 「管理」タブを選択。
- 「システム ロケールの変更」ボタンをクリック。
- 「現在のシステム ロケール」で中国語 (簡体字、中国)を選択。
- 必要に応じて「ベータ: ワールド ワイド言語サポートで Unicode UTF-8 を使用」のチェックを外す（詳細は次項）。
- OK を押して再起動する。
「Unicode UTF-8 を使用」オプションを無効化する
Windows 10/11 の「地域の設定」には、次のオプションがあります。
「ベータ: ワールドワイド言語サポートで Unicode UTF-8 を使用」
これは一見便利な機能ですが、古い ANSI 依存アプリでは文字コードの解釈が変わってしまい、逆に動作が不安定になることがあります。ZTE ツールのような .NET 2.0 世代のアプリでは、このチェックが入っているだけでエラーを起こすことがあるため、チェックが入っていたら外すことを推奨します。
ステップ 3：VC++ 再頒布可能パッケージ（x86）とドライバを一括導入
次に、ネイティブ DLL 周りの依存関係を一掃するため、必要そうな VC++ ランタイムをまとめて導入します。特に 32bit 版（x86）が重要です。ツール本体が 32bit 前提でビルドされているため、64bit 版だけ入っていても解決しません。
入れておきたい VC++ ランタイム（目安）
| バージョン | アーキテクチャ | 用途の目安 |
|---|---|---|
| Visual C++ 2008 SP1 | x86 | 古い組み込み系デバイスユーティリティで多用 |
| Visual C++ 2010 | x86 | .NET 2.0/3.5 世代の C++/CLI DLL など |
| Visual C++ 2013 | x86 | 比較的新しめのユーティリティ、設定ツール |
| Visual C++ 2015–2022 | x86 | 最近の統合ランタイム。念のため導入しておくと安心 |
各ランタイムは Microsoft 公式からダウンロードし、x86 版を優先してインストールしてください（必要なら x64 版も併せて）。
USB–シリアルドライバの導入
ZTE の校正ツールが USB 経由で電池やデバイスと通信する場合、以下のようなドライバが必要になることがあります。
- FTDI（FT232R など）
- Silicon Labs CP210x
- CH340/CH341 系
付属マニュアルやツールの配布サイトにドライバの記載があれば、それに従ってインストールしてください。デバイスマネージャーで「！」マークがついている不明なデバイスがある場合は、ドライバ不足の可能性が高いです。
ステップ 4：管理者として実行＋互換モードの設定
権限や互換性の問題を切り分けるため、一度 管理者権限＋互換モードで起動を試します。
管理者として実行する
- ツールの
.exeファイルまたはショートカットを右クリック。 - 「管理者として実行」をクリック。
- UAC の確認が出たら「はい」を選択。
これで動くようになる場合、アプリが
- 実行フォルダ直下に書き込み
- システムレジストリ書き込み
を前提としている可能性が高くなります。
互換モードの設定
- EXE を右クリック → 「プロパティ」。
- 「互換性」タブを開く。
- 「互換モードでこのプログラムを実行する」にチェック。
- ドロップダウンから「Windows 7」を選択。（うまくいかなければ Windows XP (SP3) なども試す）
- 「高 DPI スケール設定を無効にする」相当の項目にもチェックを入れておくと UI 周りでの不具合回避に役立つことがあります。
互換モードで動作が安定するようなら、環境変数や仮想ストア（VirtualStore）周りでの挙動の違いが影響していた可能性が高いと言えます。
ステップ 5：.NET Framework 3.5 を DISM で再有効化する
.NET 3.5 が 入っているように見える
場合でも、実際には内部コンポーネントが破損していることがあります。確実を期すため、DISM コマンドで再度有効化してみましょう。
オンラインから有効化する場合
- 「スタート」ボタンを右クリックし、「Windows ターミナル (管理者)」または「コマンドプロンプト (管理者)」を開く。
- 以下のコマンドを入力して Enter：
dism /online /enable-feature /featurename:NetFx3 /All
処理完了後、念のため Windows Update を実行し、関連更新プログラムを適用してから再起動します。
インストールメディアからオフライン有効化する場合
インターネットに接続できない、もしくはオンライン有効化でエラーになる場合は、Windows 11 のインストールメディア（ISO など）から有効化できます。インストールメディアをマウントし、ドライブレター（例：X:）を確認したうえで、管理者コマンドプロンプトから次のコマンドを実行します。
dism /online /enable-feature /featurename:NetFx3 /All /LimitAccess /Source:X:\sources\sxs
完了後に再起動し、アプリの動作を再確認してください。
それでもダメな場合の回避策：旧環境／仮想マシンの活用
ここまでの対策をひと通り行っても改善しない場合、アプリ側の実装に起因する互換性問題である可能性が非常に高くなります。その場合、現場の作業を止めないための現実的な選択肢としては次のようなものがあります。
- Windows 10（もしくは動作が確認できた Windows 11 アップグレード環境）をそのまま残して運用する
- Windows 10 の仮想マシン（Hyper-V, VirtualBox, VMware 等）を用意し、その中でツールを動かす
- ベンダー（ツール提供元）にログと環境情報を提示し、修正版や依存関係の明示を依頼する
特に、業務上どうしても必要なツールである場合、専用の「レガシー環境」VM を用意してそこで完結させるのはよく取られる戦略です。ホスト OS（最新 Windows 11）は普段使いに徹し、古いツールは VM 内で閉じた運用にするとトラブルも隔離しやすくなります。
短時間で原因を特定するための切り分けフロー
実運用では、すべての対策を一気に行うよりも、「何をしたら直ったか」を把握することが重要です。以下のような順番で試していくと、原因特定がしやすくなります。
| ステップ | 実施内容 | 結果 | 推定される原因 |
|---|---|---|---|
| 1 | パスを英数字のみの短いパスへ変更 | これだけで起動する | パス文字列（非 ASCII / 長パス）依存の不具合 |
| 2 | 管理者として実行 | 管理者でのみ起動する | フォルダ／レジストリへの書き込み権限不足 |
| 3 | システムロケールを中国語に変更、UTF-8 ベータ無効 | ここで起動するようになる | 非 Unicode アプリの文字コード前提とロケール不整合 |
| 4 | VC++ 再頒布可能パッケージを導入 | 導入後にエラーが消える | ネイティブ DLL の VC++ ランタイム不足 |
| 5 | .NET 3.5 を DISM で再有効化 | 再構成後に起動 | .NET 3.5 コンポーネントの破損・不整合 |
イベントビューアで詳細ログを確認する
原因が絞り込めないときは、イベントビューアで .NET Runtime エラーや Application Error の詳細を確認します。
- スタートメニューで「イベント ビューア」を検索して起動。
- 左ペインで「Windows ログ > アプリケーション」を選択。
- 右側の一覧から、ツールの EXE 名や「.NET Runtime」「Application Error」といったソースのイベントを探す。
- 詳細ペインで 例外情報・障害モジュール名・スタックトレースなどを確認。
ここで、特定の DLL 名やパスが表示されていれば、その DLL が見つからない／ロードできないことが原因である可能性が高いと判断できます。
アセンブリバインドログ（Fuslogvw.exe）の活用
より突っ込んだ調査が必要な場合、.NET Framework 2.0 付属の Fuslogvw.exe（アセンブリ バインド ログ ビューア）を使うと、
- アセンブリがどのパスから読み込まれたか
- どのパスの探索に失敗したか
を可視化できます。開発者向けツールではありますが、欠落している DLL を特定するには非常に有効です。
なぜアップグレードした Windows 11 では動くのか
「同じ Windows 11 なのに、アップグレードした PC では動いて、クリーンインストールした PC では落ちる」——これは直感的には不思議に感じられますが、内部的には以下のような違いがあります。
- アップグレード環境には、過去にインストールされた VC++ ランタイムや古いドライバが残っている
- システムロケールや .NET 言語パックが、旧環境からそのまま引き継がれている
- アプリが作成したレジストリキーや設定ファイルが既に存在している
つまり、アップグレード環境は「長年の積み重ね」で偶然にもすべての条件が満たされているのに対し、クリーンインストール環境は必要最低限の構成のみであり、古いアプリに必要な前提条件がすっぽり抜け落ちているのです。
そのため、「アップグレード PC では動く＝Windows 11 に完全対応している」とは限りません。むしろ本ケースのように、互換性の境界線上で辛うじて動いているだけ、ということも多い点に注意が必要です。
ZTE 電池校正ツール以外にも使えるチェックリスト
今回の内容は、ZTE のリチウム電池校正ツールに限らず、.NET Framework 2.0/3.5 世代の WinForms アプリ全般で役に立ちます。最後に、トラブルシューティング時に確認しておきたい項目をチェックリストとしてまとめます。
| 項目 | 確認内容 | OK の状態 |
|---|---|---|
| インストールパス | 全角・中国語・記号・スペースなどを含んでいないか | C:\Tools\AppName のような短い英数字パス |
| システムロケール | 対象アプリの言語に合っているか（中国語アプリなら zh-CN） | 必要に応じて中国語（簡体字）に変更済み |
| UTF-8 ベータ | 「Unicode UTF-8 を使用」のチェックが入っていないか | 古いアプリ利用時はチェックなし |
| VC++ ランタイム | x86 版の 2008/2010/2013/2015–2022 が入っているか | すべてインストール済み |
| USB ドライバ | デバイスマネージャーで不明なデバイスになっていないか | 該当デバイスにドライバが当たっている |
| 権限 | 管理者として実行したときだけ動作が変わるか | 必要であればショートカットに管理者実行を設定 |
| .NET 3.5 機能 | 「Windows の機能の有効化」で .NET 3.5 が有効になっているか | 有効化済み（必要なら DISM で再構成） |
| イベントログ | .NET Runtime / Application Error にエラーが記録されていないか | エラーがあればスタックトレースやモジュール名を確認 |
まとめ：.NET 3.5 アプリを Windows 11 で安定稼働させるために
ZTE リチウム電池の校正ツールのような .NET Framework 3.5 依存の WinForms アプリが、Windows 11 クリーンインストール環境で起動時に NullReferenceException で落ちる場合、その原因は多くが
- インストールパスにおける文字コード問題
- システムロケール・UTF-8 ベータ設定の不整合
- VC++ ランタイムやドライバの不足
- 権限や .NET 3.5 コンポーネントの不整合
といった「環境側の前提条件不足」にあります。単に「.NET 3.5 をオンにしただけ」で終わらせず、
- 英数字のみの短いパスに移動
- システムロケールを見直し、UTF-8 ベータを無効化
- VC++ 再頒布可能パッケージ（x86）と必要ドライバを一括導入
- 管理者として実行＋互換モードで動作確認
- 必要に応じて DISM で .NET 3.5 を再有効化
という流れで順番に対処していけば、多くのケースで復旧が期待できます。
ただし根本的には、これはアプリ側が現代の Windows 環境を前提として設計されていないことに起因する互換性の問題です。現場の運用上は、ベンダーに例外ログと環境情報を添えてフィードバックしつつ、必要であれば Windows 10 や専用 VM といったレガシー環境を併用して、「動く環境は動く環境として確保する」ことも大切です。
本記事のチェックポイントと手順をひと通り試しておけば、同種の .NET 3.5 アプリのトラブルにも応用できるはずです。Windows 11 クリーンインストール環境でも、レガシーツールをできるだけ安定して活用していきましょう。
コメント