Someone from WinClub posted a screenshot showing that version 10.1.37.7 (for Alder Lake)
was detected, while my tool detects 10.1.37.5 from the 10.1.20404.8794 installer.
I’m guessing Microsoft added the newer version to the Windows Inbox Drivers
—the drivers built into Windows 11—or it was installed via Windows Update.
In short, my tool detected something newer than Intel officially lists on its website.
At the time of writing, Intel is providing an even older installer on its website— 10.1.20398.8776 .
In the future, I plan to add an exception so that if a newer INF file is already present, the tool will
prevent installation of older versions, even if they come from Intel’s latest available installers.
Hi
I’m having this problem. I’m trying to update what appears to be the .inf file in the chipset. I want to download the latest Intel chipset version 10.1.20404.8794. When we get to step 4, download and install, it downloads the SetupChipset.msi file. However, when a dialog box appears, I can’t click the .msi installer. It only requires the .exe. Is there a way to fix this?
Thank you for the report. Let me clarify what I tested and provide precise steps.
My Test & Result:
I simulated your exact scenario. I forced my system (Intel X79) to install the optimized 10.1.20404.8794 MSI. The installation succeeded without error. This means the optimized MSI file itself is functional.
Therefore, the issue is specific to your system’s environment during the automated script run.
Immediate Action – Please Do This:
When the script fails, DO NOT CLOSE IT.
Open File Explorer and go to this folder: C:\Windows\Temp\IntelChipset\
Look for a subfolder named like 10.1.20404.8794-Consumer . Inside, you will find SetupChipset.msi .
Try installing it manually:
Double-click the SetupChipset.msi file, OR
Open Command Prompt as Administrator and run: msiexec /i "C:\Windows\Temp\IntelChipset\10.1.20404.8794-Consumer\SetupChipset.msi"
What This Tells Us:
If the manual installation works , the problem is with the script’s installation step (e.g., a permission context issue).
If the manual installation fails , you will see a specific Windows error message. This is the key clue.
Send Me These Logs:
The main script log: C:\ProgramData\chipset_update.log
If manual installation failed, note the exact error message from Windows.
Potential Causes on Your System:
Group Policies / Corporate IT Settings: Managed computers often have policies blocking modified or unsigned MSI packages.
Aggressive Security Software: Antivirus or endpoint protection may be intercepting the automated installation.
Windows Installer Service: It could be temporarily corrupted. Running sfc /scannow as admin can help.
Summary:
The file works. Please test it manually from the temp folder after the script fails and send me the chipset_update.log . The manual test result will point us directly to the root cause.
As you can see, Intel’s latest installer was installed successfully, despite containing no INF files applicable to my system. This is exactly why I created my own tool — to avoid installing Intel’s so-called chipset installer that performs no actual hardware configuration.
The problem is that during installation I want to install .msi and in the dialog box there is .exe. The installer is available in the temp folder but I can’t open it because it has the wrong extension.
I’ve double-checked the script and the package, and there’s nothing wrong with either.
The issue is that Windows Installer on your system fails before initialization and falls back to searching for an executable, even though the MSI package itself is valid. This is a problem with your Windows configuration, not with the file itself.
Most likely causes (and quick fixes):
Windows Installer service is damaged or not registered
→ Open Command Prompt as Administrator and run: msiexec /unregister msiexec /regserver
File associations for .msi are broken
→ In an elevated Command Prompt, run: ftype MSI.Package="%SystemRoot%\System32\msiexec.exe" /i "%1" %* assoc .msi=MSI.Package
Corrupted system files
→ In an elevated Command Prompt, run: sfc /scannow
then dism /online /cleanup-image /restorehealth
MSI is being treated as an executable instead of an installer package
→ Check the following registry keys and ensure they point to msiexec.exe: HKEY_CLASSES_ROOT\.msi HKEY_CLASSES_ROOT\MSI.Package\shell\Open\command
If these entries reference any executable wrapper or third-party handler, Windows may fail to initialize the MSI engine and instead prompt for an .exe file.
Third-party antivirus or security software interfering with Windows Installer
→ Temporarily disable real-time protection or add an exclusion for msiexec.exe and the installer directory.
Some endpoint security solutions hook into MSI execution and can silently break Custom Actions or override file handling, resulting in non-standard installer behavior.
Why this is definitely your system’s issue:
The same exact MSI file works instantly on other Windows machines. When a system treats a valid .msi file like a generic .exe, it’s almost always one of the above configuration problems.
I’m sorry, but all evidence confirms the problem is with your operating system. To test this definitively, download the 7-Zip MSI installer – there’s about a 90% chance you’ll see the exact same behavior.
You can also try installing the “full” installer from Intel. In reality, it will unpack and attempt to install the exact same MSI file that my updater downloads—I’m genuinely curious what will happen in that case.
*If you ask me, I’d even install an Intel installer hosted on P**nHub, as long as it had a valid Intel digital signature. Origin doesn’t matter; the certificate does.
I already solved it, I uninstalled the chipset version from .exe and updated it using your tool and it worked, 0 errors, it was not a problem with .msi
Glad to hear it’s working now
So in this case, it looks like the legacy Intel EXE installer was blocking the installation of the newer version, and removing it resolved the issue.
What’s interesting is that on my systems, having the older Intel EXE installer installed does not interfere with installing the newer MSI version — as shown in the screenshot, both can coexist without problems. In general, upgrading from older EXE-based installers to newer versions should also work without any issues.
Regarding the updater itself, I consider its current behavior to be about 99.9% optimal. I’ve only identified a few minor cosmetic issues, for example when no Intel devices are detected and some UI messages are not formatted correctly.
One important architectural improvement was separating the updater from its database. I recently found a bug in the database generator (no changes to the updater code were required).
In short, fixed a multithreading race condition that caused ~13,000 out of 99,653 device relationships to be randomly lost during processing. The generator now correctly processes all 5,296 INF files with deterministic results. By relationships I mean: HWID ↔ Platform ↔ Package Version ↔ INF Version ↔ Date
This project is primarily a hobby through which I explore and test my own capabilities, including close collaboration with AI-based tools. Interestingly, this approach has proven to be surprisingly effective—often more so than solutions produced by large corporate teams.
That said, I’m unfortunately not able to diagnose every individual system-specific issue. For that reason, I usually look into a reported problem only after it’s confirmed by at least three users.
Thanks for reporting back with the outcome — it’s always useful to know how these cases resolve.
New Windows Inbox INF detection prevents accidental downgrades
Enhanced user guidance when Windows Update provides newer drivers
Summary: v2026.02.0008 enhances Windows Inbox INF detection to prevent accidental downgrades when Windows Update provides newer driver versions than Intel packages. The update improves version comparison logic, adds clearer status messages, and maintains all hardware-accurate platform detection features from previous releases.
Technical Deep Dive: Installation Order Fix
Problem: When Intel removes specific HWIDs from newer installer packages, but your hardware still needs those drivers:
Example: Package v1.0 has HWID1, HWID2, HWID3
Package v1.1 only has HWID2, HWID3 (Intel deprecated HWID1)
Installing v1.1 first, then v1.0 would downgrade HWID2 and HWID3
Solution: Sort packages by version (oldest → newest) before installation:
v1.0 installs first → HWID1, HWID2, HWID3 all installed
v1.1 installs second → HWID2 and HWID3 upgraded, HWID1 unchanged
Result: All drivers at their maximum available version, no downgrades
Code Change (line ~1714 in PowerShell script):
# Sort packages by version (oldest first) to prevent downgrade when installing missing HWIDs
$sortedPackages = $uniquePackages.GetEnumerator() | Sort-Object {
$versionString = $_.Key -replace '-.*$', ''
try { [version]$versionString } catch { $versionString }
}
foreach ($entry in $sortedPackages) {
# Installation logic...
}
This ensures legacy platforms receive optimal driver coverage without sacrificing newer updates for actively supported HWIDs.
I had to fix the Scanner app (the brain of this project), and it took about 100 code correction attempts - it finally works!
Additionally, the 3 largest AI models were brainstorming together on how to fix the historical naming of platforms, and we came to the conclusion that we’d focus on technical rather than marketing aspects.
Fun fact (I should note that I’m only using free versions of LLMs):
Claude got stuck in an endless diagnostic loop that added no value.
ChatGPT gave up right at the start, because the free version has significantly limited memory and couldn’t process the long code.
DeepSeek initially struggled like Claude, but it used my suggestions and ultimately fixed the code (with over 100,000 entries, we disabled multithreading, as it only made the process more complicated).
Hi @FirstEver
Thank you for the Universal Intel Chipset Device Updater program.
I have a few questions. When I run Universal Intel Chipset Device Updater, it doesn’t detect the following devices in my system:
And after installing chipset driver 10.1.18981.6008, the devices listed in the program are updated to version 10.1.3.2, with the exception of PCI\VEN_8086&DEV_1E44 (it doesn’t install).
PCI\VEN_8086&DEV_1E44
the update wizard reports that these are the current versions (and no update is required).
BUT, Windows itself offers to update them and the devices (PCI\VEN_8086&DEV_0150; PCI\VEN_8086&DEV_1E22; PCI\VEN_8086&DEV_1E44) are updated to version 10.1.13
Question:
Why doesn’t the Universal Intel Chipset Device Updater see these devices?
Why aren’t they installed either through the chipset driver installation or manually, even though these VEN&DEV devices are listed?
These devices are from a legacy platform that is no longer actively updated in current public Intel chipset packages.
Why the Updater does not detect them
The Universal Intel Chipset Device Updater only recognizes hardware IDs that are present in official Intel-distributed chipset INF packages.
Since none of the 93 Intel installers contain INF entries for these HWIDs, the tool correctly does not list them as supported or updatable.
Why Windows Update installs version 10.1.13
The 10.1.13.x drivers offered by Windows Update are Microsoft-distributed system drivers, not part of the publicly available Intel chipset installer packages.
Microsoft sometimes republishes or repackages Intel chipset INF components under its own update channel. These packages may:
Contain additional hardware IDs
Use extended or merged INF sets
Be digitally signed and distributed independently of Intel’s public releases
That is why:
Manual update via Intel installer reports “current version”
The Universal Intel Chipset Device Updater does not detect them
Windows Update still offers a newer 10.1.13.x system driver
Summary
There is no detection bug in the tool.
Those specific HWIDs simply do not exist in any official Intel chipset installer INF file. The versions you receive via Windows Update originate from Microsoft’s driver distribution channel, not from Intel’s published chipset packages.
Thanks for the reply.
But these device identifiers are included in the IvyBridgeSystem.inf and PantherPointSystem.inf packages, as supported ones, just like the others.
Am I correct in thinking that these device identifiers don’t need to be updated?
You are correct that those device identifiers appear in older packages such as IvyBridgeSystem.inf and PantherPointSystem.inf.
However, based on my analysis of the complete Intel chipset INF archive (covering all public installers starting from version 10.0.13.0 – February 2014 up to the latest available release), Intel has not included any updated INF entries for those specific HWIDs in their packages since that time.
In other words:
Yes — the devices are supported in legacy INF packages.
No — Intel has not provided any newer chipset INF definitions for those devices in modern releases.
Therefore, the versions currently installed (often provided directly by Windows) are effectively the latest available definitions.
My tool only processes and compares INF files that are actually present in Intel’s official chipset installers. Since those HWIDs have not been included in updated Intel packages for many years, there is nothing newer to deploy from Intel’s side.
So yes — in practice, those device identifiers do not require updating beyond what Windows already provides.
If Intel ever reintroduces updated INF definitions for those devices in future packages, the tool will detect and process them accordingly.
Minimum Requirements: Windows 10 LTSC 2019 (build 17763) or newer, .NET Framework 4.7.2+
Database rebuild: Run the scanner after updating to regenerate Xeon E5 v1 - Jaketownintel-chipset-infs-latest.mdXeon E5 v1 - Jaketown
Core updater logic (Windows Inbox detection, version comparison) unchanged from v2026.02.0008
Summary:
v2026.02.0009 fixes a critical database issue where 300 Series (Cannon Lake PCH) was missing from the generated INF list.
All HWIDs are now correctly displayed, and console output formatting has been polished. The updater retains all previous enhancements, including Windows Inbox INF detection.
May I ask if it is possible to make a modified version that installs without an internet connection (on the premise that all driver file archives have been downloaded from your GITHUB repository and placed in a specified local directory, such as the Drivers directory in the same folder as the script), then checks and verifies the hash values from the local directory before installing the corresponding driver file archives, as in some cases the machine is completely offline.
Thank you for the suggestion. I understand the use case for completely offline machines.
However, I will not bundle any Intel INF files or installers directly inside this tool. The tool is designed to be a lightweight, transparent updater that fetches the official packages, verifying them with SHA-256 hashes to ensure integrity and safety.
You can modify the PowerShell script yourself to work from a local installers.
Today I updated my Windows 11 build 28020.1619 to version 29531.1000 (Canary Channel)
and noticed that the system had restored older versions of the INF files.
It’s strange that Windows would do something like this…
In such a case, remember that after updating the system you should run the updater
and check whether you still have the latest versions of the INF files.
Just a quick update on the Universal Intel Chipset Updater.
The tool has been running absolutely flawlessly for quite some time now — no new bug reports, no issues, despite being used by thousands of people. Most questions I get turn out to be related to the users’ own systems, not the updater itself.
Error 1603 during MSI installation
Since everything has been stable, I recently took some time to help a user who was struggling with a corrupted previous installation of the Intel Chipset Device Software. Because of that corruption, they couldn’t install any newer versions — even those offered by my updater — and kept running into Error 1603 .
I helped them clean up the broken installation manually, and in the end, they were finally able to use the updater successfully.
This issue isn’t limited to Intel Chipset Device Software — Error 1603 can affect any MSI package when the old installation is damaged. So I documented the entire solution, hoping it might help others in the future.
Heads-up for Admins: Upcoming Update with Admin-Friendly Features
I’m happy to announce that tomorrow I’ll be releasing a new version of the Universal Intel Chipset Device Updater with several enhancements specifically designed for administrators and automated deployments.
What’s new?
The script will now include dedicated command-line options. These allow for fully unattended execution, silent operation, and fine-grained control – perfect for integrating into MDM solutions like Microsoft Intune, SCCM, Workspace ONE, or PDQ Deploy.
Key improvement:
The PowerShell script (.ps1) can now be used completely independently – no more need for the batch wrapper (Run.bat). Of course, if you’re already using the .bat file, it will continue to work without any issues; the script is fully backward compatible.
Why this matters for admins:
By using the .ps1 directly, you avoid the common pitfalls associated with self-extracting executables (SFX) – no more concerns about unsigned code, local certificate warnings, or antivirus false positives. The script is just plain text, easily reviewable, and can be executed with your preferred execution policy settings.
Once the new version is live, you’ll be able to grab it from the usual place (GitHub) and soon also from the PowerShell Gallery.
Latest Release: v2026.02.0008
Highlights
Technical Updates
Bug Fixes
Included Files
Requirements & Notes
Technical Deep Dive: Installation Order Fix
Highlights
Requirements & Notes
Error 1603 during MSI installation
