🩹 Bugfix Release: v2026.08.0017
🆕 What's Fixed
FriendlyName Keyword Filter Silently Dropped Legitimate Intel Devices
Problem: Get-IntelChipsetHWIDs pre-filtered every candidate Intel device by matching its Windows-generated FriendlyName against a fixed keyword list before the device was ever checked against the HWID database:
if ($description -match 'Chipset|LPC|PCI Express Root Port|PCI-to-PCI bridge|Motherboard Resources') {
# kept
} else {
# silently dropped
}Any live, functioning (Status -eq 'OK') Intel System-class device whose FriendlyName didn't happen to contain one of those words was excluded from detection entirely — before the script ever got a chance to look it up in the INF database.
How it was found: A Station-Drivers user reported that Driver Genius Free Edition flagged three Intel System devices as outdated on a Z270 desktop, while Universal Intel Chipset Device Updater reported the system as fully up to date:
| HWID | Device | FriendlyName |
|---|---|---|
1901 |
Skylake PCIe Controller (x16) | Intel(R) PCIe Controller (x16) - 1901 |
191F |
Skylake Host Bridge/DRAM Registers | Intel(R) Host Bridge/DRAM Registers - 191F |
1911 |
Skylake Gaussian Mixture Model | Intel(R) Gaussian Mixture Model - 1911 |
None of these three FriendlyNames contain any of the filter's recognized keywords. A full, unfiltered pnputil /enum-devices /class System dump from the affected system confirmed all three devices were present with Status: OK and an active driver (oem106.inf) — ruling out stale DriverStore records, non-live/hidden devices, or a wrong PnP class as the cause. The updater's own pre-filter was the sole reason they never appeared in the report. Full investigation: Issue #26.
Root cause: The keyword list was written early in the project, before a complete INF/HWID database existed, as a rough heuristic to guess which devices were "chipset-like" from their display name. It was never updated to account for device categories whose FriendlyName doesn't contain any of those words — which, going by the current INF database, includes several device-suffix families across multiple platforms and generations, not just the Skylake case above:
*SystemGMM.inf(Gaussian Mixture Model) — Skylake, Kaby Lake, Gemini Lake, Elkhart Lake*SystemThermal.inf— Skylake, Ice Lake*SystemNorthpeak.inf— Alder Lake, Gemini Lake, Lakefield, Meteor Lake, Panther Lake*SystemLPSS.inf(Low Power Subsystem) — Elkhart Lake, Emmitsburg, Gemini Lake, Lakefield*DmaSecExtension.inf— Alder Lake, Tiger Lake
Fix: The FriendlyName keyword filter has been removed entirely. Get-IntelChipsetHWIDs now collects every VEN_8086 System-class device with Status -eq 'OK' unconditionally; the real, authoritative filter is the existing downstream match against the full INF/HWID database ($chipsetData.ContainsKey($hwId)), which was always present and correct — the keyword filter was a redundant, error-prone layer sitting in front of it that was quietly excluding legitimate candidates before they ever reached it.
🔧 Full Changelog
Core Updater (universal-intel-chipset-device-updater.ps1)
Detection:
- Removed FriendlyName keyword pre-filter from
Get-IntelChipsetHWIDs; all liveVEN_8086System-class devices are now passed through to database matching unconditionally - Removed the now-unused
IsChipsetfield and the "fallback to first 5 non-chipset devices" branch, both made obsolete by the fix above
Performance:
Get-CurrentINFVersionpreviously calledGet-PnpDevice(full system re-enumeration) once per detected device to resolve its InstanceId — an O(n²) cost. It now accepts the PnpDevice object already obtained during initial detection via a new-Deviceparameter, avoiding the redundant re-scan. The original-DeviceInstanceIdparameter is kept as a fallback.
Display:
Found compatible platform(s):HWID lists now wrap at 12 IDs per line (3-space indent) instead of a single unwrapped line, fixing unreadable output on platforms with a large number of detected devices- Platform name lines changed from white to yellow for readability
- Merged the separate "Downloading latest INF information..." and "Parsing INF information..." messages into a single status line with a more accurate time estimate
Found N Intel chipset device(s)→Found N Intel device(s)/No Intel chipset devices found.→No Intel devices found.— this count is taken before database matching and is no longer implicitly pre-filtered to only name-matched "chipset-looking" devices
📊 Real-World Validation
Tested on a triple-platform Intel X79 system (IvyTown / Patsburg PCH / IvyTown CPU Root): detected device count rose from 12 to 59 after this fix, with all additional devices correctly matched to the same three known platforms — confirming the filter gap was systemic across platforms and generations, not limited to the originally reported Skylake devices.
📋 Release Files
universal-intel-chipset-device-updater.ps1— Main updater script (v2026.08.0017)ChipsetUpdater-2026.08.0017-Win10-Win11.exe— Self-extracting package (includes updated script)intel-chipset-infs-latest.md— Unchanged from v2026.07.0016intel-chipset-infs-download.txt— Unchanged from v2026.07.0016
🔒 Security Notes
- No changes to signature verification, download integrity checks, or installer execution logic. This release only changes which locally-present devices are detected and reported — it does not change what gets installed on systems where all detected platforms already mapped to the same Intel installer package.
📝 Notes
- Impact scope: on most systems, this bug did not prevent installation —
SetupChipset.exe -OVERALLperforms its own independent hardware matching regardless of what the updater detected or reported, so affected devices were often still serviced correctly by the installer even though the updater's report incorrectly showed them as absent. The practical impact was primarily incomplete/incorrect reporting. On systems where a missed platform would have required a different installer package than the one otherwise selected, actual installation could have been affected. - Recommended for everyone, particularly systems with older/EOL Intel platforms or multiple detected chipset generations, where the previously silent detection gap was most likely to matter.
- Backward Compatibility: Fully compatible with existing databases and installer packages; no database changes in this release.