Raspberry Pi 3 B+ で Windows 10 IoT Core を再開しようとしたところ、IoT Dashboard 起動直後に「URLDownloadToCacheFile failed with HRESULT ‘-2146697211’」が出て先へ進めない――そんな相談が増えています。本記事はエラーの正体、再現の背景、短期の復旧手順から中長期の移行戦略までを、現実的な選択肢と具体的な手順で徹底解説します。
目次
Win 10 IoT Dashboard 起動時のエラー（HRESULT -2146697211）の正体
表示されるメッセージ
URLDownloadToCacheFile failed with HRESULT '-2146697211'
エラーコードが意味するもの
数値 -2146697211 は 16 進表記で 0x800C0005、WinINet／URLMon 系の定数 INET_E_RESOURCE_NOT_FOUND に相当します。つまり「ネットワークに接続できない」のではなく、要求した URL のリソースが見つからない／移動していることを示します。IoT Dashboard は起動直後に必要な構成・マニフェスト・OS/ツールのパッケージを既定の配布元（例：iottools で始まる Azure Blob ストレージのホスト）から取得しますが、この配布元のパスやファイルが既に有効でない場合、当該エラーが発生します。
なぜ今、発生が増えているのか
- 配布元の整理・アーカイブ化：Dashboard が参照する既定の ClickOnce マニフェストやパッケージの格納先が整理・移設・提供終了され、参照が 404（または同等）になっている。
- 証明書・TLS の変化：古い実行環境では TLS 設定やルート証明書の更新遅延により HTTPS ハンドシェイクに失敗し、結果として取得不能になるケースもある。ただし本件の HRESULT は主因が「リソース無効化」の場合に最も整合します。
- Dashboard 自体の陳腐化：ClickOnce アプリである Dashboard は、内部の更新 URL・マニフェスト署名の前提が変わると自動更新すら始まらず、初期ダウンロードで停止します。
Windows 10 IoT Core の現状と前提整理
Raspberry Pi 系で使われた Windows 10 IoT Core の最終世代は 2019 LTSC（ビルド 17763／1809 系）です。UWP を主体とするこのエディションは長期の機能拡張がなく、公式の配布物・周辺ツール（IoT Dashboard 含む）も更新が停止しています。現時点で「新規プロジェクトの開始」や「最新ボードへの積極的な移行」は推奨されません。既存資産を維持する場合は、入手済みイメージとツールをオフラインで保全する運用が現実解になります。
重要：Windows IoT Enterprise と Windows 10 IoT Core は別製品です。Raspberry Pi は IoT Enterprise の公式サポート対象ではありません（一部コミュニティの試行はあるものの、量産・保守の前提にはなりません）。IoT Enterprise を使う場合は、インテル系小型PCや産業用ボードなど公式にサポートされるハードウェアを選定してください。
すぐにできる復旧・回避策（短期対処）
方針の見取り図
| 目的 | 具体策 | ポイント／リスク |
|---|---|---|
| IoT Dashboard を使い続けたい | 既にインストール済みの PC からClickOnce 実体の複製を試す | 応急処置。ユーザーごとのハッシュ パスにあり互換保証はない。検証環境でのみ推奨。 |
| GUI なしでフラッシュしたい | DISM の /Apply-FFU または PowerShell スクリプトで SD カードへ手動書き込み | Dashboard 不要。誤ドライブ指定に注意。オフライン運用可。 |
| 既存機を最小変更で復活させたい | 保全済みの FFU イメージ（Raspberry Pi 3 B+ 対応）と Device Portal を併用 | 最終ビルド 17763 系を確保・再利用。ネット未接続でも動作可。 |
手順A：ClickOnce の複製（自己責任／応急）
- Dashboard が動いていた PC を用意し、次のようなパスを探します。
C:\Users\<User>\AppData\Local\Apps\2.0\配下のハッシュ フォルダーにWindows10IoTCoreDashboard.exeなどの実体があります。 - 当該フォルダー一式を ZIP 化し、対象 PC に展開します。
- 展開先で EXE を直接実行します。
※ ClickOnce の性質上、マシンやユーザーが変わると 実行不可のことが多く、完全な解決にはなりません。署名・更新先が無効のままでは将来的に破綻します。
手順B：DISM で FFU を直接書き込む（推奨）
Dashboard を使わずに、入手済みの FFU イメージ（Raspberry Pi 3 B+ 対応）を SD カードへ直接適用します。
- 管理者の PowerShell またはコマンド プロンプトを開く。
- SD カードを挿入し、
Get-Diskなどで 物理ディスク番号を確認。誤指定するとデータ消失します。Get-Disk | Sort-Object Number | Format-Table -Auto - DISM の
/Apply-FFUを使用して FFU を適用。dism.exe /Apply-FFU /ImageFile:"D:\Images\RPI3Bplus.ffu" /ApplyDrive:\\.\PhysicalDrive<span>2</span>※PhysicalDrive2は例。実際の番号に置き換えてください。 - 完了後、安全な取り外しを行い、Raspberry Pi 3 B+ に SD カードを装着して起動。
手順C：PowerShell スクリプトでの書き込み（代替）
IoT Core のパッケージに含まれていた Apply-BootMedia.ps1 と同等のロジックを用いれば、DISM を内部呼び出ししてフラッシュできます。
PowerShell -ExecutionPolicy Bypass -File .\Apply-BootMedia.ps1 `
-Image .\RPI3Bplus.ffu `
-Drive \\.\PhysicalDrive2 `
-Verbose
スクリプトは対象ディスクのクリーン・パーティション作成・ブート セクター設定といった前処理を自動化してくれます。（企業利用ではソースを精査し、ハッシュや署名の検証を必ず実施してください）
Dashboard なしでの配備・開発のポイント
- Windows Device Portal：既知の デバイス IP:8080（IoT Core 既定）にブラウザからアクセスできれば、アプリの sideload／ログ取得／再起動が可能です。ネットワーク分離環境でも運用できます。
- Visual Studio からのデプロイ：UWP アプリは「リモートマシン」デバッグ構成で IP 直指定が可能です。Dashboard の「ペアリング」なしでも到達できれば展開できます。
- アプリの自動起動：IoT Core の Device Portal → Apps で Startup に設定するか、プロビジョニング パッケージで既定アプリに設定します。
Raspberry Pi 3 B+ を使い続ける場合の実務指針
最低限、これだけは確保する
- 最終 FFU イメージ（RPI 3 B+ 対応／17763 系）のバックアップ（複数媒体・ハッシュ付き）。
- 当時の DISM（Windows 10 1809 以降に付属）または動作確認済みのフラッシュ スクリプト。
- UWP アプリの AppXBundle と依存 Framework パッケージ（.NET Native／VCLibs 等）一式。
- 運用手順書：再フラッシュから初期設定、Device Portal へのアクセス手順、アプリの再配置手順を 画面ショット付きでオフライン保管。
障害切り分けチェックリスト
| 観点 | 確認方法 | 期待値／対処 |
|---|---|---|
| エラー種別 | HRESULT が 0x800C0005（-2146697211）か | ＝リソース未検出。URL の生存／代替配布元の有無を確認 |
| 名前解決 | nslookup 等でホストが解決するか | 解決不可なら hosts／DNS／プロキシを点検 |
| TLS／証明書 | certmgr.msc でルート証明書の更新状況 | 古い環境はルート更新・TLS 既定の見直し |
| ネットワーク | プロキシ越しの ClickOnce 通信制限の有無 | プロキシ例外に対象ホストを入れるか、オフライン運用に切替 |
中長期の開発方針（現実解）
選択肢1：IoT Core をオフライン保守（限定継続）
- FFU と AppX を社内アーカイブで保全し、再現性の高いフラッシュ手順を自動化（PowerShell で
dism呼び出し）。 - 展開は USB 起動キットか PXE/WinPE を使い、完全にネットワークに依存しないパイプラインを構築。
- 計測・制御の I/O は既存のドライバ層を変えないことを最優先に、アプリ面の変更を最小化。
選択肢2：Linux（Raspberry Pi OS 32bit / Ubuntu 20.04 armhf）＋ .NET で再構築
UWP 依存が薄い場合、.NET 8 の linux-arm で Web UI／サービス化を行うのが堅実です。Raspberry Pi 3 B+ でも軽量構成なら十分運用可能です。 最小サンプル：Kestrel 常駐（systemd）
# /etc/systemd/system/myapp.service
[Unit]
Description=My .NET IoT App
After=network-online.target
Wants=network-online.target
[Service]
WorkingDirectory=/opt/myapp
ExecStart=/usr/bin/dotnet /opt/myapp/MyApp.dll
Restart=always
RestartSec=5
Environment=DOTNET_ENVIRONMENT=Production
[Install]
WantedBy=multi-user.target 選択肢3：Azure IoT Edge＋コンテナで段階移行
- 現行 UWP ロジックを Web API／Worker に切り出し、Docker イメージ化して配布・更新を制御。
- フィールド更新は モジュールごとに差し替え可能。接続断時はローカル キューでバッファリング。
- MQTT／AMQP、時系列 DB、Node-RED と並べる ポリグロット構成が取りやすく、将来のボード交換にも強い。
選択肢4：UI を伴う製品は MAUI／Uno／Web 化
| 選択肢 | 強み | 移行コスト | 向き・不向き |
|---|---|---|---|
| .NET MAUI | ネイティブ UI／マルチプラットフォーム | UWP→XAML 置換が比較的自然 | 軽量 SoC では要チューニング |
| Uno Platform | UWP/WinUI XAML を最大活用 | UWP 資産の再用率が高い | ブラウザ主体なら WebAssembly も可 |
| Web（ASP.NET Core + WebUI） | 端末レス／配布容易／保守しやすい | ハード直結 UI は工夫が必要 | デバイス UI を遠隔操作する用途に最適 |
UWP 依存コードの棚卸しと置き換え方針
API／機能の対応表（要点）
| UWP 機能 | 置き換え先（Linux/.NET 8 例） | 備考 |
|---|---|---|
| GPIO / I2C / SPI | libgpiod / pigpio / System.Device.Gpio | ユーザ権限・udev 設定に留意 |
| BackgroundTask | systemd サービス / Cron / Worker Service | ログとヘルスチェックを標準化 |
| App Services | gRPC / REST / MQTT | プロセス間通信をネットワークフレンドリーに |
| Device Portal への依存 | SSH / Ansible / 自社 OTA | 構成管理一元化で再現性確保 |
テスト観点
- ハード抽象化：I/O 層をインターフェース化し、実ハードなしでユニットテストできるようにする。
- タイミング：RT 性は割り切り。必要なら外付け MCU によるオフロードを検討。
- ロギング：UWP の
EventSourceをSerilog/ILoggerに統一し、収集を容易に。
よくある誤解と注意点
- 誤解：HRESULT -2146697211 は「接続不可（CANNOT_CONNECT）」を意味する。
正しくは： INET_E_RESOURCE_NOT_FOUND（リソース未検出）。接続そのものではなく、配布物が存在しない／移動したことが主因です。 - 誤解：Raspberry Pi 4 なら Windows IoT Enterprise に簡単に移行できる。
正しくは：Raspberry Pi は IoT Enterprise の正式対象外。公式サポートのある x86/x64（または特定 ARM64）ボードへのハード移行が前提です。 - 注意：ネット上に残る旧 Dashboard インストーラーの再配布物には改ざんリスクがあります。ハッシュ検証と電子署名の妥当性確認を必ず行ってください。
運用を楽にする小技・定型化の例
フラッシュ工程の標準スクリプト（例）
PowerShell：SD 書き込みとアプリ展開まで一気通貫
# Admin PowerShell
param(
[Parameter(Mandatory=$true)][string]$FfuPath,
[Parameter(Mandatory=$true)][int]$DiskNumber,
[Parameter(Mandatory=$false)][string]$AppxBundle,
[Parameter(Mandatory=$false)][string[]]$Deps
)
Write-Host "=== Apply FFU ==="
dism.exe /Apply-FFU /ImageFile:"$FfuPath" /ApplyDrive:\.\PhysicalDrive$DiskNumber | Write-Output
if ($LASTEXITCODE -ne 0) { throw "DISM failed." }
Write-Host "=== Post Image Tasks ==="
# ここで既定の Wi-Fi 設定や構成ファイルを SD の Data パーティションにコピー
# Copy-Item -Recurse -Path .\provisioning* -Destination E:\
if ($AppxBundle) {
Write-Host "=== Sideload App ==="
# Device Portal API で AppX を送る／SSH 経由で展開 など、自社標準に合わせて実装
}
Write-Host "Done." 障害時の情報採取テンプレ
- Dashboard 画面のスクリーンショット（エラー全文）。
- イベントログ：Applications and Services Logs → Microsoft → Windows → Application-Experience/Program-Compatibility-Assistant 等。
- ネットワーク：HTTP ステータス／DNS 解決結果／プロキシ設定。
- 検証に使った FFU のハッシュ（SHA-256）。
ハードウェア更新の現実解（Raspberry Pi からの卒業を見据える）
5〜7 年スパンの製品保守を見込むなら、入手性・長期供給・公式 OS サポートを優先して選定します。
| 方向性 | ハード候補 | メリット | 留意点 |
|---|---|---|---|
| Windows IoT Enterprise | 産業用 x86 小型PC、Intel N シリーズ、組込み SBC | AD/Defender/MDM 等と親和性が高い | コスト高めだが保守の読みやすさは高い |
| Linux + コンテナ | ARM SoC ボード全般（Raspberry Pi も可） | スケールしやすい／将来のボード交換が容易 | カーネル・ドライバの互換テストが必要 |
ケーススタディ：既存 UWP 資産を最短で延命しつつ、並行で再構築
- 延命ライン：オフライン FFU で現行機を復旧。Portal 経由で AppX 更新。
- 移行ライン：同機能を .NET 8 + Web API + Web UI で新規実装。I/O は抽象化し、Raspberry Pi OS でも x86 小型PC でも動く構成に。
- 切替：新旧を現場で A/B 運用し、データは同じバックエンド（MQTT／REST）へ送る。安定した時点で旧ラインの更新を停止。
この「二重化」アプローチなら、現場停止時間を最小化しながら技術的負債を段階的に解消できます。
トラブル復旧フローチャート（簡易）
- エラーコード確認：
-2146697211か → YES - Dashboard 依存をやめる判断 → FFU と DISM を準備
- SD へ
/Apply-FFU→ 起動確認 - UWP AppX 再配置 → Device Portal で常駐化
- 中長期の移行計画を承認 → PoC 開始
安全のためのベストプラクティス（チェックリスト）
- ハッシュ管理：FFU／AppX／スクリプトは SHA-256 を併記。入手元が不明なバイナリは使わない。
- 権限分離：フラッシュ用アカウントと通常運用アカウントを分ける。
- 再現性：実行環境（Windows ビルド、DISM バージョン、PowerShell バージョン）を記録し、同一環境で作業。
- バックアップ：SD は最低 2 枚以上に複製。現場にも予備を常備。
- 監査ログ：誰がいつどの FFU を適用したかを残す。
まとめ
- 結論：「URLDownloadToCacheFile failed … -2146697211」は INET_E_RESOURCE_NOT_FOUND、すなわち配布リソースの消失・移動が原因で発生するのが本質です。
- 短期対処：IoT Dashboard に依存せず、DISM /Apply-FFU でオフライン書き込みに切り替えるのが最も確実です。
- 継続運用：FFU と AppX の社内保全、Device Portal／Visual Studio を併用したデプロイで十分延命可能です。
- 将来戦略：UI を伴わない部分はコンテナ化、UI は MAUI/Uno/Web 化で .NET 8 + Linux へ段階移行するのが堅実。Windows IoT Enterprise を選ぶ場合は、公式サポート対象ハードを採用してください。
「いま動かす」と「数年後も困らない」を両立するには、Dashboard という一点に依存しない配備パイプラインを作ることが近道です。本記事の手順と方針を土台に、まずは FFU のオフライン再配備から着手してみてください。
コメント