Hwinfo needs a comparative benchmark module.

no it doesnt

Just a simple FLOPS or Mem bandwith would be very nice. Something like CPUz has, just way less heavy for old HW

StuckIn1999 wrote on 2025-12-08, 02:38:

Just a simple FLOPS or Mem bandwith would be very nice. Something like CPUz has, just way less heavy for old HW

Just like that.

StuckIn1999 wrote on 2025-12-08, 02:38:

Just a simple FLOPS or Mem bandwith would be very nice. Something like CPUz has, just way less heavy for old HW

Just like that.

I've started using winget on Windows 10 to perform updates to various programs. One of these is HwInfo. The problem is that with the change from installer to just copying the new version in, is that the installed version as shown in registry is incorrect, so winget wants to do an unnecessary upgrade.

My request, is that when HWINFO is run, that it check to see if registry entries exist, if so, if the version info is incorrect then update those fields. Winget looks at the displayed version field, but may as well update the others as well. If there's no registry entries then do nothing.

Not implemented in the latest release 8.44, I wonder if the author even read it.

I have read it, but don't consider this as a good solution. Running a portable build on a system with an installed version would overwrite this version and could cause issues with uninstall inforamtion.

There's no choice for 32-bit computers. I used to run the installer, but then that was taken away and only the portable version can be used. So I copy the portable exe on top of the previous one, but it doesn't update the uninstall info. What other choice do I have?

I guess I can make a reg file to update the fields myself.

Hippo 15 board V1.11. Hwinfo reports it as Hippo12.

Not sure if this topic is still used, but I need to report a random bug on ver 8.48 for win9x computers.

The problem is that no drives appear in the hard disk list, no hard drives, no CDROM drives.

debug info is attached for one of the computers.

Robbbert wrote on 2026-06-25, 11:34:

Not sure if this topic is still used, but I need to report a random bug on ver 8.48 for win9x computers. […]
Show full quote

Not sure if this topic is still used, but I need to report a random bug on ver 8.48 for win9x computers.

The problem is that no drives appear in the hard disk list, no hard drives, no CDROM drives.

debug info is attached for one of the computers.

The attachment debug.zip is no longer available

By default HWiNFO uses Safe Mode for IDE/(S)ATA Drive Scan, which relies on drivers to provide this data. However, that seems to sometimes fail on Win9x.
Try to set the mode to "Low-level IO Access".

Unfortunately eBay sellers sometimes use HWINFO as single source of truth when it's really a best guess based on a sample we can't see.

I think a really nice functional/reputational update to HWINFO would be to mark the lower confidence identifications "Provisional". My view is that doing this would encourage users to dig deeper and submit more details.

I also think a disclosure on how the identifications are made would be really good because users might then be stimulated to observe exceptions that are not currently invited.

Mumak wrote on 2026-06-25, 12:51:

Robbbert wrote on 2026-06-25, 11:34:

Not sure if this topic is still used, but I need to report a random bug on ver 8.48 for win9x computers. […]
Show full quote

Not sure if this topic is still used, but I need to report a random bug on ver 8.48 for win9x computers.

The problem is that no drives appear in the hard disk list, no hard drives, no CDROM drives.

debug info is attached for one of the computers.

The attachment debug.zip is no longer available

By default HWiNFO uses Safe Mode for IDE/(S)ATA Drive Scan, which relies on drivers to provide this data. However, that seems to sometimes fail on Win9x.
Try to set the mode to "Low-level IO Access".

Ah yes I forgot to respond to this. The suggestion works although then the smartdrive indicator doesn't work, I suppose this is expected.

Some other possible issues with the latest version is 1. sometimes crashes on exit on windows 95, and 2. sometimes drives might show twice, with different interfaces (various platforms).
If these are unexpected I can get more info.

MattRocks wrote on Yesterday, 11:40:

Unfortunately eBay sellers sometimes use HWINFO as single source of truth when it's really a best guess based on a sample we can't see.

I think a really nice functional/reputational update to HWINFO would be to mark the lower confidence identifications "Provisional". My view is that doing this would encourage users to dig deeper and submit more details.

I also think a disclosure on how the identifications are made would be really good because users might then be stimulated to observe exceptions that are not currently invited.

