2019-12-27 22:00 GPT<->MBR無損資料轉換(GPT FDISK)

無論如何轉換磁碟配置格式前、還是盡可能先備份。轉換情境為模擬Windows 7套裝電腦（HP筆電），硬碟包含4個主分割（保留、系統、HP還原、HP UEFI工具）。GPT無損轉MBR可透過Windows 10的內建工具MBR2GPT完成，但功能如其名只能MBR單向轉換GPT、且磁碟現有分割區上限為3個。介紹另一套轉換工具GPT Fdisk，原本是Linux環境工具、但目前也有Windows版本。兩者最大的共同點就是只提供命令模式操作......（免費的自然得有所取捨）；除非透過其他電腦或者Windows to GO或PE環境工具（還沒見到免費的），系統硬碟的轉換也只能在Windows RE靠命令完成了。  

首先要特別注意、GPT分割並不接受延伸/邏輯分割區，無論是哪套工具都得先將MBR分割的延伸/邏輯分割區轉換為主要分割區、再進行MBR轉GPT（注意MBR分割4個主要/延伸分割區上限）；更重要的是、若要將GPT硬碟轉換為MBR格式，因MBR分割有4個主要/延伸分割區限制，因此必須要先將GPT的分割區縮減至4個，否則GPT轉MBR將會出問題 （可透過GPT Fdisk / Fixparts進階操作轉換4個以上分割區、但不保證可行）。

1.MBR轉GPT基本相當簡單，唯一的問題是硬碟指定。以執行 GDisk64/32 \.physicaldrive#  指定目標硬碟，#是欲轉換的實體硬碟編號，通常是第一顆編號0，所以實際的命令是 GDisk64/32 \.physicaldrive0 ，進入後可輸入 ? 查詢完整選單與功能對應字元。 p 可列舉目標硬碟的分割區，w   則是寫入GUID（轉換為GPT）並退出；若放棄任何變更，以 q 退出即可。操作完成後可重回Windows安裝流程繼續操作。

2.接著是要注意的GPT轉MBR。由於Windows 10本身的GPT安裝配置就佔用4個主分割區（復原、EFI開機引導、MS保留、Windows系統），若還有其他的分割區配置、很明顯的就違反了要轉換成MBR的4個分割區限制。若想保留Windows系統、可先透過GHOST備份、稍候重裝MBR分割的Windows建立系統保留開機引導功能後再還原（或者由其他MBR Windows硬碟取得系統保留區還原、再修改BCD也可、參見Windows 10開機引導錯誤BCD修正(MBR)）。因此先移除前3個MBR無用的分割區  (若打算重裝Windows、則是前4個分割區皆刪除）、再進入GPT轉MBR流程。但若移除之後、剩餘的GPT主分割區還是大於4個？備份吧、否則就得透過GPT Fdisk / Fixparts的進階操作、或者透過其他方式轉換。

GPT轉MBR、一樣是執行 GDisk64/32 \.physicaldrive#   操作目標硬碟，以指令   r 進入還原/轉換選單、接著指令   g  進入MBR操作選單  、再以指令 w 變更硬碟為MBR分割，重啟電腦即可。若不想重啟而欲繼續進行其他磁碟作業、請重複此步驟一次強制磁碟狀態更新。否則硬碟分割表將出錯（見下圖），測試硬碟為4分割、但GPT變更為MBR未重啟或未再次執行變更強制磁碟狀態更新，則僅顯示單一分割。MBR轉換GPT無此情況。

所以一切轉換的關鍵就是單一硬碟上的分割區別超過四個！這又回到Windows 10的硬碟配置建議，若是採UEFI/GPT環境安裝、同時也考量硬碟效能，最好是獨立的實體系統SSD別帶其他資料分割區，配合獨立實體資料硬碟（反正一般標準PC SATA起碼4個接頭、也有USB 3.0可外接儲存或網路硬碟），GPT系統硬碟盡量別搞出4個以上分割區、除非不再考慮轉換、或願意花時間備份。

2019-12-21 21:30 Windows 10開機引導錯誤BCD修正(MBR)

原打算在磁碟、磁區復原測試一併帶過，但發現實際的內容有些龐雜、另寫本篇。這篇是針對開機發生0xc000000e或0xc000000f錯誤、無法以\Windows\system32\winload.exe引導開機、且「啟動修復」完全無法處理的情況、如何由Windows Recovery Environment（疑難排解-命令提示字元的Windows RE、PE變體)下、透過Bcdedit修改BCD紀錄修復開機引導問題。

