That’s actually a very useful result.
What it means
Get-PhysicalDisk is seeing
both SSDs, but one of them is in:
- OperationalStatus: Transient Error
- HealthStatus: Unhealthy
So this is
not just a BIOS problem anymore.
Windows
can see the second SSD at the storage layer, but it cannot present it as a usable disk to
Get-Disk / DiskPart. That usually means one of these:
- the SSD itself is failing
- the controller is getting bad responses from it
- there is severe leftover metadata/corruption on the drive
- the drive firmware is hanging when Windows tries to enumerate it fully
Because you already:
- replaced the CMOS battery
- confirmed AHCI persists
- changed SATA cable
- changed SATA port
- changed power connector
the remaining suspicion shifts strongly toward
SSD2 itself.
My conclusion
SSD2 is the problem
The bad drive is almost certainly the one with:
- serial
2304E6A3B147
Transient Error
Unhealthy
The good one is:
- serial
2309E6B5BB0D
OK
Healthy
What to do next
Step 1: Identify which physical SSD is bad
You need to confirm which actual drive matches serial
2304E6A3B147.
If the sticker is visible on the SSD, compare it physically.
If not, the easier practical method is:
- shut down
- disconnect one SSD
- boot
- run:
Get-PhysicalDisk | ft FriendlyName,SerialNumber,OperationalStatus,HealthStatus,Size
Then repeat with the other SSD.
That will confirm exactly which drive is bad.
Step 2: Do not use the unhealthy SSD for backup
Even if we get Windows to see it again, I would
not trust it for client backups.
A backup target must be the most trustworthy disk in the system, not the least.
So I would not spend much more time trying to make SSD2 part of the permanent solution unless you just want to test it.
Step 3: Check SMART / vendor diagnostics
Because these are
Crucial MX500 drives, the next best step is to test the bad SSD with a proper diagnostic tool.
Best options
- Crucial Storage Executive
- A SMART tool such as:
- CrystalDiskInfo
- smartctl (if you are comfortable with it)
You want to see whether the drive reports:
- media errors
- reallocated sectors / NAND issues
- firmware problems
- interface CRC problems
If the bad SSD won’t enumerate well enough for those tools, that itself is strong evidence it’s failing.
Step 4: Practical path forward
Best immediate setup
Since WSE is now stable on SSD1:
- Leave SSD1 as:
- OS on 120 GB
- remaining 812 GB as temporary backup/data space if needed
- Do not use SSD2 for now
- Attach the separate external 1 TB drive later and use that as:
- additional storage
- secondary backup target
- or primary backup target if performance is acceptable
This is not ideal, but it is much better than building your backup system around an unhealthy SSD.
Can SSD2 still be cleaned?
Maybe, but I would treat that as a test, not as a recovery plan.
If you want to try, use PowerShell first, not DiskPart.
See full details
Run:
Code:
Get-PhysicalDisk | fl FriendlyName,SerialNumber,OperationalStatus,HealthStatus,Usage,Size
Get-StoragePool | fl *
Then try:
Reset-PhysicalDisk -FriendlyName "CT1000MX500SSD1"
But because both drives have the same FriendlyName, I would rather use the serial-aware method if possible.
Unfortunately PowerShell storage cmdlets are awkward when two disks share the same model name.
Better diagnostic command
Run this:
Get-PhysicalDisk | Select FriendlyName,SerialNumber,OperationalStatus,HealthStatus,CanPool,Size,DeviceId | Format-List
If
DeviceId is shown, we may be able to target the bad disk more safely.
Important note about Get-Disk vs Get-PhysicalDisk
This difference is important:
Get-PhysicalDisk = storage subsystem can detect hardware presence
Get-Disk = Windows can enumerate it as a usable disk device
If it appears only in
Get-PhysicalDisk but not
Get-Disk, that usually means Windows sees something attached but cannot fully initialize it as a normal disk.
That is consistent with:
- failing drive
- broken metadata
- controller/firmware communication issue
Given everything you’ve already tried,
failing drive is now the leading suspect.
My recommendation now
Do this in order
- Identify which serial number matches which physical SSD
- Remove the unhealthy SSD from service
- Get backups working using:
- SSD1 free space temporarily, or
- your external 1 TB drive
- Only then decide whether to keep testing SSD2
If you need backups running right away
I would do this:
- In Disk Management, create a normal NTFS volume in the 812 GB unallocated space on SSD1
- Use that for immediate backup storage
- Keep the external 1 TB drive as the next step
- Retire or separately test SSD2
That gets your laptops protected again without waiting on a questionable disk.
Bottom line
You’ve solved the BIOS issue.
Now the remaining issue is almost certainly
SSD2 itself.
- Good SSD:
2309E6B5BB0D
- Bad/unhealthy SSD:
2304E6A3B147
I would not trust the unhealthy SSD for backup use.
If you want, I can help with one of these next:
- safe temporary setup using the 812 GB free space on SSD1, or
- commands to identify and test the bad SSD more precisely, or
- setting up the external 1 TB drive as the backup destination instead.