HP PavilionラップトップにプリインストールされたWindows 8.1を回復する際の悪い経験

背景

数週間前、私はWindows 8.1がプリインストールされたHP Pavilion p170nrラップトップの所有者になりました。 私は熱心なLinuxユーザーであるため、メインの正常なUbuntuシステムをインストールすることに決めましたが、WindowsをおもちゃやBIOSの更新などの不機嫌なものに残しました。 欲も役割を果たした-8のために、実際には、支払われたお金。



最初のステップは、ディスクスペースを解放することでした。 Microsoftの遺産によると、システムは単一のCドライブですべての利用可能なスペースを占有し、GoogleはWindowsが最終的に通常のツールを使用してドライブのパーティションを再分割する方法を学習することを提案しました。 しかし、判明したように、Cドライブは半分しか削減できません。 その後、いくつかの「移動しないファイル」が来ましたが、Windowsはそれらを移動することを断固として拒否しました。 「再配置不可能なファイル」は、ロールバックポイントおよびスワップファイルでした。 それらを削除してスワップをオフにした後、ディスクを100GBにトリミングするプロセスを開始することはできましたが、数秒の作業の後、「メモリが足りません」というダイアログボックスが表示されました。 どのメモリ、どこで、何のために-報告されていません。 ディスクには断片化する時間があまりなく、なぜメモリがまだ必要なのか、私には謎があります。



何らかの種類のパーティションマネージャーを使用する必要があり（正確な名前は覚えておらず、まだ認識していません）、Windows 8で動作することを約束しましたが、その結果、システムパーティションが強制終了されました。 さらに、それとリカバリ用のイメージを含むセクションの両方が完全にありますが、私はそれを操作しませんでした。



当然、ラップトップでシステムを復元するものは何もありませんでした。 後でわかったように、HPはそれらを個別に販売しています。 そして、私は自分でこのようなものを作成することを気にしませんでした。



SystemRescueCDが助けになりました。 fdiskとtestdiskを使った操作での浮き沈みについては説明しません。 しかし、出力はこれと同じ構造を得ることができました







すべてのファイルが適切に配置されているようです。 testdiskは、WindowsとMSRを除くすべてのセクションの内容を正しく表示しました。 Windowsの問題は、明らかに、パーティションの非常に大きなサイズにありました（セグメンテーションフォールトで落ちました）が、MSRが何であるか理解できませんでした。 ファイルシステムがなくても、何かを保管するだけのようです。



ただし、システムは起動を拒否しました。 番号付きエラー（0x00000025など）を発行し、リカバリツールを起動しようとした後、メッセージが「ファイル\ windows \ system32 \ winload.efiが破損または欠落しています」に変更されました。



Windows 8.1 PEイメージをダウンロードし（rutracker.ruで準備ができていることがわかりました）、ブートローダー、イメージ、およびその他の低レベルの詳細の調査に飛び込む必要がありました。 次のすべてが私の研究の成果であるため、ある意味で間違っていたに違いありません。

規約と詳細

UEFIおよび.efiファイル 。 UEFIは、ご存知のとおり、高度な機能を備えたBIOSの代替品であり、実際には.efiはその実行可能ファイルです。 原則として、ブートローダーが含まれていますが、その唯一の目的は環境を初期化し、OSのロードを開始することです。 しかし、必ずしもそうではありません。 たとえば、メモリテストはefiファイルとして実装されます。



画像を泳ぐ 。 Windowsの新しいバージョンは、.wimファイルを広範囲に使用します。 本質的に、これはシステムの展開に使用される単なるアーカイブです。 拡張子が.swmのボリュームに分割できます。 dismユーティリティは、これらのイメージを操作するために使用されます。

起動順序

起動後、UEFIはブートローダーのリストを分析します。 これは、Linuxのefibootmgrなどの特別なユーティリティによって編集されるスタートメニューのようなものです。 ローダー自体は「システム」セクションにあります。 このセクションのファイルシステムはFAT32である必要があります（それ以外の場合、UEFIは単にそれを表示しません）。 CDからの起動ではUDF形式もサポートされているようです。



ローダーは、通常.EFIファイルであり、通常は\ EFI \ NAME \ Bootディレクトリにあります。 NAMEは、多くの場合、機器メーカーの名前による単なる名前です。 特に、\ EFIディレクトリに2つのサブディレクトリ-HPとMicrosoftがあり、ブートローダーは\ EFI \ Microsoft \ Boot \ bootmgfw.efiに構成されています。



標準のWindowsブートローダーには、独自のブートメニューもあります。 ファイル\ EFI \ Microsoft \ Boot \ BCDに含まれています。 基本的に、これは実行できる.efiファイルとその起動オプションのリストにすぎません。 たとえば、メモリテスト、システム回復環境、Windowsの通常の起動はここから開始します。 このファイルは、bcdeditユーティリティを使用して編集されます。 ちなみに、ここでディスクを回復した後に問題が発生しました。 ブートレコードパラメーターの1つは、その作業ディスクを「デバイスパーティション=」として定義します。 そして、対応する.efiファイルがそこからロードされます。 しかし、Windowsパーティションが再作成された後、UUIDが変更されたため、ファイル\ Windows \ System32 \ winboot.efiが見つかりませんでした。 しかし、セクション全体を再フォーマットした後、これに気付きました。

