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

"Is there no way to get detailed/debug logging out of NCSI?"

Not without our internal symbols, no.  

" I use a custom dns server on localhost"

Enable Global DNS group policy if not already.   This can break the active probe.

Admin templates->Network->Network Connectivity Status Indicator->Specify Global DNS -> Enabled

Regkey tied to this is

HKLM\SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator

UseGlobalDns DWORD 1

Re passive probe:  Doesn't sound like that's affecting you, so ignore.

Re 2004:  I can't speak to bugs.  I don't have trending customer issues for 2004 NCSI as of yet.  Time will tell.

That's all I can come up with at the moment.   I'd love to help you look at a netsh trace but I'm already above and beyond with asssiting other here.  If only there were 25 hours in a day :(

If I free up time in the near future maybe we can work together.

Thanks for the suggestions Tom, I looked into them a bit, but no progress yet. Is there no way to get detailed/debug logging out of NCSI?

There's no fancy network gateway or proxying going on, just a plain routers from the ISP which have always worked just fine.

I'm fairly sure I don't have something installed which is filtering/dropping the dns packets, nslookup works fine. I don't think it's a dns issue. I use a custom dns server on localhost and this has worked fine for years. Looking at the dns server logs i can see that there are active probe dns lookups now and then, maybe once a week on average, it's very irregular. If having a custom dns setup breaks NCSI then why was this never an issue before the 2004 update.

Regarding the MinimumInternetHopCount, I had not heard about that registry key before, so I ran another Wireshark trace while Windows claimed no internet access, and 99% of packets have TTL greater than 8 (filter ip.ttl > 8), so I don't see why decreasing that to 3 is going to make any difference.

The reason it seems to me that this is a bug/regression in NCSI is that this issue began immediately with the Windows 10 2004 update. I held off installing that update on the 3rd machine I use, but eventually Windows decided to update anyway and then suddenly that machine had the same issues as well. Everything else which doesn't rely on the NCSI status still works fine.

Looking at the NCSI event log, lots of entries with the status SuspectDnsProbeFailed and ActiveHttpProbeFailed are logged when there are network adapter status changes. Running "Invoke-WebRequest http://www.msftconnecttest.com/connecttest.txt" in powershell responds in less than 1 second with the expected content "Microsoft Connect Test", so not sure why it thinks the active http probe is also failing.

Occasionally there are PassivePacketHops entries, and then Windows does claim to be connected, at least for a while, even though there are several of the other 2 status entries right after it. Even though there are lots of entries logged, nothing is captured by wireshark (on all interfaces), there are 0 packets matching that filter for NCSI traffic. The requests from powershell and nslookups always show up immediately, but nothing else.

Anything else to check? How can I find out why NCSI is not actually sending anything at all even though it claims to be doing the active checks.

I don't think running that netsh trace will help since that's too late in the pipeline and probably won't give any new insights.

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.