FirstEverTech/Universal-Intel-Chipset-Updater v2026.08.0018

v2026.08.0018 - Release Notes

on GitHub

🛡️ Safety Release: v2026.08.0018 — cAVS Audio Safeguards + EOL Package Handling

🆕 What's New

Warning and Safeguards for Intel SST/cAVS Audio INF Conflicts

Problem: Some chipset packages — particularly EOL and mobile PCH packages — include *SystemcAVS.inf files, which provide device identification for Intel Smart Sound Technology (SST). The chipset INF package does not install audio drivers itself. However, when these cAVS INFs are applied on a system where the OEM used a non-Intel audio codec (Realtek, Creative Sound Blaster, etc.), Windows Plug and Play can re-enumerate the audio controller from the generic "High Definition Audio Controller" to an Intel SST device. The third-party audio driver can no longer attach to the (now differently identified) device, and sound output breaks.

How it was found: Two independent reports on Issue #31:

Both cases trace back to the same underlying pattern: an SST/cAVS INF being applied on a system with a non-Intel audio codec.

Root cause: Still under investigation upstream — it is not yet fully established whether the affected EOL/mobile PCH packages are incorrectly classified as applicable to desktop platforms with third-party audio, or whether the SST INFs should be excluded from certain packages entirely. Reproducing this reliably requires a system with this specific cAVS/SST + non-Intel-codec configuration, which is not currently available for direct testing. This release does not fix the underlying INF conflict — that requires more real-world setupapi.dev.log data (before/after installation) from affected systems, which is still being collected via Issue #31. What this release does is make sure the updater never silently walks a user into this failure mode.

Fix (mitigation): The updater now detects cAVS INFs in any matched package before making any changes, and handles the two operating modes differently:

• Interactive mode: after the user agrees to update, but before the System Restore point is created or a single file is touched, the updater checks whether any matched platform's package includes a cAVS INF. If so, it shows an explicit warning naming the affected platform(s), explaining the risk, and linking to Issue #31 — and requires a Y/N confirmation to proceed. Answering N cancels the run with no changes made to the system. If the user proceeds and the automatic System Restore point creation subsequently fails or can't be verified, a second, more urgent warning is shown and again requires explicit confirmation before installation continues. After a successful install involving a cAVS package, the final summary reminds the user to check Device Manager → Sound, video and game controllers after reboot, and to use System Restore if the audio device is missing, shows a warning icon, or reports an error code.
• Unattended mode (-auto / -quiet): there is no user present to accept the risk, so detecting a cAVS package now aborts the run before any system changes — no restore point is created, no INF is installed. The process exits with code 3, distinct from the generic error exit code 1 used elsewhere in the script, so scheduled tasks and deployment tooling can distinguish "held back for a manual decision" from an actual failure and route it to a human instead of silently proceeding or blindly retrying.

Explicit Choice and Safeguards for Legacy (EOL) INF Packages

Problem: Some detected HWIDs are only covered by an older, End-of-Life (EOL) chipset INF package, because the "latest" package for that platform no longer lists them — Intel has moved or dropped the HWID over time, in some cases into a completely separate installer, such as the Intel Serial IO Drivers package. Previously, any matched EOL package was installed automatically and silently alongside the main package, with no way to opt out and no distinction between an EOL package that's genuinely needed and one that's obsolete because a different, newer Intel package already services that HWID.

How it was found: Reported via Station-Drivers forum feedback, where a matched TigerLakePCH-H platform showed an EOL package with a detected INF version (30.100.2413.49) already newer than the EOL package itself (10.1.34.8) — indicating the HWID was already serviced by a separate, more current Intel package.

Fix:

• Explicit choice (interactive mode): when a matched EOL package's status is Update available, the updater now shows the affected platform(s) and asks the user to choose: (1) install everything, including the EOL package(s), then the rest, or (2) skip the EOL package(s) and install all other INF files.
• Skip by default (unattended mode): in -auto / -quiet mode, these EOL packages are now skipped by default, since there is no user available to make an informed choice.
• Automatic block for downgrade risk (both modes): if an EOL package's own status is Inbox / newer detected — meaning the currently installed INF for that HWID is already newer than the EOL package would install — the EOL package is now excluded from installation unconditionally, with no prompt, in both interactive and unattended mode. Installing it would downgrade the driver. The updater reports the affected platform(s) and the version comparison (Detected: X > EOL INF: Y) that triggered the block.
• If, after skipping or blocking, no packages remain to install, the updater exits cleanly with an explanatory message instead of proceeding to create a restore point for nothing.

