Windows 11 25H2でコピー失敗「Invalid Function（エラー1）」の整理

本記事が扱う事象は、Windows 11（25H2系ビルド 26200.7462）環境で外付けHDD間に大容量ファイルをコピーする際、「Invalid Function」「MS-DOS error」「failed to write error:1」などの表示とともにコピーが途中失敗し、結果としてコピー先ファイルのサイズ不一致まで発生し得る、という現象です。とくにバックアップ運用では「作成したイメージを別ドライブへ複製して保全する」構成が多く、失敗が断続的に起きる点が実務上の確認点となります。 (Windows 11 Forum)

• 発生状況と再現条件として整理できる点
• 「エラー1 / Invalid Function」の意味と、コピー処理で起きうる位置
• ビルド26200.7462（25H2系）と外付けHDDコピーで論点になりやすい要素
• 切り分け手順を「観測結果→疑う層」で並べ替える
• バックアップ運用での影響と、運用設計上の落としどころ

発生状況と再現条件として整理できる点

Windows標準のエクスプローラー、xcopy、robocopy、第三者コピーソフトのいずれでも、同一環境で断続的に失敗している点が最重要です。 (Windows 11 Forum)

本記事の対象となる事象では、週次バックアップで作成した約51GBのイメージを、外付けHDD Aから外付けHDD Bへコピーする運用が前提に置かれています。2026年1月11日ごろ（スレッド開始日時が「Sunday」表記）に、TeraCopy（テラコピー）で「failed to write error:1」が出て途中失敗し、原因切り分けとしてエクスプローラーで試すと約62%で「MS-DOS error」相当のエラー表示、robocopyでは約81%で「Invalid Function」再試行に入る、という経過が記録されています。 (Windows 11 Forum)

一方で同一ハードウェア・同一USBポートでもLinuxでは成功し、ハッシュ一致やFreeFileSyncで差分なしとされている点から、「コピー手段の違い」だけでは説明しにくい構造が見えます。つまり、Windows側のストレージスタック（USB接続、ブリッジ、ドライバ、キャッシュ方式、ファイルシステム処理）で、特定条件に入ると書き込み継続が破綻する可能性が論点になります。そうすることによって、単純なアプリ不具合か、周辺機器・電力・I/O方式の相性かを分けて考えやすくなります。 (Windows 11 Forum)

「エラー1 / Invalid Function」の意味と、コピー処理で起きうる位置

エラー1（ERROR_INVALID_FUNCTION）は「関数が正しくありません」を意味し、呼び出したAPIやデバイスが要求をサポートしない場合に返るコードです。 (Microsoft Learn)

Microsoftの公開資料では、システムエラーコード1はERROR_INVALID_FUNCTION（0x1）として定義されています。これは「Windowsが何らかの“要求された機能”を実行できない」ときに返り得る値で、アプリ側の指定、ドライバ、ファイルシステム、デバイス側の機能対応など、層のどこで不整合が出ても表面化し得ます。要点を整理すると、「コピー＝単一の仕組み」ではなく、API呼び出し→I/O方式→デバイス処理の連鎖で成立しているため、途中で非対応や異常応答が起きると同コードになる、という位置づけです。 (Microsoft Learn)

なお、Windowsのファイルコピー実装は内部でCopyFileExなどのAPIや、キャッシュ／非キャッシュI/O、再試行、検証など複数の経路を取り得ます。別分野の事例ですが、CopyFileEx起点でERROR_INVALID_FUNCTIONが出る報告（特定ファイル種や特殊属性、クラウド同期フォルダなど）もあり、コード自体は「原因を直接示す」より「失敗した層の候補を広く残す」性格が強い点は押さえる必要があります。ためえ、表示文言が同じでも原因の層は一致しないケースがあります。 (FreeFileSync.org)

ビルド26200.7462（25H2系）と外付けHDDコピーで論点になりやすい要素

同じコピー対象でもWindows側だけで不一致が出る場合、USB接続（電力・ブリッジ・転送方式）と書き込みエラー処理の相互作用が主要論点になります。 (Windows 11 Forum)

