Motherboard or drive problems

[Zipdrive]

Following a successful run of Spinrite 6.1 my desktop and laptop PCs (and a failed run on a UEFI-only laptop), I tried running SR on my son's PC, based on an ASUStek B150M-A motherboard with four storage devices: A Samsung EVO SSD, two Samsung HDDs and a Hitachi HDD.
While Window is operation, all drives are accessible and seem fullly functional, but when loading SR6.1, I got error indications from one drive (in red) and an inability to access the other one (in gray). I'm not sure what the difference between the two is (something about recovering from reset command).
Moreover, As I tried running SR on the "viable" drives, it just wouldn't go anywhere. It ran for hours and hours on the SSD, not showing almost any progress, intermittantly clicking like crazy. Thinking there might be a major issue with the start of the drive, I stopped the run and started new runs at 5%, 50% and 80% of the drive, getting the same symptoms in all the spots.
Even though spinrite worked overnight (~14 hours) it did not manage to get much ahead and all I had to show for it was a single "U" sector (is U worse than B?)

I could really use some advice on what can be going on here. Is this a motherboard issue? How can all the drives show such a set of symptoms?
Thank you. any help is appreciated.

 

[ColbyBouma]

Can you move one of those drives to a different computer and try again?

Also, would you be willing to share the log files from the SRLOGS folder on your SpinRite boot drive?

 

[Zipdrive]

I'm attaching the relevant logs. Note that I've had to rename the file extension tot txt as the forum attachment wouldn't accept ".log" files.
Moving the disks around will take some more time.

 

[Zipdrive]

Hmmm...it seems the forum won't accept my second, larger, log, probably due to its size (912KB). Any idea what the maximum allowed attachment size is?

 

[ColbyBouma]

Hmmm...it seems the forum won't accept my second, larger, log, probably due to its size (912KB). Any idea what the maximum allowed attachment size is?

I think it's around 500 kB. If you ZIP it, it will probably be small enough.

 

[Zipdrive]

zipped it is.

 

[ColbyBouma]

Hmm, your motherboard uses a very common Intel SATA controller (8086-A102). In fact, it's the same controller as my main testing machine. I was hoping your issues were being caused by an exotic controller

Another odd thing is that there's no SMART data in either of your logs. There is definitely something strange going on with your machine.

Are the drives connected directly to the motherboard, or do you use something like a port multiplier?

Another thing to check is the SATA controller settings in the BIOS. For example, is it in RAID mode?

 

[Zipdrive]

No RAID, and I wouldn't know a port multiplier if I ever saw one, but the drives are connected to the MB itself.
Regarding SMART data, I couldn't get any data in any of the computers I ran SR on, including my main desktop and old laptop, and even IIRC my work laptop using SR6.0
Attaching some logs for comparison.

 

[ColbyBouma]

There's SMART data in all 3 of those logs. "End-of-Run SMART System Status", at the end of the scans against AHCI drives. It's normal for BIOS drives to not have SMART data. The scans in log #3 and 4 were against AHCI drives, so they definitely should have SMART data.

From log #0:

See more

  |==========================================================================|
  |                      End-of-Run SMART System Status                      |
  |--------------------------------------------------------------------------|
  |  monitored param               margin         current/max    raw data    |
  |   ECC corrected  0 :::::::.......................  49/202 00000000000000 |
  |  rd chan margin  -                                                       |
  |  relocated sect  0 ::::::::::::::::::::::::::::::  90/90  00000000000000 |
  |  realloc events  0 :::::::::::::::::::::::::::::: 100/100 00000000000000 |
  |     seek errors  0 ::::::::::::::::::::::::::::::  49/49  00000000000000 |
  |   recal retries  0 :::::::::::::::::::::::::::::: 100/100 00000000000002 |
  |  cabling errors  0 :::::::::::::::::::::::::::::: 100/100 00000000000023 |
  |   uncorrectable  0 :::::::::::::::::::::::::::::: 100/100 00000000000000 |
  |    write errors  0 :::::::::::::::::::::::::::::: 100/100 00000000000000 |
  | command timeout  0 :::::::::::::::::::::::::::::: 100/100 00000000000000 |
  | pending sectors  0 :::::::::::::::::::::::::::::: 100/100 00000000000000 |
  |    read retries  -                                                       |
  |    total writes  -                                                       |
  |  write failures  -                                                       |
  |   wear leveling  -                                                       |
  |  remaining life  -                                                       |
  |   realloc space  -                                                       |
  |--------------------------------------------------------------------------|
  |                      drive temperature: 31'C/ 88'F                       |
  |==========================================================================|

One thing that could help Steve diagnose the problem with your B150M-A motherboard is a debug log. To generate one, call SpinRite with the "diags" parameter. If your boot drive launches straight into SpinRite, you'll have to exit it first. You don't have to run a scan, just launch it and exit. The file will end with .DBG, and will be in your SRLOGS folder.

spinrite.exe diags

 

[Zipdrive]

Thanks!
Attaching the DBG file.

 

[Zipdrive]

Any insights, ColbyBouma (or anyone else)?
Is there a next step I should take?

 

[ColbyBouma]

Were you able to test any of those drives on a different motherboard?

 

[Zipdrive]

It took a while, but I was able to run SR on the drives when they were attached to a different PC.
On the plus side the SSD, the Hitachi HDD and one of the Samsung HDDs all passed SR scans with flying colors.
On the other hand, the other Samsung HDD is apparently in such a shape that it put spinrite into a reboot loop. Any idea what that says?
Following the scans, they are still all usable on the original PC,
As a side issue, I couldn't figure out from windows 10 which of the physical drives is which logical ("letter") drive in order to back the problematic one up. Is there no easy way if figuring out if, say, drive D is the Hitachi or one of the Samsungs? Not to mention I can't tell which of the samsungs is which, as they are of identical model.

 

[ColbyBouma]

On the other hand, the other Samsung HDD is apparently in such a shape that it put spinrite into a reboot loop.

The entire computer is rebooting? Does this happen during Discovery, or during a scan?

As a side issue, I couldn't figure out from windows 10 which of the physical drives is which logical ("letter") drive in order to back the problematic one up.

You can correlate them by serial number. Run the following in PowerShell:

$Disks = Get-Disk
Get-Partition | Where-Object { $_.DriveLetter } | ForEach-Object {
    
    $PartitionDisk = $Disks | Where-Object Number -eq $_.DiskNumber
    [PSCustomObject]@{
        DriveLetter  = $_.DriveLetter
        DiskNumber   = $_.DiskNumber
        DiskModel    = $PartitionDisk.FriendlyName
        SerialNumber = $PartitionDisk.SerialNumber
        DiskSizeGB   = [Math]::Round(($PartitionDisk.Size / 1GB), 2)
    }
    
} | Format-Table -AutoSize

You can compare that to the serial numbers in your SpinRite logs (SRLOGS folder on your SpinRite boot drive).