FastCopyが突然フリーズ（コワークドライブ）

[sano-yasunori]

質問
2024年11月にライセンスを購入させていただき使い始めたところです。
現象としましては、同期の設定で動作をさせているとFastCopyが突然不定期にフリーズしていまい、その後はWindowsが反応しなくなり強制再起動に陥ってしまいます。解決に向けてアドバイスをお願いします。何をお伝えすればいいかあまりわからないので、とりあえず備考に環境や状況の詳細等をお知らせします。追加で必要な情報がありましたらお知らせいただけますと幸いです。よろしくお願いします。

備考
FastCopyインストールパソコン
NEC Mate タイプML（デスクトップ型）
型番：PC-MKH48L97AG2J
Windows11 Pro、Intel Corei7-12700、Memory 16GB、SSD-512GB
ポータブルUSB-SSD：BUFFALO SSD-PHP1.0U3BA/N
クラウドストレージ：NTT東日本の「コワークストレージサービス」を利用
※ツール（コワークドライブ）をインストールするとドライブマッピングされ、Zドライブとして表示されます
FastCopyの用途としましては、クラウドストレージのデータをローカルにバックアップすることを目的にしています。

FastCopy
Source：クラウドストレージ（CoWorkStorage）の共有フォルダをドライブマッピング（Z:￥全社共有）
DesDir：FastCopyをインストールしたパソコンにUSB-C接続した外付けしたBUFFALO社製のSSD（Ｅ:）
モードは同期で、その他の設定はデフォルトから変更していません。
容量は約550GBでSource直下の20個程度あるフォルダを小分けして実行し、フリーズしてしまったらPCを強制再起動して同期転送を再開しました。その後、数日かけて何とか一度フルバックアップ（転送）が完了し、現在は1日1回、4時間程度で同期を行っているのですが、初期同様、時々フリーズしてしまう状況です。

[shirouzu]

類似の報告は効いたことが無いですね…FastCopyはMSが提供する標準ファイル操作APIで動作しています。（CreateFileやWriteFileなどのAPI群）
従いシステム全体のフリーズやBSODが起きる場合は、ハードウェア・OS・ドライバーの問題の可能性が高いです。

今回で一番疑わしいのは、お使いのコワークドライブに見えます。
専用ドライバがインストールされ、標準のファイル操作APIの要求をトラップして、通信に変換してるのだと思いますが、その中で問題を起こしているのであれば（ドライバ=OS内部）、システム全体がハングすることもあり得ますね。

ただ難しいのは、提供ベンダ側に問い合わせても「非標準のソフトを使っているためでは？」と逃げられやすいことです。
robocopy などのOS標準装備のツールを使って、現象を再現させて問い合わせると良いかもしれません。

あとはフリーズ直前のイベントビューアを参照して、怪しいログが無いか調べるとか、信頼性モニターを見てみるとかでしょうか。
（ただBSODと違い、フリーズの場合は足跡が残りづらい…）
https://forest.watch.impress.co.jp/docs/shseri/win10minor/1137563.html

[sano-yasunori]

早速の返信ありがとうございます。
やはりコピー元のコワークドライブが原因の可能性があるということですね。
事象が発生した時点のイベントビューアにはこれといってエラー表記は出ていない状況です。
FastCopyがフリーズすると、一緒にマウスのウインド操作もできなくなり、通常のシャットダウンもできません。
先ずはアドバイスいただきました robocopy 等で検証してみたいと思います。
ちなみに、コワークドライブアプリをインストールしない場合はブラウザでアクセスする方法になるのですが、その状態で FastCopy で、データをローカルにコピーする方法はありますでしょうか。

[shirouzu]

当該ソフトのことは良く知らないのですが、FastCopyのSource/DestDirボタンから見えない/選べない＝標準ファイルAPIで操作できないわけで、コピー等はできないかと思います。

もしWinDbg等で解析する技術をお持ちでしたら、下記のような方法でクラッシュダンプを取って解析すると何かがわかる可能性はあります。
https://learn.microsoft.com/ja-jp/windows-hardware/drivers/debugger/forcing-a-system-crash-from-the-keyboard

[sano-yasunori]

情報ありがとうございます。

[sano-yasunori]