先提議最簡便的方式--在系統還正常時、以Bcdedit /export備份BCD，之後可透過Bcdedit /import還原損壞的BCD；或直接在Windows RE進入MBR磁碟的系統保留分割區\Boot 或者GPT磁碟的EFI分割區（需先自行設定磁碟代號） \EFI\Microsoft\Boot 直接複製備份隱藏的BCD檔、日後碰上BCD檔損壞可直接還原、最省事。

首先透過Windows 10安裝媒體（DVD或USB隨身碟）進入疑難排解-命令提示字元（千萬別用Shift+F10的方式進入、將遭遇檔案鎖定而無法完成操作的情況）進入Windows RE。也可藉此先備份前述的BCD檔。

執行 Bcdedit /enum all /v 列舉BCD全部項目、應當會見到類似以下內容（原始BCD內容頗多、難以擷圖呈現、只節錄可能受影響需修改的區塊）

Windows 開機管理程式
--------------------
identifier {9dea862c-5cdd-4e70-acc1-f32b344d4795}
device partition=C:
description Windows Boot Manager
locale zh-TW
inherit {7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}
default {1ede9478-2108-11ea-9755-8e663bbbaab2}
resumeobject {1ede9477-2108-11ea-9755-8e663bbbaab2}
displayorder {1ede9478-2108-11ea-9755-8e663bbbaab2}
toolsdisplayorder {b2721d73-1db4-4c62-bf78-c548a880142d}
timeout 30