本記事が前提とする条件では、Windows 11のビルドは26200.7462で、これは2025年12月9日付の累積更新（KB5072033）に紐づくOSビルドとして案内されています。したがって、時系列としては「更新適用後の25H2系ビルド環境で現象が観測された」整理が可能です。 (Microsoft サポート)

ただし、コピーが止まるタイミングが一定でない点、複数ツールで同様に失敗する点、Linuxでは成功する点を踏まえると、OS更新だけを単独原因と断定する材料は不足します。そこで構造的な論点として、(1) 外付けHDDへの給電不足やUSBハブ／ドックの品質差、(2) USB-SATAブリッジのコマンド対応差（大容量連続書き込み時のエラー応答）、(3) Windows側の書き込みキャッシュや再試行の挙動、(4) NTFS上の巨大単一ファイルを長時間連続転送する際のエラー処理、が候補になります。

実際に当該スレッドでは、外付けHDDの電力供給不足を仮説とし、セルフパワー（外部電源）付きUSB 3.0ハブの利用で問題が解消したという趣旨の指摘が提示されています。言い換えると、Windowsは書き込みエラーを検出した際に「関数が正しくありません」へ落ちる経路があり、Linux側は別の再試行やI/O経路で完走する可能性が残ります。以上を踏まえると、OSと周辺機器の組み合わせとして評価する視点が判断材料になります。 (Windows 11 Forum)

切り分け手順を「観測結果→疑う層」で並べ替える

コピー手段を増やすより、「どの層で破綻しているか」を観測で固定する設計が重要です。 (Windows 11 Forum)

本記事で整理する論点は、症状が「コピー失敗」に見えても、(A) コピー途中で停止する、(B) コピーが完了したように見えるがサイズやバイナリ比較が一致しない、の2系統が混在している点です。後者はバックアップの保全性に直結するため、単純な再試行ではリスクが残ります。そこで、観測できる情報を軸に、疑う層を並べ替える整理が実務上の確認点になります。 (Windows 11 Forum)

この表の使い方としては、まず「どの現象に該当するか」を固定し、次に層を一段ずつ変えて差が出る点を探す整理になります。たとえば、ドックやケーブルを変えると改善する場合は周辺機器・電力寄り、同一周辺機器でも別PCで再現する場合はOS・ドライバ寄り、という見立てが可能です。一方で、Macrium Reflectなどバックアップ製品側にも「Invalid Function」系の不具合修正が過去に案内されており、バックアップ作成と“複製”を同一品質として扱わない運用設計も論点になります。 (Macrium Updates)

バックアップ運用での影響と、運用設計上の落としどころ

バックアップイメージの複製で不一致が出た場合、保全性は「複製の成否」ではなく「検証の成否」で評価する必要があります。 (Windows 11 Forum)

本記事の対象テーマは、OSバックアップ自体の作成ではなく、作成済みイメージを複数メディアへ複製する段階で破綻している点にあります。この段階は、バックアップソフトが内部整合性（検証、セクタ読み戻し、CRC等）を取りやすい工程ではなく、汎用コピーの信頼性に依存しやすい工程です。そのため「コピーが完了した」という事実だけでは、復元可能性の判断材料として不足します。 (Windows 11 Forum)

同スレッド末尾では、バックアップイメージを別ドライブへコピーした個体が復元時に失敗した経験談が述べられており、複製工程の品質管理が課題になることが示唆されています。これは、(1) 複製後に必ずハッシュやバイナリ比較を通す、(2) 複製ではなく「別メディアへ改めてイメージ作成」する運用も併置する、(3) 周辺機器（USBドック、ハブ、給電）の構成を固定し、異常が出る組み合わせを排除する、といった設計論へ接続します。ここで重要なのは、手段の推奨ではなく、失敗が断続的に起きる構造では「検証を通ったコピーのみを保全対象とする」考え方が合理的になる、という整理です。以上を踏まえると、Windows 11 25H2系ビルドで同様の表示に遭遇した場合でも、OS不具合と周辺機器要因を分けて記録し、保全性を検証結果で管理する枠組みが判断材料として重要です。 (Windows 11 Forum)