3 ms·

The code which outputs the error message is probably getting it from GetLastError() or similar (the Windows equivalent to POSIX's errno). But meanwhile, some er

by cesarb 3y ago

The code which outputs the error message is probably getting it from GetLastError() or similar (the Windows equivalent to POSIX's errno). But meanwhile, some error handling code has called some library functions (probably to restore the system to a sane state), and one of these library functions accidentally overwrote the global per-thread "last error" variable. That is, the error in the error handling routine would simply be a lack of doing a "saved = GetLastError()" at the start and then a "SetLastError(saved)" at the end. This kind of mistake is very common when dealing with GetLastError() or errno, since most library functions you might call while handling an error do not overwrite these values... until something in one of them fails (sometimes even a non-fatal error which is handled internally by them) and overwrites that per-thread variable.

tonyedgecombe 3y ago
I remember one bit of customer code where I needed to pass a BSTR string into a function. I constructed it using CComBSTR without considering that the destructor calls SetLastError. I could see the call failing but the only information I got back was ERROR_SUCCESS.
mike_hearn 3y ago
Yeah that's almost certainly the issue. Last year I had to debug a Windows issue that caused the following: we get back a struct from the Windows API that contains an HRESULT style error code, and also a string error message in case of error. Printing the string revealed that it started with the error code in hex, so we just logged the string. As part of a workaround for another Windows bug we had to check the error code for a specific value and do something different. Eventually we got a report from a Windows machine in the wild where the code seemed to be doing something impossible: the log indicated the error code we looked for was being returned, yet, the code didn't take the conditional path that checked for it. After a lot of head scratching we realised there was only one possibility: the error code printed in the error message and the error code returned in the structure didn't actually match. Sure enough that turned out to be the case. Somehow Microsoft had generated the textual version of the error successfully, and then the machine readable error code had been replaced with something else before it was returned. The fix was to compare against both the HRESULT and the stringified form. Naturally, this error only occurred on some Windows installs and not others for no obvious reason. The core OS seems to have tech debt issues so severe that it's basically impossible to verify even for app developers - you can do everything right, test it all carefully, and your code will still blow up in the wild in an undocumented fashion because no two Windows installs are quite alike, even (perplexingly) for fresh out-of-the-box installs that appear to be the same version. At this point even Linux is more consistent than Windows 10 is. I can't imagine how painful it must be to work on Windows deployments at Microsoft. The install base has become so inconsistent that they're pretty much guaranteed to trash people's systems with every change they make by now.
- deleted 3y ago
  [deleted]

by cesarb 3y ago

tonyedgecombe 3y ago

I remember one bit of customer code where I needed to pass a BSTR string into a function. I constructed it using CComBSTR without considering that the destructor calls SetLastError. I could see the call failing but the only information I got back was ERROR_SUCCESS.

mike_hearn 3y ago

Yeah that's almost certainly the issue. Last year I had to debug a Windows issue that caused the following: we get back a struct from the Windows API that contains an HRESULT style error code, and also a string error message in case of error. Printing the string revealed that it started with the error code in hex, so we just logged the string. As part of a workaround for another Windows bug we had to check the error code for a specific value and do something different. Eventually we got a report from a Windows machine in the wild where the code seemed to be doing something impossible: the log indicated the error code we looked for was being returned, yet, the code didn't take the conditional path that checked for it. After a lot of head scratching we realised there was only one possibility: the error code printed in the error message and the error code returned in the structure didn't actually match. Sure enough that turned out to be the case. Somehow Microsoft had generated the textual version of the error successfully, and then the machine readable error code had been replaced with something else before it was returned. The fix was to compare against both the HRESULT and the stringified form. Naturally, this error only occurred on some Windows installs and not others for no obvious reason. The core OS seems to have tech debt issues so severe that it's basically impossible to verify even for app developers - you can do everything right, test it all carefully, and your code will still blow up in the wild in an undocumented fashion because no two Windows installs are quite alike, even (perplexingly) for fresh out-of-the-box installs that appear to be the same version. At this point even Linux is more consistent than Windows 10 is. I can't imagine how painful it must be to work on Windows deployments at Microsoft. The install base has become so inconsistent that they're pretty much guaranteed to trash people's systems with every change they make by now.

deleted 3y ago
[deleted]