No WiFi auto-connect on XPS 13 9360 / Windows 10 Insider 14986 - General Hardware - Laptop - Dell Community

No WiFi auto-connect on XPS 13 9360 / Windows 10 Insider 14986


Laptop computer Forums (Audio, General Hardware, Video)

No WiFi auto-connect on XPS 13 9360 / Windows 10 Insider 14986

This question is not answered

My new XPS 13 9360 will not auto-connect to any WiFi access points.

I am fully up-to-date on BIOS and all drivers from Dell; currently I see this on Windows 10 Build 14986 (which is the latest slow ring insider build) - but I _may_ have seen this on the latest Windows 10 stable edition as well.

I have tried recreating access points, reinstalling drivers, all to no avail.

The access points in question auto-connect perfectly with another laptop. Generally, once (manually) connected, WiFi works very well.

I'd be grateful for any suggestions on how to make auto-connect work reliably.

All Replies
  • Hi, just solved removing the option "Killer bandwith option" (a real killer lol) from wifi-property -> network. I was looking for setting up a static ip when i saw this option enabled. Disabled and everything went good.

    My pc is a new xps 9360 with w10 x64 pro ver 1607-14393.693 and Killer Wireless-n/a/ac 1535 Wireless Network Adapter

    Hope that can help you

  • "Killer bandwidth option" = Killer traffic shaper.

    From my point of view, it is a very good idea to first remove all existing Killer and Qualcomm software from the system and then reinstall the freshest barebones drivers (and only the drivers!) from

  • I can't even find where to turn this option (Killer bandwidth option) off.

    Shoffmeister, did you mean there was a different between installing Killer Drivers Installation - 64bit ("Driver only installation") and Killer INF Package ("Driver INF Package for device manager installation")?

    I installed the first (as it said driver only), but I'm starting to get a feeling you meant the latter as I still have some Killer program installed under "Programs and Features"...

    Thanks for helping.

  • The Killer traffic shaper appears to be composed of two elements - one is what appears to be a plugin into the Killer Network Manager ( ), and one  as network filter driver on each(?) network adapter ( ).

    Basically, by following the steps given above, you will unconditionally remove all Killer software from your computer and then install a version which does not physically include any of these bits and bytes.

    The network properties dialog is also the best starting point for figuring out which additional software might add to your network usability. As a rule of thumb, try to absolutely minimize the set of items listed there which do not originate from Microsoft directly (and leave all Microsoft items at their defaults).

    Example: Oracle Virtualbox installs its own filter driver to implement network bridging. Some VPN software will do similar things. That in itself is not bad per se - but if any one of these components is not implemented correctly, then it can have a negative impact on aggregate behaviour. Similarly, if the raw Killer (Qualcomm) network drivers are not implemented 100% correctly, and have only been certified within the Microsoft stack (which would be fairly normal), then any additional component might expose problems in the Qualcomm driver.

    So the general troubleshooting steps are: Pare the whole thing down to the barest essentials (i.e. the moral equivalent of a clean Windows 10 installation from Microsoft installation media - the Dell factory image is already pre-blessed with the Qualcomm / Killer bandwidth control option, if I recall correctly), then introduce whatever you _need_ (and only that) into the mix. For myself, I have the "bare Microsoft stack" and VMware Workstation (which inserts the VMware Bridge Protocol filter driver into the network stack) - and that works.

    If you do not get any autoconnect working even in a clean installation against one specific access point, try to find other, more expensive / more enterprise-class / better maintained access points to see how these behave. Consumer WiFi devices sometimes seem to have awkward budget constraints placed on their correct behaviour.

  • (Apologies for the links in the text above - the forum software is a bit lacking)

  • @shoffmeister - just to make things really clear:

    You installed the driver using the "Killer INF Package" on this page (and not the "Killer Drivers Installation - 64 bit") and also changed "CsEnabled" to '0' in the registry path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power ?

    Are these the two necessary steps that fixed the issue for you?


  • Between WiFi auto-connect working and not-working, I applied the changes listed below. I did not dig into whether any of these steps addressed any root cause, or whether all of this is coincidental. My WiFi has been auto-connecting perfectly reliably ever since, despite me switching a couple of times each day.

    Generally, I suspect that the Killer bandwidth manager deserves most of the blame (it is made to disappear with the uninstall and does not return with the pure driver installation), possibly combined with Virtualbox (which is also rather invasive on the network stack)


    - Network Stack Management per se

    1.) uninstall all Killer software from the system via Windows 10 "Control Panel" -> "Programs and Features"

    2.) install the drivers, not the INF files, from - i.e.

    3.) uninstall Oracle VirtualBox

    - Power Management (because I want, want, want)

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power -> CsEnabled: 0

  • There is another insider build available.  You might check the known PC problems to see if it will help.


    XPS 2720, Inspiron 17 7779, Inspiron 15 7567, XPS 13 9365, Inspiron 1545, TB16 Dock

  • For what it's worth - I quite happy with the current state of my XPS 13 9360, and am looking forward to the next slow ring update (for other reasons)

    Frankly, I doubt that Windows insider builds contribute at all to this scenario, wherever correctly written non-Microsoft software is concerned. This is the reason that I trimmed down the exposure to Qualcomm to just the driver, got rid of Virtualbox (which I distrust - VMware I trust). I do not mean to imply here that Microsoft is free from producing defective software components, by the way.

  • @shoffmeister - so since I changed CsEnabled to 0 - things have actually gotten worse. Now when I'm back from sleep, the WiFi adapter says that there are no available networks for about 20-25 seconds before it reaches the stage where it was before - showing them but not connecting until manually asking it to...

  • CsEnabled = 0 effectively results in the hardware initializing from a much "colder" power state ("Connected Standby" is disabled), so it is not surprising that it takes longer for the network _hardware_ to become available later.

    You seem to be having more of a hardware problem - the network _hardware_ (WiFi adapter) should be up and running almost immediately once you see the Windows login prompt.

    Get this fixed by a qualified computer technician. This person should be able to perform better troubleshooting on the root cause (assuming that you did a full system reset, including BIOS, and full driver updates after fresh install)

  • Thanks for your answer.

    I think it's time for a full reset of this computer back to factory defaults since I started getting exceptions when restarting it.

  • Updating that after a complete factory reset - WiFi auto-connects after sleep *most* of the time within 2-4 seconds.I'm on Windows 10 build 14393.969, and the build comes pre-installed with the entire Killer Wireless Suite v1.1.61.1286 (the actual driver is from 8/30/2016).

    If the computer goes from sleep into a deeper state (I'm not sure what exactly it is, but when that happens I had to input my BIOS password again) - the adapter doesn't reconnect just like before...

    @shoffmeister - with the evidence collected with CsEnabled=0 (20-25 seconds until adapter "sees" networks at all) do you believe this is a hardware fault?



  • There is supposed to be a new public out in about two weeks.  Until then, check the thread linked.  The Killer Rep says it is an Updated version of the driver you mention..

    As a note, I am starting to understand the Modern Standby situation but I don't think mine is working correctly since I keep getting Push warnings..


    XPS 2720, Inspiron 17 7779, Inspiron 15 7567, XPS 13 9365, Inspiron 1545, TB16 Dock

  • I can only contribute one data point:

    I have total and utter WiFi reliability (transport / (re)connect) on Windows 10 Insider builds, with the _pure_ drivers from Killer Networking - (Driver Version = in Windows 10 Device Manager).

    I am still with CsEnabled == 0, as I have philosophically challenged with the concept of "connected stand-by" for a laptop.

    On the other hand, I only see two access points, regularly - one Enterprise class WiFi mesh on 5 GHz, one singular home router on 2.4 GHz (with uncrowded neighbourhood), all of which probably have top-of-the-tops WiFi chips (and baseband firmware) on their end.

    Regarding your question on the possibility of a hardware defect, my gut reaction is: highly unlikely.

    My recommendation for systems, and my general goal at large, is to stay with a really large vendor (e.g. Dell), and to cherry-pick the most current driver versions from the (ideally massive-scale) component vendor (e.g. Intel, Qualcomm, Realtek) wherever possible.

    So, for instance, I am running Windows 10 with the Dell BIOS, but with Intel's chipset drivers (really, not Dell's packaging of the Intel chipset drivers), the Intel graphics drivers, the Qualcomm network/Bluetooth drivers, and the Realtek sound drivers.

    All in all I am totally pleased with the way things work at the moment.

    After Windows 10 Creators Update has been released to the masses, I will rebuild the XPS 9360 to get off the Windows Insider track (which at this time has High DPI improvements, exclusively), put all drivers in place, and get rid of Connected Stand-By, again.