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.