Problem here is that even such "confidence level" is very difficult to estimate. In many cases we might be pretty confident about accuracy but due to some other factors that we're unable to reliably determine, the outcome can be different.
Our goal is to always provide most accurate results and avoid any "man in the middle". But this is sometimes impossible to achieve - on old systems due to the lack of sufficient indicators and on newer ones due to vendor secrecy.
There are also cases where we can retrieve very reliable (hard-coded ID data) but since various ODMs sometimes rename the parts for marketing reasons we were asked not to show the fused identification...

Mumak wrote on Yesterday, 13:23:

Problem here is that even such "confidence level" is very difficult to estimate. In many cases we might be pretty confident abou […]
Show full quote

MattRocks wrote on Yesterday, 11:40:

Unfortunately eBay sellers sometimes use HWINFO as single source of truth when it's really a best guess based on a sample we can't see.

I think a really nice functional/reputational update to HWINFO would be to mark the lower confidence identifications "Provisional". My view is that doing this would encourage users to dig deeper and submit more details.

I also think a disclosure on how the identifications are made would be really good because users might then be stimulated to observe exceptions that are not currently invited.

Problem here is that even such "confidence level" is very difficult to estimate. In many cases we might be pretty confident about accuracy but due to some other factors that we're unable to reliably determine, the outcome can be different.
Our goal is to always provide most accurate results and avoid any "man in the middle". But this is sometimes impossible to achieve - on old systems due to the lack of sufficient indicators and on newer ones due to vendor secrecy.
There are also cases where we can retrieve very reliable (hard-coded ID data) but since various ODMs sometimes rename the parts for marketing reasons we were asked not to show the fused identification...

For items in my collection I have done quite a lot of work identifying specific products, and my conclusions sometimes conflict with HWINFO (and others). There's at least one example I posted on Vogons.org and RetroWeb subsequently aligned to the evidence I surfaced.

What do you propose be done in situations like that?

MattRocks wrote on Yesterday, 15:40:

Mumak wrote on Yesterday, 13:23:

Problem here is that even such "confidence level" is very difficult to estimate. In many cases we might be pretty confident abou […]
Show full quote

MattRocks wrote on Yesterday, 11:40:

Unfortunately eBay sellers sometimes use HWINFO as single source of truth when it's really a best guess based on a sample we can't see.

I think a really nice functional/reputational update to HWINFO would be to mark the lower confidence identifications "Provisional". My view is that doing this would encourage users to dig deeper and submit more details.

I also think a disclosure on how the identifications are made would be really good because users might then be stimulated to observe exceptions that are not currently invited.

Problem here is that even such "confidence level" is very difficult to estimate. In many cases we might be pretty confident about accuracy but due to some other factors that we're unable to reliably determine, the outcome can be different.
Our goal is to always provide most accurate results and avoid any "man in the middle". But this is sometimes impossible to achieve - on old systems due to the lack of sufficient indicators and on newer ones due to vendor secrecy.
There are also cases where we can retrieve very reliable (hard-coded ID data) but since various ODMs sometimes rename the parts for marketing reasons we were asked not to show the fused identification...

For items in my collection I have done quite a lot of work identifying specific products, and my conclusions sometimes conflict with HWINFO (and others). There's at least one example I posted on Vogons.org and RetroWeb subsequently aligned to the evidence I surfaced.

What do you propose be done in situations like that?

Please provide more details about those cases so that I can investigate them.

Hello Mumak!

I have a fairly obscure bug to report. Memory reporting seems to be broken for my retro X79 motherboard in Windows XP. As far as I can tell, the last version of HWInfo that was able to correctly report on my memory was 7.64. See version 8.52 for the buggy reporting. My Z77 boards do just fine with the latest version. Thanks.

Barley wrote on Today, 15:10:

Hello Mumak! […]
Show full quote

Hello Mumak!

I have a fairly obscure bug to report. Memory reporting seems to be broken for my retro X79 motherboard in Windows XP. As far as I can tell, the last version of HWInfo that was able to correctly report on my memory was 7.64. See version 8.52 for the buggy reporting. My Z77 boards do just fine with the latest version. Thanks.

The attachment 764.JPG is no longer available

The attachment 852.JPG is no longer available

Please provide HWiNFO Debug Files from both HWiNFO versions and I'll check that.

Mumak wrote on Today, 15:17:

Please provide HWiNFO Debug Files from both HWiNFO versions and I'll check that.