[smartmontools-support] [Smartmontools-database] TOSHIBA-MQ04UBF100 on Windows - Resume.

[Arioch The]

There clearly is something wrong between smartctl and windows.
Or, at least, there was.

At the same time, another Windows program did display SMART properly.
IOW it correctly addressed the drive in that specific situation, where
smartctl did it incorrectly.

You may argue that the bug technically is in the Windows, or in
obscure imprecise specifications or somewhere yet else, but the end
result was that, smartctl failed to work, while CrystaDiskInfo was
working.
So it was not a show stopper, a program designed with more smarts or
more correctness could do the job still.
And there was no way to force Smartctl to work.
I hope you can take a look in CDI sources, and perhaps there were
comments about unobvious details in proper using of Win32 API or some
workarounds or something.

-----------

> Normally this device name is translated by Windows to '\Device\Harddisk1\DR1' for internal use.

But who exactly was doing this translation for Smartctl ?

Because smartctl clearly was addressing wrong drive DR1 instead of
correct drive DR6.
More so, smartctl also refused to display /dev/sdg when i tried to
coerce smartctl to use the correct drive DR6.
It was refusing to work with either parameter.

----------

> Smartctl does not use registry accesses. It uses WMI queries .... The WMI queries may result
 in the registry accesses seen in the logs.

I can not say which library used by Smartctl and for what goal was
using the registry, but it did so.

Also, WMI library also may have bugs, for example some minor bugs were
described at https://habr.com/ru/post/264717/



Then again, it seemed that -d type was detected correctly, it was low
level drive name which was mis-detected, and that mis-detection was
fixed (or worked around) by registry tinkering.

So it should be that some apart from WMI Smartctl also used some other
library (or maybe even some process, service) which helps it to figure
correct "internal" drive name, and that other library was affected by
registry change.

-------

> Win32 path  '\\.\PhysicalDrive1'

The log does not show it though.
The log sometimes shows 'e:\' or other times '\Device\Harddisk1\DR1' -
but not that PhysicalDrive alias.
So i can only assume there is some library used by Smartctl that
converts the device name, and that due to some reason it did it
wrongly.

-----

I have a good-bad news though.
I wanted to do a cold boot with the USB drive connected.
The USB drive went into coma but otherwise stayed attached (maybe FW
still could do some internal housekeeping).
So, after a day or two of work, with several hibernate/resume in
between i today decided to shutdown the windows.
The Windows BSODed. Was it deue to my registry tinkering or due to USB
device malfunctioning i can not know.

I did a cold boot, having that only one USB drive attached, not both.
I also did not replugged the drive.

So, as of now

1) the reg. key was indeed recreated,
HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\MultifunctionAdapter\0\DiskController\0\DiskPeripheral\1
2) smartctl still addresses  '\Device\Harddisk1\DR1'
3) and this works, for now
4) i hope there is the reproducible scenario to make that drive DR6
again, but i am not sure and i do not know one yet

So, a heisenbug...