Windows 10 says I have no internet connection, but I have.

OK, email sent.

Here's a more complete one that I use:

((dns.qry.name contains "www.msftconnecttest" || dns.qry.name contains "msftncsi") && dns.qry.type == 0x1)

|| http.host contains "connecttest"

|| ip.src == 13.107.4.52

|| http.host contains "msftncsi"

|| ((ip.dst == 13.107.4.52) && (tcp.flags.syn == 1))

If you are absolutely not seeing any DNS or HTTP coming from PID matching nlasvc then your active probing is not enabled.  I know despite a lot of crazy history in this thread I can't even get my hands around I think you had registry values correct....but maybe not.

Hi Tom

I ran a wireshark capture yesterday for 8+ hours, captured several GBs with a total of 0 packets matching this filter. When i initially started the capture the windows network status indicator showed "internet access", but a bit later windows claimed no internet and remained that way for the rest of the day. I then ran "nslookup dns.msftncsi.com", and also opened **"**www.msftconnecttest.com" in my browser, both of those showed up in Wireshark immediately (matching the filter).

This issue has been going since about April last year, I had the same issue on 2 different machines i use regularly and then in November/December it started happening on a 3rd machine as well. At home and the office. Same issue on Wi-Fi and Ethernet, though Wi-Fi is more annoying because windows likes to disconnect after it thinks there is "no internet" (and no it's not a driver issue).

Active Probing is on and I have checked that numerous times, turning it off doesn't help. That other policy key to disable active polling doesn't exist so does not apply either.

A lot of apps blindly use the status windows reports which makes them all unusable. It also affected office preventing opening files from onedrive, and outlook cannot connect to exchange (though sometimes it still works, maybe if it's started before windows "goes offline").

Thankfully web browsers are smart enough to ignore windows in this regard and have been working fine all along.

I have not yet seen this issue in a windows 10 virtual machine though if that helps narrow things down.

Is there anything else that can be diagnosed? Does the NCSI thing write to any kind of log file? What other information can I give that will help MS actually do something about this!

I believe you when you say you've verified the regkeys.

There have been may cases I've worked on in which no probe packets ever made it to the wire because of intereception in the network stack.

Ex: Third party product that installs a DNS intercept filter on the loopback and pipes it back into the stack again will not work because without Global DNS GPO enabled this violates TCP<-->NCSI broker that the destination network interface chosen needs to be the one TCP receives.  Loopback messes that up.

Third party products I've seen do this include Cisco Umbrella, Z-scaler, F5 Big IP agent, McAfee something something, etc.

(Global DNS fixes this)

Another Ex:  NCSI uses WinhttpAutoProxySvc to know if there's a proxy and to send the probe that way.  But if there's a problem with the proxy configuration in the environment and autoproxy can't get the info accurately, neither can NCSI, and this sometimes results in autoproxy returning proxy autodetect failure back to NCSI..failing the probe.   Manual proxy gets around this, but the right way to fix is to fix autodiscovery.

These may not apply to you.  But there are other possibilities.   Third party products installing filters in the network stack that intercept and drop certain packets.  

Regarding tracing, the best we have for external consumption at this point are the NCSI diagnostic/operational events.   They aren't all that verbose.  

I could also recommend elevated prompt:

netsh trace start wireless_dbg, bounce adapter, netsh trace stop, netsh trace convert <resulting etl file>.  In Win10 20H1 (2004) builds this has gotten a little better verbiage but still not much compared to our internal tracing that we use with customers that open cases with us.

If nobody saw me put this elsewhere...

HKLM\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet\MinimumInternetHopCount

DWORD 3

and reboot

helps the passive probe. (note that active probe isn't just firing on periodic basis...it's triggered by mostly network changes.  Passive probe is in play by watching received packets and learning from those in between active probes).

Default of that regval is 8, which IMHO is way too big.

I hope this helps somewhat.  

Almost every NCSI case I've ever gotten I've root caused...but I can't do that here because it requires me getiing into internal tracing 1:1 with everyone...and that's unfortunately just not feasible.

I'm here for top-of-head quick-fire answers I can give, and any value I can add.

And of course, if I come across a bug fix that does get published on occasion I'm more than happy to light that up here when that happens.