家族がDynabook（T75）が立ち上がらない、と持ってきた。これを使える所まで回復したので記憶と記録を元に書き留める。なお以下の内容は、試行錯誤的な作業を数日間に渡って行った関係で時間的な流れや手順を正確に再現したものではない。
Dynabookの電源を入れてみると画面の中央にDynabookとタイルが出たままで、BIOSや回復環境へ進むためのファンクションキー（Fxx)の機能を表すメッセージが出る所まで進まず、 暫く放置していると回復環境（WindowsRE）が立ち上がるが修復関係のメニューを選んでもエラーになったりしてWindowsは立ち上がらない状態であった。なお家族によるとWindowsは更新を繰り返し当初Windos10であったものがWindows11までアップデートされたそうである。
回復環境でコマンドプロンプトを立ち上げてchkdskを実行してみると多くの時間がかかるとともに次のメッセージが出てディスク（HDD）にエラーがある事が分かる。
「破損したディスク上のアッパーケース テーブルが検出されました」
diskpart を立ち上げ list volume を実行してみると、表示にとても時間がかかってどうやらHDDが壊れているようだ。このHDDを取り出し別のPCに繋げてディスクの管理で内容を見るとC:ドライブに相当するパーティションがNTFSではなくRAWになっている。これではWindowsは立ち上がらない。
これ以上このHDDで作業してもアクセスにとても時間がかかって作業効率が悪く、さらに最悪の場合HDDを壊してデータが復元できなくなる可能性があるので先ずこのHDDのクローンを作成することとした。
同じ大きさのHDDを調達し、手持ちの Acronis True Image（2014版）付属のDVDで立ち上げHDDのクローニングを試みるもエラーがあってクローニングは不可とのメッセージで拒否される。代わりにHDDのバックアップの取得を行った(これは実行できた)。特にエラーのあるC:ドライブのパーティションはファイル毎ではなくセクター単位での取得になり、１TBのディスク全体を吸い上げるのに8時間くらいかかった。このとき進行状況の0%辺りと44%辺りがやたら遅かったので、この辺りが物理的に壊れている可能性が高い。
次にこのバックアップデータをAcronisを使って作業用の新しいHDDに書き込む（リカバリ）。その前段階として新しいディスク全体の管理方法（MBR又はGPT）を元のHDDと同じ（GPT）にする必要がある。復元は、最初はAcronisで行ったが適当にお任せでやったら各パーティションの空きスペースが圧縮され元の状態を復元できなかった。そこで予めパーティションを作成してその中にデータを流し込むこととし、別のPC(※)（以下「作業用PC」とする）のdiskpartを使って壊れたdiskから管理情報（VolumeやPartition情報）を採取した（＃）。
元のDISKの管理情報は次のようなものである。
（この表示には作業用PCを使ったため、上の表示では元のC:がE:として割り当てられている）
（Partition 2がVolumeとして認識されていないのは、Partition間の隙間だからだろう）
これらの情報からパーティション（順番、大きさ、フォーマット形式等）をdiskpart（或いは相当のツール）を使って新DISKに再現した。しかし上の表示値は丸められているので正確な値は分からず、元あった場所に狂い無くパーティションを回復することは出来なかった。このときVolume
5 (Partition 3)の属性を正しくNTFSと指定する事を忘れてはならない。
新しいディスクに管理情報を設定した後、Partition毎にバックアップデータを流し込んだ。このデータの書き込みには4時間くらい、とくに壊れているPartition 3は全セクターをベタ書きするので時間がかかった。そしてAcronisの指示通り最後にトラック0やMBRも書き戻した。これらディスクの管理情報は最後に書き戻すよう指示されているので、ツールが適当に値を修正している筈だ。これでクローン（正確にはクローンもどき）は出来上がった。以下はこのHDDでの作業である。
このディスクをDynabookに戻して起動を試みたが、いきなりエラーとなるだけで回復環境を含めて全く立ち上がらなかった（これはよくあるパターンで、普通は泣く泣くクリーンインストールするしかない）。各Partitionの位置がオリジナルと完全に一致していない事が原因かと思ったが最後に書き込むMBRはツールで修正されていると思われ、またこのDiskはGPT形式でありMBRを使っていないので関係ない筈なのだが・・・。
このディスクを作業用PCに付けるとファイルにアクセス出来るようになった（色々試みたのでこの段階で何かの復活ツールの世話になったのか思い出せない）。ただし幾つかのファイル、とくにユーザのファイルへのアクセス権が無いと怒られた。そこでユーザフォルダのプロパティを開き、セキュリティタブの中のアクセス権を編集しUsersやPowerUsersを追加した（％）。ここまで来てユーザのファイルにアクセスできるようになり、ファイルを外付けUSB-HDDに取り出す事ができた。
最後にchkdskを/fオプション付きで起動し壊れていたC:パーティションの修復を試み、それによって様々なエラーが修正された。その中には、
CHKDSK は新しいルート ディレクトリを作成します。
165 個のインデックスなしファイルがスキャンされました。
48 個のインデックスのないファイルが元のディレクトリに回復されました。
117 個のインデックスのないファイルが lost and found に回復されました。
48442 個の再解析レコードが処理されました。
マスター ファイル テーブル (MFT) のミラーでエラーを修復します。
属性定義テーブル エラーを修復します。
ブート ファイル エラーを修復します。
マスター ファイル テーブル (MFT) の BITMAP 属性エラーを修復します。
ボリューム ビットマップ エラーを修復します。
などがあった。
続く。
（※）作業用PCはDELLのLatitude D630（Core2Duo,4GB） というWindows-XP時代のPCをSSD化しWindows10に更新したものである。
（＃）SANWAのUSB-CVIDE3というSATA-USB3.0変換ケーブルを使って接続した。
（％）Windowsを十分理解していないのでこの操作が妥当であるかは分からない。ただ、Windowsの調子が悪くなった時はほぼ間違いなくアクセス権と後述の{GIUID}の問題が絡んでくる事は経験済み。
