What is your Hardware ID for Samsung 850 Pro with EXM04B6Q firmware?

Fascinating.

The 1TB 850 Pro that was returned to me from Samsung Repair with the re-flashed EXM04B6Q firmware shows the non-specific "generic" Hardware ID value of:

SCSI\DiskSamsung_SSD_____________EXM0

running on my ASUS Z170 desktop Win7 machine, which then results in a Win7 Device Manager disk drive name of: "Samsung SSD SCSI Disk Device". In contrast, this same disk drive shows up with HWINFO64 and CrystalDiskInfo as "Samsung SSD 850 Pro 1TB". Obviously these other two programs must be looking for something other than just the Hardware ID in order to determine the device name.

But as a result of the "generic" Hardware ID and "generic" Device Manager drive name, AIDA64 5.95.4500 running in Win7 seemingly does not recognize the device properly. No SMART data is retrieved, and consequently no drive temperature data is available for display.


Now I also have a Lenovo P70 laptop which has a 512GB 850 Pro in it, that I flashed myself to EXM04B6Q using the standalone bootable ISO CD.

The firmware upgrade went without a hitch, and the Hardware ID value is also the same "generic" value of: SCSI\DiskSamsung_SSD_____________EXM0 same as exists with my 1TB 850 Pro used on my Z170 desktop machine. Again, no "850 Pro" in the name, nor is there any indication of drive capacity in the drive name shown in Win7 Device Manager, which again shows a "generic" value of simply "Samsung SSD SCSI Disk Device".

And again, AIDA64 running in Win7 on the P70 fails to obtain SMART date, and thus fails to display drive temperature. And again in contrast, both HWINFO64 and CrystalDiskInfo correctly display the drive name as "Samsung SSD 850 Pro 512GB".

But I have both Win7 and Win10 available on my P70 laptop. Remarkably, in Win10 Device Manager running on that P70 laptop the drive name shows up as: Samsung SSD 850 Pro 512GB which is the same value shown by HWINFO64 and CrystalDiskInfo running in either Win7 or Win10. Apparently Win10 Device Manager must be looking for something else to identify the drive that way (same as HWINFO64 and CrystalDiskInfo apparently do), since it can't be uniquely recognized from the Hardware ID alone.


Now, one more data point here.

I have access to another machine, this time an M800 tower desktop machine running Win7 that has a 128GB 850 Pro SSD in it, along with a 1TB Western Digital HDD spinner. The 128GB 850 Pro has, again, been flashed with its EXM04B6Q firmware upgrade using the bootable CD ISO approach.

Remarkably, the resulting new Hardware ID on this 128GB 850 Pro is NOT that "generic" non-unique value it was on both my 512GB and 1TB models. Instead, the new Hardware ID on this 128GB model is:

SCSI\Disk_Samsun_SSD_850_Pro_128GEXM0

and it shows up in Win7 Device Manager as: "Samsun SSD 850 Pro 128G SCSI Disk Device".

And with HWINFO64 and CrystalDiskInfo it shows up as: "Samsung SSD 850 Pro 128GB".

Most importantly, the drive IS recognized for what it is by AIDA64, and SMART data is correctly obtained, and drive temperature is correctly reported.

Note that the Hardware ID value for the 128GB drive is very similar to that of the 256GB drive reported by PBCOPTER in this thread: SCSI\DiskSamsung_SSD_850_PRO_256GEXM0, which is very different than the "generic" value shown in my 512GB and 1TB models.

Also, note that the Device Manager name for the 128GB drive is again very similar to that of the 256GB drive reported by PBCOPTER: "Samsung SSD 850 PRO 256GB", which again is very different than the "generic" value shown in Device Manager for my 512GB and 1TB models.


Bottom line: clearly there is a problem with Win7 AIDA64 in that it fails to recognize the strangely "generic" new values of Hardware ID and resulting non-unique Device Manager name, for the larger 512GB and 1TB models, as both HWINFO64 and CrystalDiskInfo do correctly and as Win10 Device Manager apparently does.

Now as to why Samsung would choose to imbed a different "generic" Hardware ID in the 512GB and 1TB models, but a "unique" Hardware ID in the smaller 128GB and 256GB models... well, who knows?