検証のために別のWindows11のパソコンを用意し、クラウドストレージサービス「コワークストレージ」のコワークドライブをインストールして、ドライブ(Z:)としてアクセスできるようにしてから、アドバイスいただきました「robocopy」で、バックアップ対象の全体の１割（50GB程度）を対象に、同期バックアップ（/MIR）を、2日かけて数回試してみましたところ、特に問題は発生せず正常に動作しました。
その後、そのパソコンに、約550GBのバックアップの取れている外付けのUSB-SSDを接続し、FastCopyをインストールして動作モードを「同期（サイズ・日付）」で、あらためて動作検証を行っております。現在のところ6回ほどFastCopyを動作させ全て正常に終了しています。1回の動作に約3.5～4時間を要します。当初の事象は発生していませんので、今のところ、事象の発生したパソコン又は、コワークストレージサービスに起因するものではないかというところですが、今しばらく検証を続け様子を見たいと思います。取り急ぎご報告いたします。
検証用パソコン：HP EliteBook 830 G5, Windows11(24H2), Intel Core i5-7200, Mem 16GB, SSD 256GB

[sano-yasunori]

検証中に別の事象が発生してしまいました。
7回までは順調でした。同様に8回目を行った際、それでまは同期モードで数十から数百程度のファイル処理（Write & Del）だったところ、ログを確認すると、TotalDelが353GB、DelFilesが287,117となっており、全550GBの約6割強のファイルが、指定したDestDir（バックアップ先のフォルダ）から削除されました。実際にSourceから削除されているのかを確かめたところ、ファイルは存在していました。検証中FastCopyの設定は変更してしていません。8回目の最終ログは以下の通りです。

=================================================
FastCopy(ver5.8.0) start at 2024/12/19 15:00:01
<Source>  Z:\全社共有
<DestDir> E:\コワークストレージバックアップ
<Command> 同期（サイズ・日付）
<JobName> CoWorkStorage_Backup
-------------------------------------------------
～ファイルリストは大量のため割愛します
-------------------------------------------------
TotalRead  = 11 MiB
TotalWrite = 11 MiB
TotalFiles = 7 (0)
TotalSkip  = 191,714 MiB
SkipFiles  = 107,042 (0)
TotalDel   = 353,536 MiB
DelFiles   = 287,117 (29,731)
TotalTime  = 59:38
TransRate  = 0.00 MB/s
FileRate   = 0.00 files/s

Result : (ErrFiles : 0 / ErrDirs : 0) at 2024/12/19 15:59:39

---

FastCopyからはログが出力され終了しているので、続けて8回目を実行しています。
予想通り、DestDir（バックアップ先のフォルダ）から削除されたファイルをコピーしています。
この状況については、何が原因なのでしょうか。
調査に必要なものは、できるだけ提供しますので、調査/対応をお願いいたします。
※当初の事象とは違う内容になるので、別スレッドの方がいい場合はご指示ください。

[shirouzu]

過去に類似報告を聞いたことが無いのですが、特定フォルダ配下がすべて削除、といった状態でしょうか？
（ログでパターンをご確認ください）
ありうるとすると…たとえば Sourceが共有ボリュームだとして、ネットワーク障害等で、Sourceフォルダの内容の一部が一時的に読み取れず（空に見えた）とかですかね…普通は考えづらいですが。
当該時間中に、イベントビューア（Sourceが共有ボリュームであればサーバ側も）に障害などのイベントなどが記録されていないかも確認してみてください。

[shirouzu]

追記：
ソースコードを念のため確認しましたが、Sourceのフォルダ内容の列挙に「失敗」した場合（FindFirstFileExW/FindNextFileW APIがエラーを返した場合）、エラーログに出力した上で当該フォルダはスキップする形になっているので、これらの列挙APIがエラーと報告せずに空内容を返す、などがなければ（削除は）考えづらい挙動ですね。

上記コメント時、ちょっと勘違いしていましたが、Sourceが例の「コワークストレージ」なのですね。
うーん、正直このドライブでは、上記のような厳密なAPI動作（列挙エラー時に空ではなく、きちんとエラーを返す）を守っていない可能性があるかもですね。
（しばらくは robocopy /MIR でも動作実験したほうが良い気がします。ファイル列挙中にネットワークケーブルを抜いてテストする等）

