VOGONS


HWiNFO support of vintage hardware

Topic actions

Reply 820 of 826, by Mumak

User metadata
Rank Oldbie
Rank
Oldbie
Barley wrote on 2026-09-23, 15:44:
Mumak wrote on 2026-09-23, 15:17:

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

The attachment HWiNFO32_852_debug.txt is no longer available
The attachment HWiNFO32_764_debug.txt is no longer available

Thanks! Try to enable the "Low-level PCI Access" option in HWiNFO and let me know if that worked.

Reply 821 of 826, by Barley

User metadata
Rank Member
Rank
Member
Mumak wrote on 2026-09-23, 16:43:

Thanks! Try to enable the "Low-level PCI Access" option in HWiNFO and let me know if that worked.

Sure did! Thank you! Is there a short and easy way to explain what the problem was? I'm especially curious about what was different with my chipset/motherboard to cause the issue.

Reply 822 of 826, by Mumak

User metadata
Rank Oldbie
Rank
Oldbie

Nothing is different with your system. It's due to certain security rules Microsoft introduced in kernel where they don't allow direct access to PCIe configuration space on some systems anymore.
Since this restriction resulted in BSODs on some systems, we have globally disabled the "Low-level PCI Access" option for all systems including legacy ones. But I didn't realize that the alternate function (via HAL) doesn't work as expected on XP and here the direct access is still required on systems like yours (where we need access to extended PCIe space). This will be fixed in the next HWiNFO build by enabling this option by default on such systems.

Reply 823 of 826, by Barley

User metadata
Rank Member
Rank
Member
Mumak wrote on 2026-09-23, 17:19:

direct access is still required on systems like yours (where we need access to extended PCIe space).

"extended PCIe space": do you mean systems with a plx chip, or a large number of native pcie lanes like my i7-4930K/Rampage IV Extreme?

Reply 824 of 826, by Mumak

User metadata
Rank Oldbie
Rank
Oldbie

Neither of those. It's the internal PCIe register space at offset 0x100 and above (so extended space from 0x100 in legacy PCI).

Reply 825 of 826, by Barley

User metadata
Rank Member
Rank
Member
Mumak wrote on 2026-09-23, 17:43:

Neither of those. It's the internal PCIe register space at offset 0x100 and above (so extended space from 0x100 in legacy PCI).

Thanks. I was curious because CPU-Z is having the same issues reading my memory, but unlike HWiNFO, there is no setting that I can find that will fix it, nor will downgrading to an earlier version fix it.

Reply 826 of 826, by MattRocks

User metadata
Rank Oldbie
Rank
Oldbie
Mumak wrote on 2026-09-22, 15:45:
MattRocks wrote on 2026-09-22, 15:40:
Mumak wrote on 2026-09-22, 13:23:

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.

I’m hesitating over how best to present the cases because some of my interpretations are still developing, even where I can evidence discrepancy.

One of your points particularly interests me. Where you were asked not to show fused identification, how did HWiNFO handle those requests?

From a historical research perspective, my aim is to preserve both the underlying identification and the marketed name - with an explanation of what each represents because the differences can be as interesting to hardware archaeology as they are to the study of marketing and strategy.

This also gets at my earlier concern: I’ve seen users treat HWiNFO’s displayed names as direct hardware readings. Is there a way for users to distinguish what is read directly from the hardware from what is assigned through a lookup or inference?

Desktop timeline [ MOS 7501 → 68030 → x86(P5/MMX) → x86(K6-2) → x86(K7*) → PPC(G3*) → x86-64(K8) → x86-64(Xeon) → x86-64(i7) ] * lost