Anyway, I have a ticket open with AIDA64 about this, since they are the only software that mis-recognizes the drive in Win7, no matter what the Hardware ID value and Device Manager name is. Obviously this new Hardware ID is not problematic for HWINFO64, CrystalDiskInfo, and Win10 Device Manager, nor is it a problem for AIDA64 running in Win10 (perhaps because of the correct value shown in Win10 Device Manager).

More to follow...

Just to summarize what I've been able to collect (and PBCOPTER please double-check the Win7 Device Manager disk drive name you posted above, as well as the HWINFO64 and CrystalDiskInfo values if you can provide them)...


512GB with EXM04B6Q
(1) Hardware ID: SCSI\DiskSamsung_SSD_____________EXM0
(2) Win7 Device Manager disk drive name: "Samsung SSD SCSI Disk Device"
(3) Win10 Device Manager disk drive name: "Samsung SSD 850 Pro 512GB"
(4) HWINFO64 drive name: "Samsung SSD 850 Pro 512GB", world wide name: 50025388400576F2
(5) CrystalDiskInfo: "Samsung SSD 850 Pro 512GB"


1TB with EXM04B6Q
(1) Hardware ID: SCSI\DiskSamsung_SSD_____________EXM0
(2) Win7 Device Manager disk drive name: "Samsung SSD SCSI Disk Device"
(3) Win10 Device Manager disk drive name: n/a
(4) HWINFO64 drive name: "Samsung SSD 850 Pro 1TB", world wide name: 5002538C4043F52C
(5) CrystalDiskInfo: "Samsung SSD 850 Pro 1TB"


128GB with EXM04B6Q
(1) Hardware ID: SCSI\Disk_Samsun_SSD_850_Pro_128GEXM0
(2) Win7 Device Manager disk drive name: "Samsun SSD 850 Pro 128G SCSI Disk Device"
(3) Win10 Device Manager disk drive name: n/a
(4) HWINFO64 drive name: "Samsung SSD 850 Pro 128GB", world wide name: 50025388401AD82D
(5) CrystalDiskInfo: "Samsung SSD 850 Pro 128GB"


256GB with EXM04B6Q
(1) Hardware ID: SCSI\DiskSamsung_SSD_850_PRO_256GEXM0
(2) Win7 Device Manager disk drive name: "Samsung SSD 850 PRO 256GB"
(3) Win10 Device Manager disk drive name: n/a
(4) HWINFO64 drive name: n/a
(5) CrystalDiskInfo: n/a

Ok. Finally got the problem with AIDA64 and the larger 512GB and 1TB models of the Samsung 850 Pro resolved, thanks to the author. I am not 100% satisfied with the explanation because there are so many other variables involved which bring other factors into play, but there's no question that the "solution" is in AIDA64 and it seemingly not tied to the Hardware ID value itself.

Turns out that because I had installed Intel Rapid Storage Technology (RST) supposedly to enhance pure SATA performance (even though I was not running RAID), this required that I also check two AIDA64 sensor options relating to RAID which I had un-checked since I don't have RAID. Turns out the presence of Intel RST causes SATA HDD/SSD drives under its control to have a Hardware ID that starts with "SCSI", and that corresponds to "RAID".

So the reason no SMART data was being obtained by AIDA64 for my SATA HDD/SSD devices was because I had neglected to check the two "RAID" options in AIDA64. Now as to why the smaller 128GB 850 Pro drive WAS interrogated for SMART data even though Intel RST was also installed on that machine and yet the two RAID options were NOT checked, well I don't know. Maybe because it had a "unique" Hardware ID value that identified it as a Samsung 850 Pro, maybe that was equally as important so that SMART data was retrieved. I don't know.

I only know that when I was instructed (by the author) that since SCSI was showing in the Hardware ID this meant it was like "RAID" (even though it wasn't true RAID), that this meant I needed to enable the RAID functionality of AIDA64 to get SMART data. I am sure it was the installation of Intel RST which is what caused this, and probably not the firmware upgrade to EXM04B6Q... although the timing of the two was coincidental, so it's hard to tell now after the fact.

Anyway, case closed. I now have gotten back my drive temperatures for all drives, NVMe and SATA (both HDD and SSD).

What a battle!