[sano-yasunori]

Q：特定フォルダ配下がすべて削除、といった状態でしょうか？（ログでパターンをご確認ください）
A：多数のフォルダにわたって削除されています。2024/12/19 15:00-15:59に実行したFastCopyのログには約30万行があり、ほぼ全てがdel(-)行です。
　---
Q：当該時間中に、イベントビューアに障害などのイベントなどが記録されていないかも確認してみてください。
A：イベントビューアーWindowsログを確認しました。システムの「警告」が1件のみでした。下記に記載します。また、Aplicationは「エラー」「警告」共に1つもありません。
　---

ログの名前: System
ソース:Microsoft-Windows-Kernel-Processor-Power
日付:2024/12/19 15:44:21
イベント ID:37
タスクのカテゴリ:(7)
レベル:警告
キーワード:         
ユーザー:SYSTEM
コンピューター:DESKTOP-8IAI884
説明:グループ 0 のプロセッサ 3 のスピードはシステム ファームウェアによって制限されます。プロセッサは、最後のレポート後 86399 秒間このパフォーマンスが制限された状態にあります。

　---
Q：Sourceが共有ボリュームであればサーバ側も確認
A：残念ながらクラウドサービスのため、確認することができません。
　---
※この件の検証を継続するにしても、先ずは削除されてしまった350GB近くのバックアップを取得するのに（現在実行中）、クラウド側のレスポンスが遅いためか数日かかります。また検証した robocopy /MIRでは、4GB/ファイル数3179のフルバックアップ後の動作（ファイル転送がなくても）で、5分かかるため、ざっくり550GBで12時間かかる想定は、ちょっと実用的ではないと考えております。FastCopyの場合は3.5時間程度で完了していましたので、FastCopyを利用した環境で進めたいと考えています。
　---
クラウドサービス側に何か確認することがありましたらこちらから問い合わせますので、ありましたらお知らせください。

以上です。引き続きよろしくお願いいたします。

[sano-yasunori]

また、FastCopyで検証中のログの中には、Write/Del 以外に以下の情報が確認できました。
　---

OpenFile(この操作を完了できませんでした。再実行してください。1237) 
ReadFile(システムに接続されたデバイスが機能していません。31)
ReadFile(アクセスが拒否されました。5)

※上記メッセージのあともログは記録されどちもバックアップは完了しています。

[shirouzu]

ファイルI/Oでは明示的なエラー（テンポラリエラーの類が多いようですが）が出ることもあるようですね。
ともあれ、フリーズの件と言い、Win32ファイルAPIとしての信頼性が足りず、FastCopyでのご利用はお勧めできない印象です。
不安定なハードウェア（PCやSSD）をお使いの場合には「まずは信頼性のあるハードウェアを整備してからご質問を」と返信するのですが、それと同様に、この手の特殊なドライバの不安定さに起因する問題には、こちらとしても対応は難しいですね。

robocopy /MIR を使っても、おそらく何十回に一度か、類似の障害が発生するでしょうから、その際のログをもってドライバ開発元に修正を求める、などのアプローチくらいしか、根本的な改善は望めないのではないでしょうか。
（どうしても使いたい場合は、完全ベリファイ付きの差分コピー＋ログを毎回確認して、だましだまし使うとかですかね…）

[sano-yasunori]

色々とご確認いただきありがとうございます。
コワークストレージサービス（NTT東日本）のサポート窓口に問い合わせてみましたが、クラウドからローカルにまとめてファイルを転送することに関して、提供サービスのサポート範囲外とのことで残念ながら一歩も進みませんでした。コワークドライブでアプリケーションを提供しているのに、それらを使っての動作に関しては全くのノンサポートでした。サポートはコワークストレージの操作範囲内だそうです。サービスの管理者メニューにあるログについても確認しましたが、操作系のログは色々とあるものの、接続や切断などのシステム系のログはありませんでした。
　---
こちらも考えていましたが、ファイル転送先のデータが削除されてしまったことの対策としては、FastCopyの同期モードをやめて差分モードで行う方法を選択するしかないようですね。現在同期モードで実行中（だいぶかかりますが...）なので、ファイル転送が終わり次第、差分モードで動作検証を行ってみたいと思います。