S
superware9
The laptop is a Dell E5570 with a Crucial MX300 CT525MX300SSD1, last Wednesday I upgraded Windows 10 Pro to the latest major version 20H2. The upgrade rebooted twice and when it finished - partition D, which was a 312GB NTFS, became RAW.
Examining the partition data shows it's totally random indicating encryption, the first and last sectors are identical probably indicating the NTFS boot sector is still there and data is intact. The OS partition C is ok, meaning D is Opal range-encrypted.
C:\Windows\Panther\setupact.log shows in the beginning:
2020-12-23 10:38:54, Info SP CNewSystem:
reInitialize: Velocity feature state for BitLocker auto-unlock is enabled
2020-12-23 10:38:54, Info SP Client requested to keep BitLocker active, but the device does not support it. Will suspend BitLocker instead.
...
2020-12-23 10:39:23, Info MOUPG ImageDeploy: Initializing BitLocker Mode: [Keep Active (Best-Effort)]
...
2020-12-23 10:50:46, Info SP CSuspendBitlocker::CheckEncryptedByPath: Processing drive C:
2020-12-23 10:50:46, Info SP CSuspendBitlocker::CheckEncryptedByPath: Disk is not encrypted or bitlocker is already suspended
Windows Logs -> System (eventvwr) shows the following right after the first reboot:
The operating system started at system time 2020-12-23T11:14:03.
11:14:05|EnhancedStorage-EhStorTcgDrv|The following informational event has occurred (0x0, 0x5, 0x0, 0x0). D0Entry
11:14:05|EnhancedStorage-EhStorTcgDrv|A TCG Command has returned an error. Desc: AuthenticateSession Param1: 0x1 Param2: 0x60000001C Param3: 0x900000006 Param4: 0x0 Status: 0x12
11:14:05|EnhancedStorage-EhStorTcgDrv|A TCG Silo has returned the capabilities value of 0x7.
11:14:06|EnhancedStorage-EhStorTcgDrv|The following informational event has occurred (0x0, 0x0, 0x0, 0x0). DeviceStart
11:14:08|Ntfs|Volume D: (\Device\HarddiskVolume5) is healthy. No action is needed.
11:14:49|Ntfs|The file system structure on volume D: has now been repaired.
11:14:49|Ntfs|Volume D: (\Device\HarddiskVolume5) requires an Online Scan. An Online Scan will automatically run as part of the next scheduled maintenance task. Alternatively you may run "CHKDSK /SCAN" locally via the command line, or run "REPAIR-VOLUME <drive:> -SCAN" locally or remotely via PowerShell.
11:14:53|Ntfs|A corruption was discovered in the file system structure on volume D:. The Master File Table (MFT) contains a corrupted file record. The file reference number is 0x1000000000024. The name of the file is "<unable to determine file name>".
A few seconds earlier it seems KB4592438 was installed (according to setupact.log), which has a documented issue here, here and MS confirmed, regarding chkdsk (which might have been executed automatically on boot). Yet this looks like a different issue surrounding SED.
TPM is enabled in the BIOS, I don't believe BitLocker was ever explicitly enabled on any of the partitions. It's possible to roll back the upgrade for 10 days, so I had to extend that setting to 30 days so not to lose the Windows.old folder. I tried rolling back on a clone disk, just to make sure it's successful, and it was. For now I can't go back since it's irreversible and I'm not sure if it'll help, the big question is whether Windows changed something in the SED/Opal subsystem, or simply giving the wrong credentials.
Here is sedutil output:
# sedutil-cli --scan
Scanning for Opal compliant disks
/dev/sda 2 Crucial_CT252MX200SSD1
/dev/sdb No
No more disk present ending scan
# sedutil-cli --query /dev/sda
/dev/sda ATA Crucial_CT252MX200SSD1
TPer function (0x0001)
ACKNAK = N, ASYNC = N. BufferManagement = N, comIDManagement = N, Streaming = Y, SYNC = Y
Locking function (0x0002)
Locked = N, LockingEnabled = Y, LockingSupported = Y, MBRDone = N, MBREnabled = N, MediaEncrypt = Y
Geometry function (0x0003)
Align = N, Alignment Granularity = 1 (512), Logical Block size = 512, Lowest Aligned LBA = 0
SingleUser function (0x0201)
ALL = Y, ANY = N, Policy = N, Locking Objects = 16
DataStore function (0x0202)
Max Tables = 16, Max Size Tables = 12582912, Table size alignment = 1
OPAL 2.0 function (0x0203)
Base comID = 0x1000, Initial PIN = 0x0, Reverted PIN = 0x0, comIDs = 1
Locking Admins = 4, Locking Users = 16, Range Crossing = N
TPer Properties:
MaxComPacketSize = 131072 MaxResponseComPacketSize = 131072
MaxPacketSize = 129792 MaxIndTokenSize = 126976 MaxPackets = 1
MaxSubpackets = 1 MaxMethods = 1 MaxSessions = 1
MaxAuthentications = 21 MaxTransactionLimit = 1 DefSessionTimeout = 240000
Host Properties:
MaxComPacketSize = 2048 MaxResponseComPacketSize = 2048
MaxPacketSize = 2028 MaxIndTokenSize = 1992 MaxPackets = 1
MaxSubpackets = 1 MaxMethods = 1
# linuxpba
DTA LINUX Pre Boot Authorization
Please enter pass-phrase to unlock OPAL drives: *****
Scanning....
Drive /dev/sda Crucial_CT525MX300SSD1 is OPAL NOT LOCKED
One thing which is special about D, is that the Administrator's Documents, Pictures, Downloads etc. folders were moved (changed location) from C to D after the initial Windows installation. So this issue might be connected with 20H2 classifying C as not-encrypted, finding OS related folders on the Opal encrypted D, and somehow corrupting D in some later process.
I've read posts online regarding Windows "taking ownership" on SED/Opal for some reason, can this be the case here? This clearly seems like a severe upgrade bug. What does "Locked = N" actually mean? Is there a way to get the partition data back?
Thank you!
Continue reading...
Examining the partition data shows it's totally random indicating encryption, the first and last sectors are identical probably indicating the NTFS boot sector is still there and data is intact. The OS partition C is ok, meaning D is Opal range-encrypted.
C:\Windows\Panther\setupact.log shows in the beginning:
2020-12-23 10:38:54, Info SP CNewSystem:
reInitialize: Velocity feature state for BitLocker auto-unlock is enabled2020-12-23 10:38:54, Info SP Client requested to keep BitLocker active, but the device does not support it. Will suspend BitLocker instead.
...
2020-12-23 10:39:23, Info MOUPG ImageDeploy: Initializing BitLocker Mode: [Keep Active (Best-Effort)]
...
2020-12-23 10:50:46, Info SP CSuspendBitlocker::CheckEncryptedByPath: Processing drive C:
2020-12-23 10:50:46, Info SP CSuspendBitlocker::CheckEncryptedByPath: Disk is not encrypted or bitlocker is already suspended
Windows Logs -> System (eventvwr) shows the following right after the first reboot:
The operating system started at system time 2020-12-23T11:14:03.
11:14:05|EnhancedStorage-EhStorTcgDrv|The following informational event has occurred (0x0, 0x5, 0x0, 0x0). D0Entry
11:14:05|EnhancedStorage-EhStorTcgDrv|A TCG Command has returned an error. Desc: AuthenticateSession Param1: 0x1 Param2: 0x60000001C Param3: 0x900000006 Param4: 0x0 Status: 0x12
11:14:05|EnhancedStorage-EhStorTcgDrv|A TCG Silo has returned the capabilities value of 0x7.
11:14:06|EnhancedStorage-EhStorTcgDrv|The following informational event has occurred (0x0, 0x0, 0x0, 0x0). DeviceStart
11:14:08|Ntfs|Volume D: (\Device\HarddiskVolume5) is healthy. No action is needed.
11:14:49|Ntfs|The file system structure on volume D: has now been repaired.
11:14:49|Ntfs|Volume D: (\Device\HarddiskVolume5) requires an Online Scan. An Online Scan will automatically run as part of the next scheduled maintenance task. Alternatively you may run "CHKDSK /SCAN" locally via the command line, or run "REPAIR-VOLUME <drive:> -SCAN" locally or remotely via PowerShell.
11:14:53|Ntfs|A corruption was discovered in the file system structure on volume D:. The Master File Table (MFT) contains a corrupted file record. The file reference number is 0x1000000000024. The name of the file is "<unable to determine file name>".
A few seconds earlier it seems KB4592438 was installed (according to setupact.log), which has a documented issue here, here and MS confirmed, regarding chkdsk (which might have been executed automatically on boot). Yet this looks like a different issue surrounding SED.
TPM is enabled in the BIOS, I don't believe BitLocker was ever explicitly enabled on any of the partitions. It's possible to roll back the upgrade for 10 days, so I had to extend that setting to 30 days so not to lose the Windows.old folder. I tried rolling back on a clone disk, just to make sure it's successful, and it was. For now I can't go back since it's irreversible and I'm not sure if it'll help, the big question is whether Windows changed something in the SED/Opal subsystem, or simply giving the wrong credentials.
Here is sedutil output:
# sedutil-cli --scan
Scanning for Opal compliant disks
/dev/sda 2 Crucial_CT252MX200SSD1
/dev/sdb No
No more disk present ending scan
# sedutil-cli --query /dev/sda
/dev/sda ATA Crucial_CT252MX200SSD1
TPer function (0x0001)
ACKNAK = N, ASYNC = N. BufferManagement = N, comIDManagement = N, Streaming = Y, SYNC = Y
Locking function (0x0002)
Locked = N, LockingEnabled = Y, LockingSupported = Y, MBRDone = N, MBREnabled = N, MediaEncrypt = Y
Geometry function (0x0003)
Align = N, Alignment Granularity = 1 (512), Logical Block size = 512, Lowest Aligned LBA = 0
SingleUser function (0x0201)
ALL = Y, ANY = N, Policy = N, Locking Objects = 16
DataStore function (0x0202)
Max Tables = 16, Max Size Tables = 12582912, Table size alignment = 1
OPAL 2.0 function (0x0203)
Base comID = 0x1000, Initial PIN = 0x0, Reverted PIN = 0x0, comIDs = 1
Locking Admins = 4, Locking Users = 16, Range Crossing = N
TPer Properties:
MaxComPacketSize = 131072 MaxResponseComPacketSize = 131072
MaxPacketSize = 129792 MaxIndTokenSize = 126976 MaxPackets = 1
MaxSubpackets = 1 MaxMethods = 1 MaxSessions = 1
MaxAuthentications = 21 MaxTransactionLimit = 1 DefSessionTimeout = 240000
Host Properties:
MaxComPacketSize = 2048 MaxResponseComPacketSize = 2048
MaxPacketSize = 2028 MaxIndTokenSize = 1992 MaxPackets = 1
MaxSubpackets = 1 MaxMethods = 1
# linuxpba
DTA LINUX Pre Boot Authorization
Please enter pass-phrase to unlock OPAL drives: *****
Scanning....
Drive /dev/sda Crucial_CT525MX300SSD1 is OPAL NOT LOCKED
One thing which is special about D, is that the Administrator's Documents, Pictures, Downloads etc. folders were moved (changed location) from C to D after the initial Windows installation. So this issue might be connected with 20H2 classifying C as not-encrypted, finding OS related folders on the Opal encrypted D, and somehow corrupting D in some later process.
I've read posts online regarding Windows "taking ownership" on SED/Opal for some reason, can this be the case here? This clearly seems like a severe upgrade bug. What does "Locked = N" actually mean? Is there a way to get the partition data back?
Thank you!
Continue reading...