Windows 開機載入器
-------------------
identifier {1ede9478-2108-11ea-9755-8e663bbbaab2}
device unknown
path \Windows\system32\winload.exe
description Windows 10
locale zh-TW
inherit {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
recoverysequence {1ede9479-2108-11ea-9755-8e663bbbaab2}
displaymessageoverride Recovery
recoveryenabled Yes
allowedinmemorysettings 0x15000075
osdevice unknown
systemroot \Windows
resumeobject {1ede9477-2108-11ea-9755-8e663bbbaab2}
nx OptIn
bootmenupolicy Standard

Windows 開機載入器
-------------------
identifier {1ede9479-2108-11ea-9755-8e663bbbaab2}
device ramdisk=[unknown]\Recovery\WindowsRE\Winre.wim,{1ede947a-2108-11ea-9755-8e663bbbaab2}
path \windows\system32\winload.exe
description Windows Recovery Environment
locale zh-tw
inherit {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
displaymessage Recovery
osdevice ramdisk=[unknown]\Recovery\WindowsRE\Winre.wim,{1ede947a-2108-11ea-9755-8e663bbbaab2}
systemroot \windows
nx OptIn
bootmenupolicy Standard
winpe Yes
custom:46000010 Yes

休眠後繼續
---------------------
identifier {1ede9477-2108-11ea-9755-8e663bbbaab2}
device unknown
path \Windows\system32\winresume.exe
description Windows Resume Application
locale zh-TW
inherit {1afa9c49-16ab-4a5c-901b-212802da9460}
recoverysequence {1ede9479-2108-11ea-9755-8e663bbbaab2}
recoveryenabled Yes
allowedinmemorysettings 0x15000075
filedevice unknown
filepath \hiberfil.sys
bootmenupolicy Standard
debugoptionenabled No

裝置選項
--------------
identifier {1ede947a-2108-11ea-9755-8e663bbbaab2}
description Windows Recovery
ramdisksdidevice unknown
ramdisksdipath \Recovery\WindowsRE\boot.sdi

開機失敗主因是當中紅字項目的設定值為 unknown 導致無法正常引導開機。

這時以 Bcdedit /set {identifier GUID} object value 逐項修正，除Windows Recovery Environment的Windows開機載入器與搭配的裝置選項（虛擬磁碟boot.sdi檔）此項以外、所有 unknown 的項目，device、osdevice、filedevice修正值為 partition=Windows所在的磁碟代號，可用 Bootrec /scanos 指令確認（以Windows RE當下查詢的磁碟代號為準、千萬不可直接以C:代入、否則也將引導錯誤）。

例如修改Windows 10的Windows 開機載入器這項所含的2筆錯誤值，操作指令為

Bcdedit /set  {1ede9478-2108-11ea-9755-8e663bbbaab2} device partition=D:

Bcdedit /set  {1ede9478-2108-11ea-9755-8e663bbbaab2} osdevice partition=D:

而Windows Recovery Environment的Windows開機載入器{1ede9478-2108-11ea-9755-8e663bbbaab2}此項的device與osdevice、則是將 unknown 改為Windows RE分區磁碟代號（注意含[ ]括號）並保留其餘舊值

Bcdedit /set  {1ede9479-2108-11ea-9755-8e663bbbaab2}  device ramdisk=[E:]\Recovery\WindowsRE\Winre.wim,{1ede947a-2108-11ea-9755-8e663bbbaab2}

Bcdedit /set    {1ede9479-2108-11ea-9755-8e663bbbaab2} osdevice ramdisk=[E:]\Recovery\WindowsRE\Winre.wim,{1ede947a-2108-11ea-9755-8e663bbbaab2}

Windows Recovery Environmen相應的Windows Recovery虛擬磁碟裝置{1ede947a-2108-11ea-9755-8e663bbbaab2}此項的ramdisksdidevice分區 unknown   也一併改為與Windows RE所在相同磁碟代號

Bcdedit  /set     {1ede947a-2108-11ea-9755-8e663bbbaab2}   ramdisksdidevice  partition=E:

 

以上為參考範例、實際的BCD identifier GUID請以 Bcdedit /enum all /v 列舉為準、Windows所在磁碟代號由Windows PE/RE以   Bootrec /scanos 查詢為準。若   Bootrec /scanos  無法正確判斷Windows安裝位置、請以 Diskpart 的 list disk / part / vol 查詢各分區研判。Windows Recovery Environment (\Recovery\WindowsRE\winre.wim)所在以及相應的Windows Recovery虛擬磁碟檔(\Recovery\WindowsRE\boot.sdi)可能直接存在於系統分區、或者獨立的復原分區，也請自行確認。

某些情況下Windows RE將會安裝於系統分區、而非以獨立復原分區安裝，若欲將存在於Windows所在分區的Windows RE搬移至另行規劃的復原分區、以避免Windows RE連帶損壞的情況，可先新增一額外的NTFS分區（大小約600MB，必須移除磁碟代號、否則該分區Windows RE將失效），接著進入Windows RE、透過Diskpart進入該分區(sel disk # -> sel part #)以   set id=27   設置為復原分區類型、再將系統分區下的Recovery隱藏目錄透過xcopy /e /h完整複製至該復原分區，最後透過上述方式重新設定Windows RE以及搭配的裝置選項所在位置至還原分區。

 

一般介紹的修正開機方式多以刪除原有問題BCD，再透過 Bootrec /rebuildbcd 重新偵測系統中Windows所在位置、並提示使用者新增至BCD（重建）的方式，或以Bcdboot \Windows_path\ /S C: /F ALL /L zh-TW 將位置確定的Windows啟動項目「重增」於BCD解決，似乎也很妥當（但若Bootrec /scanos 無法正確研判系統分區配置、則Bootrec /rebuildbd 亦無法重建BCD）。

先看看以 Bootrec /rebuildbcd 方式重建的BCD（重建的僅有以下內容以及刪除的Windows 記憶體測試器引導）

Windows 開機管理程式
--------------------
identifier {9dea862c-5cdd-4e70-acc1-f32b344d4795}
device partition=C:
path \bootmgr
description Windows Boot Manager
locale zh-TW
default {ce0a49a5-23f7-11ea-ad4d-a0ed28f09187}
displayorder {ce0a49a5-23f7-11ea-ad4d-a0ed28f09187}
timeout 30

Windows 開機載入器
-------------------
identifier {ce0a49a5-23f7-11ea-ad4d-a0ed28f09187}
device partition=E:
path \Windows\system32\winload.exe
description Windows 10 Enterprise
locale zh-TW
recoverysequence {ce0a49a6-23f7-11ea-ad4d-a0ed28f09187}
recoveryenabled Yes
osdevice partition=E:
systemroot \Windows
bootmenupolicy Standard

Windows 開機載入器
-------------------
identifier {ce0a49a6-23f7-11ea-ad4d-a0ed28f09187}
device ramdisk=[E:]\Recovery\WindowsRE\Winre.wim,{ce0a49a7-23f7-11ea-ad4d-a0ed28f09187}
path \windows\system32\winload.exe
description Windows Recovery Environment
locale zh-TW
inherit {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
displaymessage Recovery
osdevice ramdisk=[E:]\Recovery\WindowsRE\Winre.wim,{ce0a49a7-23f7-11ea-ad4d-a0ed28f09187}
systemroot \windows
nx OptIn
bootmenupolicy Standard
winpe Yes
custom:46000010 Yes

裝置選項
--------------
identifier {ce0a49a7-23f7-11ea-ad4d-a0ed28f09187}
description Windows Recovery
ramdisksdidevice partition=E:
ramdisksdipath \Recovery\WindowsRE\boot.sdi

 

很明顯少了相當的項目、不過Windows RE的引導還在、之後的測試也正常。再看看以 Bcdboot \Windows_path\ /S C: /F ALL /L zh-TW將Windows啟動「重增」的BCD

Windows 開機管理程式
--------------------
identifier {9dea862c-5cdd-4e70-acc1-f32b344d4795}
device partition=C:
description Windows Boot Manager
locale zh-TW
inherit {7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}
default {2d2c3b86-234c-11ea-9c81-bd5c8869bb1f}
resumeobject {2d2c3b85-234c-11ea-9c81-bd5c8869bb1f}
displayorder {2d2c3b86-234c-11ea-9c81-bd5c8869bb1f}
{1ede9478-2108-11ea-9755-8e663bbbaab2}
toolsdisplayorder {b2721d73-1db4-4c62-bf78-c548a880142d}
timeout 30

Windows 開機載入器
-------------------
identifier {2d2c3b86-234c-11ea-9c81-bd5c8869bb1f}
device partition=E:
path \Windows\system32\winload.exe
description Windows 10
locale zh-TW
inherit {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
allowedinmemorysettings 0x15000075
osdevice partition=E:
systemroot \Windows
resumeobject {2d2c3b85-234c-11ea-9c81-bd5c8869bb1f}
nx OptIn
bootmenupolicy Standard

休眠後繼續
---------------------
identifier {2d2c3b85-234c-11ea-9c81-bd5c8869bb1f}
device partition=E:
path \Windows\system32\winresume.exe
description Windows Resume Application
locale zh-TW
inherit {1afa9c49-16ab-4a5c-901b-212802da9460}
allowedinmemorysettings 0x15000075
filepath \hiberfil.sys
bootmenupolicy Standard

相較 Bootrec /rebuildbcd 「重建」BCD， Bcdboot \Windows_path\ /S C: /F ALL /L zh-TW「還原」的BCD內容似乎較多（還有部分與復原前相同內容刪除），但未包Windows RE引導。

因此若不願以 Bcdedit /set 逐項修改、或係因BCD完全損毀而無法修改，建議以  Bootrec /rebuildbcd 「重建」BCD、起碼相較 Bcdboot \Windows_path\ /S C: /F ALL /L zh-TW「重增」Windows啟動的BCD、Windows RE能正常運作（Bootrec /rebuildbcd  消失的休眠裝置也可透過Windows休眠功能重新設定）。

或者、透過Bcdboot \Windows_path\ /S C: /F ALL /L zh-TW「還原」BCD後、也可在進入Windows後、透過 Reagentc  /disable 停用Windows RE再以 Re  agentc  /ensable 重建BCD內的Windows RE啟動項目。

以上的情況為BIOS/MBR磁碟開機引導的修正、EFI/GPT磁碟的BCD處理也是近似方式處理。

2019-12-20 22:30 GHOST 12與Windows 10 GPT磁碟操作心得

在VM測試Windows RE下GHOST(v12.0.0.10658)對於GPT分割區的備份與還原作業，無論是磁碟或個別分割區還原、遠無想像中的障礙，尤其可由Windows安裝媒體的疑難排解-命令提示執行（Windows RE、PE變體。但不可直接以Shift+F10叫出命令提示字元視窗執行GHOST，否則將可能發生磁碟鎖定無法作業的問題），不需另搞一套PE、無須特別設定。也許再多用GHOST一陣子吧。

針對GPT或MBR磁碟的磁碟還原或者分割區還原皆無異狀、且不需特別設定。

以完整GPT磁碟影像的個別分割區（保留/EFI/MSR/系統）還原至無分割磁碟（Ex:大硬碟轉至小硬碟）也無問題，但需先以diskpart convert gpt定義目標硬碟分割表格式為GPT，之後GHOST配合-SZEE參數、可自動以影像檔內的配置表大小建立分割區並還原。

若由較小的磁碟影像還原至較大磁碟、也要-SZEE參數以免保留/EFI/MSR分割區也被等比放大，但還原後需以磁碟管理工具調整系統分割區；或以-SZEE參數個別還原保留/EFI/MSR分割、再以一般方式等比還原系統分割。也可參考官方問答，以指令/參數固定分割區大小批次還原作業。

將EFI/GPT格式硬碟的Windows系統分割區影像、直接還原至BIOS/MBR硬碟、GHOST不需指定特別參數、系統也能正常運作。但該MBR硬碟需已經Windows 10配置必要空間（具系統保留分割區且當中BCD正常）。

若因特殊操作（ex:分別還原MBR的系統保留區與GPT的系統區至無系統的MBR磁碟）導致BCD引導錯誤、可參見在下另一篇關於BCD錯誤的修正方式。

2019-12-16 21:00 Windows 10移轉準備--Clonezilla與容量差異硬碟系統移轉(UEFI/GPT)

該來的還是來了、Windows 7一如Windows XP被M$宣判死期，隨著Windows 10與UEFI/GPT的到來，過往熟悉的透過GHOST進行磁碟/分割區備份與移轉作業也得有些調整（GHOST較難以取得「更新」）。所以這次實驗的主角為Clonezilla、內容為大小硬碟間的移轉。

當然是針對比較有問題的大硬碟轉往小硬碟，實驗平台是VM上60GB->40GB VMDK移轉（device-image與device-device結果相同）、Clonezilla為2.6.4-10。

device-image來源為60GB的映像檔、device-device來源則是60GB的VMDK。

作業模式為Expert專家模式，必須使用的參數為-icds、建立分割表時無視目標硬碟容量（所以原硬碟的檔案總用量務必小於新硬碟全部空間），且確定調整檔案系統以配合配置表的選項-r啟用（預設啟用）。

接著對於配置表的進階選項則是選擇-k1等比建立分割表

然後等作業完成。以下為實驗成果，成功開機。

最初的實驗沒注意配置表的進階條件設定-k1，因此始終無法進行分割區複製作業。

以上是較單純的大小硬碟間移轉與還原；若較特別的情況、牽涉到包含其他資料分割區、只還原Windows系統分割區，除設定-icds、必須使用選項-k不在目標硬碟建立分割表。注意：若用-k1、目標硬碟前三個分割區--復原作業區、EFI開機引導區、系統保留區將會成為RAW格式無法識別、而導致開機失敗，也無法以Windows 10的開機修復功能解決）。若Windows分割區完全消失（刪除），還原於重建的分割區將極可能無法載入Windows、也無法透過修正BCD解決。

以上的實驗都是在VM環境下達成。雖然VM的基礎硬體模擬度不差，但實機也許又有其他情況。

 

所以進入Windows 10 / UEFI(GPT)的時代後、別將系統碟配置搞得太複雜--獨立的SSD系統碟(GPT)+獨立資料硬碟(GPT/MBR)對於這類作業會單純許多（完整系統硬碟備份/還原），也能藉由實體磁碟區隔、降低單一磁碟故障而遺失全部資料的風險。

實驗中碰上些狀況--設定icds參數後打算取消作業更改參數，但接連的cancel後、作業還是進行了，cancel只是放棄項目選擇罷了。希望新版的Clonezilla能修正此問題，否則任何的專家模式設定都務必當心、畢竟無法停止（除了關機或reset）。

若需要完全清除硬碟內容再復原，可透過Clonezilla shell執行fdisk重建GPT；或者透過Windows開機媒體中的修復電腦、疑難排解、開啟命令提示字元，執行Diskpart、選擇需要清除硬碟分割的硬碟、執行clean清除。

2019-12-13 22:00 無聊的AF硬碟4K對齊空間壓榨

相較傳統無對齊分割的31KB偏移、1MB(1024KB)對齊減損了1MB......對於動輒GB甚至TB級的硬碟、在99.9999%的使用者眼中簡直微不足道......所以這篇是與0.0001%的心得分享。

首先在Windows以管理員身份執行Diskpart.exe，先選擇要操作的磁碟。

接著以Create Partition Primary配合參數Align=<N> 設定起始對齊位移值。最低32KB，就指定Align=32。

假設以全部磁碟空間建立單一MBR分割，指令為Creation Partition Primary Align=32

若要建立GPT分割，可將對齊的新建MBR分割區以convert gpt指令轉換為GPT分割區。

關鍵是Align參數、預設值是1024(K)，指定最低值32(K)並未有問題、也可符合磁碟AF 4K對齊。

2019-12-11 21:30 解除Windows Defender應用程式防護(WDAG)運作限制

Windows Defender應用程式防護(Windows Defender Application Guard, WDAG)最低系統硬體需求為4處理器核心、8GB記憶體以及5GB儲存空間，否則在開啟或關閉Windows功能內的項目將會反白而無法勾選啟用（提示「此裝置設定不支援WDAG」）。

若因無法滿足以上條件又想啟用WDAG測試，可嘗試編輯機碼位置

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Hvsi]

新增以下DWORD值

SpecRequiredProcessorCount （處理器核心限制）
SpecRequiredMemoryInGB （記憶體限制）
SpecRequiredFreeDiskSpaceInGB （儲存空間限制）

新增值為0、可不做修改完全無設限。

無須重啟系統、重新進入開啟或關閉Windows功能，WDAG即可勾選啟用。

當然按官方說法這只是測試使用的權宜之計，實際運用系統還是應滿足最低要求以獲得正常的運作效能。

2019-12-10 21:00 解決VMware Workstation無法以EFI模式安裝Windows 10 X64

這實在是相當初級的錯誤狀況。

在VMware Workstation以EFI模式安裝Windows 10 x64時、可能出現"No compatible bootloader found" "unsucessful"之類的提示，以EFI SHELL透過/EFI/BOOT/BOOTX64.EFI安裝卻出現"Image type X64 is not supported by this IA32 shell"，原來是IA32(x86)無法引導x64(AMD64)安裝。

VMware Workststion無法支援EFI x64安裝、不是見鬼了！其實問題在於新增VM時的Guest OS版本選擇，預設是Windows 10。按以往的BIOS模式安裝，一般也不會刻意選擇、也不會有任何問題。但VMware Workstation的EFI可是嚴格區分x86與x64，而新增VM預選的"Windows 10"其實就是x86(IA32)！若點開選單、會注意到Windows由XP開始都有獨立的x64項目，無法以EFI安裝Windows 10 x64的關鍵就是在此。

所以新增VM時、若欲以EFI模式安裝x64系統，務必注意Guest OS版本選擇為x64，否則就將出現無法安裝的情況。若已建立VM、也可至Settings的Options分頁更改平台類別。