Universal Intel Chipset Drivers Updater​

on an old gigabyte motherboard with Skylale chipset, version 2026.08.0017 totally disables internal audio (realtek), I had to use Windows 11 restore point

hitman72ita 写�：:

on an old gigabyte motherboard with Skylale chipset, version 2026.08.0017 totally disables internal audio (realtek), I had to use Windows 11 restore point



 

Thanks for reporting this. Just to clarify: `2026.08.0017` is the version of the Universal Intel Device Updater, not the Intel chipset INF version itself. On Skylake, the updater installs the applicable Intel chipset INF files such as `SkylakeSystem.inf`, `SkylakeSystemGMM.inf` and `SkylakeSystemThermal.inf`. These are chipset/system INFs; they do not contain Realtek audio or Intel SST audio drivers.

So the updater does not directly install or replace the Realtek audio driver. However, the fact that the audio stopped working immediately after the INF installation is worth investigating. Installing chipset INFs can trigger Windows Plug and Play re-enumeration and driver re-evaluation, so it is technically possible that something changed in the device state or driver binding.

If you can reproduce the issue, could you please collect the following?

1. Before running version `2026.08.0017`, when audio is working:

• Share your `C:\Windows\INF\setupapi.dev.log`

2. Immediately after installing the updater, when the Realtek audio is no longer working:

• Share your another copy of `C:\Windows\INF\setupapi.dev.log`
• Check Device Manager → Sound, video and game controllers and also System devices.
• Please note whether the Realtek/High Definition Audio device:
  • disappears completely,
  • appears with a yellow warning icon,
  • or remains present but reports an error (e.g. Code 10, 28 or 31).

3. If possible, after restoring the Windows restore point and getting the audio back:

• Share another copy of `C:\Windows\INF\setupapi.dev.log`

The before/after `setupapi.dev.log` files are particularly useful because they are Windows SetupAPI/PnP logs, not just Intel installer logs. They may show which devices were re-enumerated and which INF/driver packages Windows selected during the update.

If you can also provide the motherboard's exact Gigabyte model, that would be very helpful, because "Skylake" covers several different desktop platforms.

With those details we should be able to determine whether the chipset INF installation actually changed the audio device/driver state, or whether the timing was coincidental.

Something to consider, as far as which is the deciding factor: driver version vs. driver date? Driver Fusion opts for the newer DRIVER DATE, while Driver Genius opts for the newer DRIVER VERSION. So; for Intel Chipset drivers, the newer driver version may end up being dated JULY, 1968, when allowing Driver Genius to make the decision. If using Driver Fusion, the older driver by version number but newer by date will be picked for installation. 
Also note: Intel's own Chipset installation software will follow the same option path as Driver Fusion, so that the driver date is considered more important than the driver version number. 
If you compare the end result (installed using Intel's own latest version of Chipset software) after a brand-new fresh Windows installation, compared with the end result after first using Windows Update and other 3rd-party driver update software, you end up with a different list of Chipset driver versions.  
Note for audio ussues: there's a free software "Display Driver Uninstaller" that includes the option to clean out remnants of Realtek Audio drivers. Should be run while booted into Safe Mode. Then reboot into Normal Mode, & then run the full "Setup.exe" Realtek Audio installer.

I forgot to mention that the updater now supports the latest Intel Chipset Device Software installer ( v10.1.20658.8883 )

Additionally, I've created a tracking issue on GitHub for the audio problems reported after Intel chipset INF updates: github.com/FirstEverTech/Universal-Intel...et-Updater/issues/31
It covers both the Realtek issue on Gigabyte Skylake and the Creative Sound Blaster issue on EVGA X299 Dark. If you have any additional details or logs to share, please post them there – it will help me investigate and resolve these conflicts more effectively.

After analyzing this issue, I have come to the conclusion that there is a high probability of audio problems occurring on systems where the chipset INF package contains cAVS (*SystemcAVS.inf).

The problem appears to be directly related to Intel cAVS / Smart Sound Technology and the way Windows re-enumerates and binds the audio device after installing this INF. This may affect systems where the OEM uses additional or customized audio hardware/drivers, such as Realtek, Creative, etc.

I could potentially solve this problem in the Updater, but there is one major problem: I do not have access to a machine that actually uses this type of cAVS/SST audio configuration and where the problem can be reliably reproduced.

If anyone has such a system and is willing to spend some time helping to find a proper solution, please let me know. We will definitely need to analyze C:\Windows\INF\setupapi.dev.log before and after installing the problematic INF. This should allow us to determine exactly which device was re-enumerated, which INF was selected by Windows, and how the driver binding changed.

What I will do in the meantime

I will prepare a new version of the Universal Intel Chipset Updater which will detect cAVS in the INF package and warn the user before installation.

The workflow will be:

1. User cancels the installation → no changes are made.
2. User continues, installation completes and audio still works → everything is OK.
3. User continues, installation completes but audio stops working → the user can use the previously created Windows System Restore point to return to the state before the update.
4. User runs the Updater in silent/automatic mode (-quiet / -auto) → cAVS is detected → the installation is automatically aborted to prevent a potential audio compatibility problem.

The warning will also inform the user that a System Restore point should be created before continuing. If the Updater is unable to create or verify the restore point, the user will be informed before proceeding. At this point, I cannot offer a better and safe solution. As I understand it, Intel is effectively ignoring this particular compatibility problem, while I do not have the necessary hardware to reproduce and investigate it properly. I also do not want to simply block all cAVS packages, because we need real-world data to determine exactly what the INF installation changes and how the resulting audio configuration can be safely restored without reverting the entire system.

If anyone has an affected platform and is willing to help investigate this, please contact me. The most valuable information would be the setupapi.dev.log files and the exact device state before and after installing the INF.

One important clarification: the disappearing/broken audio issue is not caused by my Updater itself.

The Updater installs the official Intel Chipset Device Software / INF files. If the official Intel package contains a cAVS INF, installing that package manually from Intel's website can trigger exactly the same issue on affected systems. The Updater does not modify, replace, or create the Intel INF files — it simply identifies and installs the applicable packages. In other words, the same potential audio problem can occur when using Intel's own latest official INF installer directly. The Updater only makes the problem more visible because its purpose is to find and install the latest applicable Intel INF files automatically.

This appears to be an Intel compatibility issue that Intel has not adequately addressed. I am therefore adding the cAVS detection and warning to the Updater as a safety measure, rather than because the Updater is the cause of the problem. The goal is not to hide or work around the issue, but to prevent users from unknowingly applying an INF package that may affect their audio configuration.