Final AX200 EOL driver package possibly broken (hardcoded GUID in file path)

[bubsi]

Continuing from a related thread as @JeanetteC_Intel suggested (https://community.intel.com/t5/Wireless/A-newer-product-version-is-already-installed-With-AX200/td-p/1752050).

I believe the final driver provided for the AX200 wifi adapter is broken as there appears to be a hardcoded GUID in the startup path (assume it was a dev testing and forgot to revert, I've made similar mistakes :D). It's possible if anyone downloads this package (whether they have an AX200 installed or not) they may experience the same result (no installer GUI loading).

24.20.2.1 AX200 driver https://www.intel.com/content/www/us/en/download/915475/intel-wireless-wi-fi-drivers-for-intel-wi-fi-6-ax200.html

WirelessSetup.exe never gets as far as detecting an existing install, it dies during BA startup parsing setup.xml. Ran it with verbose Burn logging enabled and got this every time:

i000: _startupDir = C:\WINDOWS\Temp\{FAE1DE06-3D6D-4179-91BA-9220E6B5864B}\
i000: Parsing BundleSettings...
e000: Exception caught: System.IO.FileNotFoundException: Could not find file 'C:\WINDOWS\Temp\{FAE1DE06-3D6D-4179-91BA-9220E6B5864B}\setup.xml'.
at CommonUtils.OsFiles.XmlDocumentWrapper.XmlDocumentWrapper.Load(...)
at IDK.Core.CustomBAConfig.BundleSettingsParserBase.Parse(...)
at IDK.Core.BootstrapperApplication.CoreBA.ParseInstallDataConfigurationFiles()
i500: Shutting down, exit code: 0x647

GUID {FAE1DE06-3D6D-4179-91BA-9220E6B5864B} shows up identically across 5 separate runs, but the actual WixBundleSourceProcessFolder the SFX extracted to is different every time (different GUID per run, as expected). So _startupDir isn't being set from the real extraction path, it looks like it's reading a value baked in at build time rather than the runtime extraction dir. Confirmed it crashes before any command-line switch is processed (tried plain run, /uninstall, -extract:, /extract: same exception every time, same exit code, no UI ever shown beyond UAC).

No related bundle interference either, I checked, only the unrelated 24.40.0.4 bundle (latest driver I'd mistakenly grabbed first) was present and got fully removed before testing this.

Box is a desktop, custom build, Win11 26200, AX200 onboard (DEV_2723, SUBSYS_00848086).

I realize this is EOL so probably low priority.

[LohithG]

Hello bubsi,

Thank you for posting in the Intel Community Forum and for providing such a detailed description of the issue along with your observations. I appreciate the time you've taken to investigate the behavior and share your findings.

To help me better understand whether this behavior is specific to your environment or reproducible with the published installer, could you please help me with the following information?

• Can you confirm whether re-downloading the installer from the Intel Download Center results in the same behavior?
• When did you first notice this behavior? Has the installer always failed this way, or did it start occurring after a particular Windows update, software installation, or system change?
• You mentioned that this is a custom-built desktop. Is the Intel Wi-Fi 6 AX200 integrated into the motherboard, or is it installed as a separate M.2/add-in wireless adapter?
• If you have access to another Windows system, does the same installer exhibit the same issue?
• Are you using any third-party antivirus or endpoint security software? If so, does the behavior persist after temporarily disabling it?
• After the installer exits, were you able to verify whether setup.xml exists in the temporary extraction folder, or is the file missing entirely?

The answers to these questions will help me determine whether the behavior is isolated to a particular environment or if additional investigation into the installer package is required.

I look forward to your response. If you have any additional observations or findings, please feel free to share them, as they will help with the investigation.

Best regards,

LohithG.

Intel Customer Support Technician

[bubsi]

Hi @LohithG ,

Thank you for your quick response. I believe you're correct that this is actually a machine, or environment, specific problem. I tried the installer on multiple other machines and could not replicate the results. The only meaningful difference is that the problematic machine has had other versions of the driver installed in the past (both older and newer) and the other machines where clean.

I think the question is now, where does the GUID in `_startupDir` get set from? Is it a rogue registry key? Why is it not using the perfectly valid new directory the installer creates on each run?

[bubsi · Accepted solution]

I've solved it, it was a reg key. For anyone hitting the same issue, here's what was actually going on.

The installer was crashing in ParseInstallDataConfigurationFiles() trying to read setup.xml from a hardcoded temp path that didn't exist. What looked like a build-time packaging defect (the _startupDir GUID being identical across every run regardless of where the SFX actually extracted to) turned out to be Burn reading stale registration data from a previous install attempt.

Specifically, the registry key:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{CC58D3F6-A834-4132-801D-9807FE9BB8F3}\variables
had been written during an earlier run and contained:
WixBundleOriginalSource REG_SZ C:\WINDOWS\Temp\{FAE1DE06-3D6D-4179-91BA-9220E6B5864B}\WirelessSetup.exe
WixBundleOriginalSourceFolder REG_SZ C:\WINDOWS\Temp\{FAE1DE06-3D6D-4179-91BA-9220E6B5864B}\

Burn reads WixBundleOriginalSourceFolder from its persisted bundle registration on subsequent runs and uses it as _startupDir when parsing bundle settings. Since the temp folder it referenced was long gone, setup.xml was never findable regardless of how many times the installer was re-run or re-downloaded, the path it was looking at never corresponded to the current session's extraction directory.

The GUID {CC58D3F6...} matches WixBundleProviderKey logged in the Burn output, which is how I tracked down which key to look at.

Deleting the entire key:
`reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{CC58D3F6-A834-4132-801D-9807FE9BB8F3}" /f` cleared the stale registration, and the next run resolved _startupDir correctly from the actual extraction path and completed successfully.

The reason this state existed in the first place was that I'd previously accidentally installed the wrong driver package (24.40.0.4, intended for a newer chipsets) which shares the same WixBundleProviderKey as the 24.20.2.1 package. When I then tried to install 24.20.2.1, Burn picked up the existing registration from the 24.40.0.4 install, including its original source folder, which pointed at a temp path from whenever 24.40.0.4 had been installed, now deleted. Every subsequent attempt kept re-reading from that same stale key rather than writing a fresh one, since the bundle registration already existed.

So the root trigger was installing 24.40.0.4 first, not anything inherently broken about the 24.20.2.1 package itself. Worth knowing for anyone like me blissfully unaware AX200 support has stopped (the newer installers don't tell you this, they just report they're successfully installed).

Thanks again @LohithG for nudging me to look again.

[Tharun_Intel]

Hello bubsi,

Thank you for getting back to us and for taking the time to share the update!

We're really glad to hear that you were able to resolve the issue on your own — that's great news! The information you've shared will be genuinely helpful to other customers who may run into a similar situation, so we truly appreciate you sharing it with us.

Since your issue has been resolved, we'll be closing this support thread, and it will no longer be actively monitored. If you ever need assistance in the future, please don't hesitate to open a new support thread — we're always here to help!

Thank you again, and we wish you a wonderful experience ahead.

Tharun

Intel Customer Support Technician