Problem: Audio device conflicts after chipset INF update (SST / Realtek / Creative)

[FirstEverTech]

Audio device conflicts after chipset INF update (SST / Realtek / Creative)

This is a tracking issue for audio-related problems reported after installing Intel Chipset Device Software via the Universal Intel Chipset Updater.

---

Issue 1 – Realtek audio disabled on Gigabyte Skylake motherboard

Reported by: hitman72ita (Station-Drivers)
System: Old Gigabyte motherboard, Skylake chipset, Windows 11
Symptom: After running Updater version 2026.08.0017, internal Realtek audio was completely disabled. System restore was required to recover audio.

Status: Under investigation – user was asked to provide setupapi.dev.log before/after installation.

---

Issue 2 – Creative Sound Blaster Recon3Di breaks on EVGA X299 Dark

Reported by: Forum user (Station-Drivers)
System: EVGA X299 Dark motherboard, Creative Sound Blaster Recon3Di, Windows
Symptom: KabyLakePCH-H EOL package (10.1.1.37) containing Intel SST Audio INF files caused the audio controller to be reassigned from "High Definition Audio Controller" to an Intel SST device. The Creative driver could no longer attach, breaking sound output.

HWID: A2F0
Platform: KabyLakePCH-H (200 Series PCH) – marked as EOL in the database
Detected INF: 10.0.26100.8972, 2603.9.4.0
Latest INF proposed: 10.1.1.36

---

Common pattern

Both issues appear to be related to Intel Smart Sound Technology (SST) INF files, which are included in some chipset packages (particularly EOL/mobile PCH packages). The chipset INF package does not install audio drivers – it only provides device identification. However, when SST INFs are applied to systems with non-Intel audio codecs (Realtek, Creative), Windows Plug and Play may reassign the audio controller from the generic "High Definition Audio Controller" to an Intel SST device, preventing the correct audio driver from attaching.

---

Proposed actions

1. Review EOL package classification – The KabyLakePCH-H package (10.1.1.37) should be evaluated to ensure it does not incorrectly target desktop platforms with third-party audio codecs.
2. Investigate SST INF inclusion – Determine whether SST-related INFs should be excluded from certain desktop/server chipset packages to avoid these conflicts.
3. Add warning or skip logic – Consider adding a safety check in the Updater to detect non-Intel audio controllers and skip SST-related INFs on those systems.
4. Gather more data – Affected users are encouraged to provide setupapi.dev.log before/after installation and their exact motherboard model.

---

Related links

• Intel Smart Sound Technology (SST) – known conflicts with Realtek audio
• Previous discussion on Station-Drivers

---

If you are experiencing a similar issue

Please share:

• Motherboard / laptop model
• Audio codec (Realtek, Creative, etc.)
• setupapi.dev.log from C:\Windows\INF\ before and after installation
• Device Manager state of the audio device (disappeared, yellow exclamation, error code)

This will help identify the root cause and prevent future conflicts.

---

CC: @FirstEverTech

[FirstEverTech]

Issue 1

hitman72ita wrote:
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.

[FirstEverTech]

Issue 2

x299 Owner wrote:
The latest version 2026.08.0017 is suggesting an update for :

Platform: KabyLakePCH-H [EOL] / 200 Series - Kaby Lake PCH-H (Mobile High Performance) Latest Intel Chipset INF Utility: 10.1.1.37 (30/09/2016*) Detected INF: 10.0.26100.8972, 2603.9.4.0 -> Latest INF: 10.1.1.36 -> Update available

Applying this update ends up disabling/breaking the integrated Creative Sound Blaster Recon3di sound card on a EVGA x299 Dark motherboard. The device this driver updates currently/correctly appears as a "High Definition Audio Controller" in Device Manager but after the update appears as a different device ("clear voice" or something like that).

The hardware ID is A2F0. From the tool:

Found 55 Intel device(s)
INF database download & hardware matching in progress... (up to 1 minute)

Found compatible device(s)

• Skylake-E devices (HWID):
  2014, 2015, 2016, 2018, 2020, 2021, 2024, 2025, 2026, 2030, 2033, 2034,
  2035, 2036, 2040, 2041, 2042, 2043, 2044, 2045, 2046, 2047, 2048, 2049,
  204A, 204B, 204C, 204D, 204E, 2054, 2055, 2056, 2057, 2066, 2080, 2081,
  2082, 2083, 2084, 2085, 2086, 208D, 208E

• KabyLakePCH-H devices (HWID):
  A294, A299, A2A1, A2A3, A2B1, A2BA, A2D2, A2E0, A2E1, A2E9, A2EB, A2F0

From your chipset latest.md:

KabyLakePCH-H EOL
Generation: 200 Series - Kaby Lake PCH-H (Mobile High Performance)

INF Package Version Date HWIDs
KabyLakePCH-HSystem.inf, KabyLakePCH-HSystemcAVS.inf 10.1.1.37 10.1.1.36 30/09/2016* A2BA, A2BB, A2BC, A2BD, A2BE, A2F0

Thank you for the detailed report – this is exactly the right way to reach me.

What you're experiencing is another variant of the SST (Smart Sound Technology) conflict, this time with the Creative Sound Blaster Recon3Di on your X299 board. The HWID A2F0 is part of the KabyLake PCH-H EOL package, which contains Intel SST Audio INF files. When the system applies this INF, it can reassign the audio controller from the generic "High Definition Audio Controller" to an Intel SST device, breaking the Creative driver's ability to attach.

The chipset INF package does NOT install audio drivers – it only provides device identification. However, if your board uses a non-Intel audio codec (like Creative), the SST INF can cause the controller to be misidentified, preventing the correct driver from loading.

Solutions:

1. Skip this specific update – the EOL package (10.1.1.37) is only needed for mobile Kaby Lake systems, not for desktop X299 with Creative audio.
2. If already applied – roll back the driver for the audio controller in Device Manager to "High Definition Audio Controller" and block future updates for that specific HWID.

I'll review the EOL package classification to ensure it doesn't incorrectly target desktop platforms with third-party audio codecs. Thank you for bringing this to my attention – this is valuable feedback for refining the database.

[FirstEverTech]

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.