🔧 Full Changelog

Core Updater (universal-intel-chipset-device-updater.ps1)

Safety:

• New cAVS detection pass over all matched platform INF lists, run after the user's initial update confirmation and before System Restore point creation
• New interactive warning + confirmation gate on cAVS detection, with cancellation leaving the system fully unmodified
• New second confirmation gate if System Restore point creation fails/cannot be verified while a cAVS package is pending install
• New unattended-mode fail-closed behavior: cAVS detection aborts the run with exit code 3 before any restore point creation or installation, in both -auto and -quiet (quiet relaunches with -auto internally, so this covers both)
• New post-install reminder in the final summary when a cAVS package was installed, pointing the user to Device Manager and System Restore

EOL package handling:

• New per-platform persistence of update status (Latest version / Update available / Inbox / newer detected), so the install-flow logic can act on it instead of it being discarded after the status line is printed
• New interactive 1/2 prompt for EOL packages whose status is Update available: install everything including EOL, or skip EOL and install the rest
• New default-skip behavior for those same EOL packages in unattended mode (-auto / -quiet)
• New unconditional block, in both interactive and unattended mode, for EOL packages whose status is Inbox / newer detected (currently installed INF is already newer than the EOL package — installing it would downgrade the driver)
• New clean-exit path when skipping/blocking EOL packages leaves nothing to install, avoiding an unnecessary restore point creation attempt

Versioning:

• Script version bumped to 2026.08.0018

📊 Real-World Validation

• No new hardware validation for this release — both changes are process/logic safeguards around already-reported behavior (cAVS audio conflicts via Issue #31; EOL package version conflicts via Station-Drivers forum feedback), not changes to what gets detected. Real-world setupapi.dev.log data from affected systems is still being collected via Issue #31 to work toward an actual root-cause fix for the cAVS conflict.

📋 Release Files

• universal-intel-chipset-device-updater.ps1 — Main updater script (v2026.08.0018)
• ChipsetUpdater-2026.08.0018-Win10-Win11.exe — Self-extracting package (includes updated script)
• intel-chipset-infs-latest.md — Unchanged from v2026.08.0017
• intel-chipset-infs-download.txt — Unchanged from v2026.08.0017

🔒 Security Notes

• No changes to signature verification, download integrity checks, or installer execution logic.
• No new INF packages, HWID mappings, or download sources introduced. The behavioral changes are: certain installs (those involving a cAVS INF) now require explicit acknowledgment in interactive mode, or are held back entirely in unattended mode; and EOL packages are now conditionally skipped, offered as a choice, or blocked, based on data already present in the existing database.

📝 Notes

• Impact scope: this release does not change platform/HWID detection or which packages are matched — it only adds: (1) a warning/confirmation step (interactive mode) or an abort (unattended mode) when a matched package contains a cAVS INF; and (2) a choice, default-skip, or unconditional block for matched EOL packages, depending on their update status. Systems with no cAVS-containing package and no EOL-package match will see no behavior change.
• Recommended for everyone, but especially relevant for anyone running the updater unattended (scheduled tasks, fleet deployment via -auto/-quiet) on systems with EOL/mobile PCH platforms or non-Intel audio codecs, where a silent audio breakage or an unwanted/downgrading EOL install was previously possible.
• Backward Compatibility: fully compatible with existing databases and installer packages; no database changes in this release. Exit code 3 is new for cAVS and unrelated to EOL handling — skipping or blocking EOL packages does not introduce a new exit code and does not itself count as a failure; automation that only checks for exit 0 vs. non-zero will still correctly treat cAVS aborts as "did not complete," but tooling that wants to distinguish it from a hard failure should special-case code 3.
• Known limitation (cAVS): the current detection is INF-filename-based (cAVS) and does not yet inspect the actual installed audio codec (e.g. via Win32_SoundDevice) to determine whether the warning is actually applicable to the specific system. This means the warning may appear on some systems where the SST device wouldn't conflict with anything (no non-Intel audio device present). Targeted skip/detection logic based on the locally detected audio codec is tracked as a follow-up in Issue #31.
• Known limitation (EOL handling): the "already newer than EOL package" block relies on a plain version-number comparison ([version] parsing) against whatever INF version is currently reported for that HWID. It does not itself identify which separate Intel package (e.g. Intel Serial IO Drivers) provided that newer version — it only infers that some other package must have, since the EOL package didn't. On systems where the newer version happens to be an actual Windows Update inbox driver rather than a separate Intel package, the block still applies, since installing an older EOL INF over it would still be a downgrade.

Full changelog →