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

[Christian Franke]

[CC:smartmontools-support only as this is the more appropriate list]

Arioch The wrote:
>> Read SMART Data failed: IOCTL_SCSI_PASS_THROUGH_DIRECT failed, Error=121
> this one seems due to HDD going shutdown when trying reading specific areas.
>
> computer thinks HDD is connected, but it seems to be totally in coma
> until replugging
>
> can not even run the long test...It hangs for about a minute, then LED
> goes off and 121 errors start to spawn
>
> All in all i may speculate:
>
> 1) the original bug is with translation from E: or from /dev/sdb into
> internal Windows hardware device names (DR1 instead of correct DR6)

Smartctl does not do the above translation.

- 'smartctl ... /dev/sdb' or 'smartctl ... pd1' open Win32 path 
'\\.\PhysicalDrive1'. This should always address the disk which appears 
as "Disk 1" in Windows disk management. Normally this device name is 
translated by Windows to '\Device\Harddisk1\DR1' for internal use.

- 'smartctl ... E:' opens Win32 path '\\.\E:'. Then Windows usually 
routes pass-through accesses to the underlying physical drive.


> 2) it seems related to MultifunctionAdapter registry key, which
> overrides correct disk ID if present,
>        whether this parsing is done by SmartMonTools custom code or by
> Windows internas i don't know

Smartctl does not use registry accesses. It uses WMI queries to map 
physical drive or drive letter to the USB Id which is then mapped to '-d 
TYPE' option with drivedb. The WMI queries may result in the registry 
accesses seen in the logs.

No WMI queries are done if the '-d TYPE' is explicitly specified ('-d 
sat' in this case) or if it is not an USB drive.

I don't see anything which should be fixed in smartctl.

Regards,
Christian