失敗した場合のダウンロード手順

Windowsの起動に失敗した場合、BCDのブートローダーエントリには、この場合に実行する「アイテム」を示すrecoverysequenceパラメーターがあります。 このエントリは、「Recovery Tools」セクションの\ Recovery \ WindowsRE \ winre.wimイメージからのRAMディスクの準備と、対応するWindowsブートローダーの起動について説明しています。



回復環境から、回復イメージを展開できます。このイメージは、install.wimファイルの対応するセクション（約17GB）に保存されます。 それに加えて、このセクションには、ドライバー、メーカーのユーティリティ、およびこれらすべてをインストールするためのスクリプトを含む.wimファイルが格納されます。 私のinstall.wimは、サイズが約350GBの多くの.swmファイルに分割されました。



同じセクションで、winUCRD.wimファイルを見つけました。このファイルのサイズと構造はwinre.wimと非常に似ていますが、サイズが数百キロバイト異なり、いくつかの余分なファイルが含まれています。 おそらくwinreには何らかの種類の空白がありますが、これはインストールプロセス中に確定されます。

復旧作業

すべてが非常に単純に見えます-システム障害が発生した場合、状況を修正しようとする回復ツールが起動し、これが不可能な場合、システムの工場出荷時の状態が完全に復元されます。 明らかに、いくつかのディスクを完全に再作成したため、リカバリを開始したときに黒い画面しか表示されませんでした。

いくつかのGoogleオプションが残っていました

• リカバリイメージのあるパーティションから起動します。 一部の記事では、このセクションにアクティブのマークを付けることを推奨しています。その後、そこからシステムのインストールが開始されます。 当然、うまくいきませんでした。 GPTパーティション分割では、アクティブなパーティションはなく、その上のファイルシステムはNTFSです。 理論的には、このメソッドはおそらく機能しています。 しかし、常にではありません。
• install.wimイメージをWIndowsディスクに解凍するだけで、インストールは自動的に実行されます。 すでにもっともらしいオプションです。 install.wimは実際に存在し、アンパックすることが判明しましたが、インストールは開始されませんでしたが、システムは起動しようとしましたが、directxドライバーをロードする段階に落ちました。 どうやら、ラップトップのドライバーを再インストールする必要があったようです。 しかし、ここでは、システムを展開し、それらを意味のあるシーケンスに結びつけるように設計された数十個の.cmdおよび.vbsスクリプトの形式で問題が発生しましたが、成功しませんでした。 もちろん、同じドライブ上でinstall.wimのさまざまな.wimファイルを単純に解凍しようとしても、何も起こりませんでした。
• イメージをディスクまたはフラッシュドライブに書き込み、そこから起動します。 これは有効なオプションだと思います。 唯一の問題は、画像のサイズが約20GBであり、そのようなメディアを見つけることが問題になる可能性があることです。

これで私は研究を終了することにしました。 月曜日までに作業用のラップトップが必要になり、Ubuntuのインストールと設定に必要なものすべてが約5時間かかりました。



PSこの記事の資料を集めて、回復ツールが起動しない理由を説明する興味深い投稿に出会いました。 そのためには、BCDで、RAMディスクと、インストールされたWindowsが置かれているディスク（これも私のものでした）のパラメーターを指定する必要があります。



PPSはい、確かに、ポイントは、回復ツールをロードしたBCD記録のdevice / osdeviceパラメーターがRAMディスクパラメーターを含むレコードを示していないことでしたが、どこにあるかは明確ではありませんでした。 次のコマンドを使用して復元できます（）

bcdedit /create {ramdiskoptions} /d "Ramdisk options" bcdedit /set {ramdiskoptions} ramdisksdidevice partition=Drive bcdedit /set {ramdiskoptions} ramdisksdipath \Recovery\WindowsRE\boot.sdi
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここ：ドライブ-リカバリイメージが保存されているディスク。 これはUUIDではなく、単に「c：」です

• ドライブ -リカバリイメージが保存されているディスク。 これはUUIDではなく、ドライブ文字 'c：'を含む文字列です（引用符なし）
• {ramdiskoptions} -これはこのように示されています（定義済みの名前）が、ここでエントリのGUIDに置き換えることができます。

回復環境のスタートアップの記録のパラメーターを編集します（再作成できます）。

 bcdedit /create /d "Boot from WIM" /application OSLOADER bcdedit /set {GUID} device ramdisk=[c:]\Recovery\WindowsRE\winre.wim,{ramdiskoptions} bcdedit /set {GUID} path \windows\system32\winload.efi bcdedit /set {GUID} osdevice ramdisk=[c:]\Recovery\WindowsRE\winre.wim,{ramdiskoptions} bcdedit /set {GUID} systemroot \windows
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここに：

• GUID-回復環境のスタートアップレコードのID。必要に応じて作成できます。
• [c：] -winre.wimが置かれている現在のドライブ文字。 ディスクは非表示にすることができます。この場合、パスはそのIDで示されます-{UUID} \ Recovery \ WindowsRE \ winre.wim