PC
- RAMSPDToolkit v1.6.0, ConsoleOutputTest (PawnIO), Windows
- 2x Crucial DDR4 32GB (2x32GB) (CP32G4DFRA32A.C16FF, Micron DRAM) on SMBus i801 at 0x51 / 0x53
- ROG STRIX Z790-A GAMING WIFI D4
Observation
For each DDR4 module, the log shows the sensor-presence check running through both of its detection paths and concluding "not found" before the actual temperature read is attempted:
[TRACE] 0x51 does not have SPD_DDR4_THERMAL_SENSOR_BIT set.
[TRACE] Checking another way if thermal sensor is present.
[TRACE] 0x51 Thermal sensor address did not respond or quick was unsupported.
[TRACE] 0x51 Thermal sensor not found.
...
[TRACE] Temperature read failed with status -2147024463.
[DEBUG] Temperature read failed.
So the code already knows there's no sensor, but still goes on to attempt the actual temperature read afterward, which of course fails (0x800701B1 / "no such device") and gets logged as a failure rather than as an expected "skipped" state.
This is especially predictable for DDR4: the SPD_DDR4_THERMAL_SENSOR_BIT + quick-command fallback check is a pretty strong prior -- the overwhelming majority of consumer DDR4 sticks don't carry a TSOD at all (unlike DDR5, where the on-die PMIC/hub exposes thermal data more consistently). So for DDR4 in particular, once both detection paths say "not found," attempting the read is close to guaranteed to fail.
Suggestion
Once HasThermalSensor (or equivalent) resolves to false via the existing two-step check, short-circuit the subsequent temperature-read call instead of attempting it anyway. This would:
- avoid the extra SMBus round-trip per module
- turn a confusing "read failed" DEBUG/error-style log line into a clear "no sensor present, skipping" line, which is much easier to read for anyone diagnosing their own SPD dump
I have attached the Log.txt file in case you want to review it thoroughly
Log.txt
PC
Observation
For each DDR4 module, the log shows the sensor-presence check running through both of its detection paths and concluding "not found" before the actual temperature read is attempted:
So the code already knows there's no sensor, but still goes on to attempt the actual temperature read afterward, which of course fails (0x800701B1 / "no such device") and gets logged as a failure rather than as an expected "skipped" state.
This is especially predictable for DDR4: the SPD_DDR4_THERMAL_SENSOR_BIT + quick-command fallback check is a pretty strong prior -- the overwhelming majority of consumer DDR4 sticks don't carry a TSOD at all (unlike DDR5, where the on-die PMIC/hub exposes thermal data more consistently). So for DDR4 in particular, once both detection paths say "not found," attempting the read is close to guaranteed to fail.
Suggestion
Once
HasThermalSensor(or equivalent) resolves tofalsevia the existing two-step check, short-circuit the subsequent temperature-read call instead of attempting it anyway. This would:I have attached the Log.txt file in case you want to review it thoroughly
Log.txt