This is something I kind of like about the Microsoft APIs. Their error codes aren't always perfect, but at least they give you some indication where things went wrong.

From MSDN:

> An HRESULT value consists of the following fields:

> A 1-bit code indicating severity, where zero represents success and 1 represents failure.

> A 4-bit reserved value.

> An 11-bit code indicating responsibility for the error or warning, also known as a facility code.

> A 16-bit code describing the error or warning.

The "reserved value" also includes a bit for non-Microsoft code (which driver vendors and other API producers can use, although I don't know how often they do)

There's a list of common "facilities" here: https://learn.microsoft.com/en-us/openspecs/windows_protocol...

As a regular user, you will see errors like 0x8ACEF00D, but if you decode them, you can get a sense of what part of the system ran into the failure. Compared to the "negative value indicates failure, look up the possible failures and what they mean for every function" approach many other APIs follow, that's a welcome change.

Of course there's no guarantee that Microsoft doesn't return some kind of meaningless internal E_SOMETHING_WENT_WRONG value, but for a lot of APIs, there are details hidden in plain sight. It won't tell you your ISP's fiber has snapped, but it'll tell you if the problem is within the driver, a security limitation, an HTTP error, or a generic network stack issue.

HRESULTs are well intentioned. They originated in OS/2; but Microsoft always seemed to use them half-heartedly.

Users should not be seeing "08CAE5D012" error messages. They should be seeing "Connection refused. (08CAE5D012)" messages, or "No connection. (83255321)" messages instead.

There's is a non-trivial protocol for translating HRESULTs into error text; but it is often not supported properly by Windows applications, or Windows OS components.

e.g. DirectX which returns generic 0x8004005 E_FAIL errors. Or the WinSock APIs, which return HRESULTs, but don't provide text message translations; or Microsoft Installers that report raw HRESULTs with no attempt to capture the associated error text.

With discipline, the entire system could have worked. But there wasn't, and it didn't.

I've been suffering that TODAY.

"Connection Refused No Further Information"

Well thanks pal.

I was getting the equivalent from my Roku box the other day, something like "no connection to the internet". Sigh.

Add a parallel step there, somewhere, for DNS. My raspberry pi runs pihole but the hardware is failing somehow so the server crashes so DNS lookups fail. All existing connections are fine, direct IPs are fine, locally cached results are fine, but new lookups fail. It is somewhat fun to watch it happen.

Windows has a tool to diagnose network problems, and it's usually completely useless but I think DNS not working is something it does identify.

Windows has a button to diagnose failed internet connections, but it has never reported anything other that the internet connection doesn't work. It's pathetic.

Keep going... ...

Try: ISP router intercepts DNS and drops the record because your company put private addresses on public DNS and the router has rebind protection.

You're making the assumption that it is all caused by hardware or software malfunction in the sending of an IP packet to the target server. However the first step is usually a DNS lookup. A list would look more like this:

1. DNS lookup fails because the DNS server address configured at the computer OR router is incorrect 2. DNS lookup fails because the configured DNS server is down 3. DNS lookup fails because some firewall is blocking requests to it 4. DNS lookup fails because the network was congested 5. DNS lookup fails because of interference in the Wifi channel from other Wifi networks 6. Etc. Etc.

So indeed, usually when the network is down you only get "DNS lookup failed". Because the actual reason may be complicated. Of course, usually it is due to your computer not being connected to a router so usually the error message hints at that (in layperson's terms: not connected to the internet). So that's why browsers hint at it being your connection, i.e. ethernet or wifi.

But there is no way to make sure. All we know is that DNS seems to fail. The reason it fails could be any part of its configuration which is spread out across physical systems and software components.

The best we can say: probably your ethernet/wifi connection. If we trust that none of the other components are failing then it must be your connection that is failing.

It's like trying to find out what's wrong in 1+2+32+4=10. Sure, it seems like the 32 should be a 3. But maybe the 10 should be a 39. There is no way to tell anymore. All we can do is make an educated guess.

It's similar to when you try to print something, and nothing happens.

1. is the printer turned on?

2. is the printer out of paper or ink?

3. does the cable have a loose connection?

4. is it the wrong printer driver?

5. do you need to reboot windows?

6. do you need to power cycle the printer?

No help anywhere. You just try things one by one, sacrifice a small animal, and then maybe the printer gods will smile on you and the printer will print.