Jekyll2023-10-19T16:02:42+00:00http://n7.pm/feed.xmlRamblings about personal projectsfox80912023-10-19T00:00:00+00:002023-10-19T00:00:00+00:00http://n7.pm/qca6174<p>Laptops with soldered Wi-Fi chipsets can be a huge pain, as when the Wi-Fi chipset dies, it renders the machine near unusable. This was the case for a system owned by a friend of mine, leading to consistent hangs during the boot process under Windows and kernel hangs under Linux. They managed to solve the issue for Linux by blacklisting the kernel driver (<code class="language-plaintext highlighter-rouge">ath10k_pci</code> in the case of the Qualcomm Atheros QCA6174 in their system), however, they were unable to solve the issue under Windows. Given that I have decent experience with Windows internals, and have previously dealt with device blacklisting as used for Hackintosh setups (macOS running on non-Apple hardware), I offered to help.</p> <p><img src="/images/posts/qca6174/laptop_hang.jpg" alt="Laptop failing to boot" /></p> <p>My first thought was to block driver installation for the affected device with the <a href="https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-deviceinstallation#preventinstallationofmatchingdeviceids">PreventInstallationOfMatchingDeviceIDs</a> Group Policy. This allowed Windows to boot, however, it immediately threw a MACHINE_CHECK_EXCEPTION BSOD when connected to the internet due to Windows attempting to probe the device during Windows Update. My next idea was to blacklist Windows driver updates via <a href="https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-admx-devicesetup#driversearchplaces_searchorderconfiguration">DriverSearchPlaces_SearchOrderConfiguration</a> (Or more accurately in this case, by setting the backing registry key <code class="language-plaintext highlighter-rouge">HKLM\SOFTWARE\Policies\Microsoft\Windows\DriverSearching\SearchOrderConfig</code> to 0). While both of these seemed to help, neither entirely prevented Windows Update from attempting to install drivers for the Wi-Fi card. To deal with this, an additional Windows Update for Business Group Policy, <a href="https://learn.microsoft.com/en-us/windows/deployment/update/waas-configure-wufb#exclude-drivers-from-quality-updates">ExcludeWUDriversInQualityUpdate</a>, needed to be enabled. Following this, the laptop happily booted into Windows, even when connected to the internet.</p> <p><img src="/images/posts/qca6174/laptop_booted.jpg" alt="Laptop booted into Windows" /></p> <p>All in all, this was a fun deep-dive into Windows policy options, and a great exercise in working around hardware issues in software. If you happen to face similar issues, the registry file to enable these tweaks is provided <a href="/files/DisableWifi.reg">here</a>. Do note however that this is not entirely plug and play, as <code class="language-plaintext highlighter-rouge">PCI\\VEN_168C&amp;DEV_003E</code> must be replaced with the hardware ID for your Wi-Fi chipset.</p> <p>If you have any questions or comments regarding this endeavour, please feel free to reach out via the email provided at the bottom of the page.</p>fox8091

Laptops with dead Wi-Fi chipsets are near useless. Windows hangs during boot, and Linux requires relatively obscure workarounds. Let's fix that.