6 ms·

When installing the update, some users are finding themselves faced with an 0x80070643 error, a generic failure message. Unfortunately, according to Microsoft,

When installing the update, some users are finding themselves faced with an 0x80070643 error, a generic failure message. Unfortunately, according to Microsoft, "because of an error in the error code handling routine," this might not be the correct error. Error in the error code code is giving the wrong error code for the error. I'm curious how often the error code code needs touching that there is an error in there that hasn't been patched long ago. I would imagine it would be a set and forget kind of thing. Unless this error in the error code code has been there for a long time but unnoticed. In which case there might be a errors in the QA of the error code code.

hulitu 3y ago
> "because of an error in the error code handling routine," WinErr:013 Unexpected error - Huh ? This may be the famous "/* NOTREACHED*/".
drsopp 3y ago
Maybe it was caused by a bug in the debugger.
berkes 3y ago
This is why I am extra vigilant, pendantic and strict when writing or reviewing code that handles exception and error paths. More than happy-path code, I want this to be simple, rediculously easy and very loosely coupled. No inheritance, no abstractions, very shallow dependency trees and so on. Just once too often did a bug in exception handling cause a system to go down - It is often not or hardly covered in tests (Its exceptional after all) and very unpredictable: more than elsewhere do exceptions have the tendency to arise where you never expected them (it's in the definition, really).
- JeffSnazz 3y ago
  This attitude seems a little silly to me—being "extra vigilant, pedantic and strict" about happy-path code would necessarily imply the same about "exception and error paths". Generally speaking, bugs mostly appear in a binary fashion and not in varying degrees—ie your code either reflect expected behavior or doesn't.
  - reactordev 3y ago
    You'd be surprised at how many await's it takes to produce a try/catch. The attitude of being extra vigilant, pedantic, and strict around exception and error paths forces the happy path to be as well defined as it possibly can be given the requirements. It's defensive programming. Assume everything will break in ways you don't know about when writing it. Especially true for async/await code. I don't find it silly. It's like a seasoned sarge telling you not to pull the pin on that baseball object you have in your hand.
    - JeffSnazz 3y ago
      > It's defensive programming. This would necessarily presume applying the same attitude towards the happy path—you're describing something short of that. Or to put it a different way: defensive programming necessarily implies a skepticism that you even are sure what the happy/error paths are!
      - reactordev 3y ago
        Oh you definitely apply the same attitude to happy path at the end after scrutinizing the exception/error path options.
        JeffSnazz 3y ago
        > This is why I am extra vigilant, pendantic and strict when writing or reviewing code that handles exception and error paths. I realize that this is a different person from you, but that's the attitude I am replying to.
        hnrhn 3y ago
        Perhaps the implication is not "extra vigilant ... [compared to my level of vigilance on the happy path]", but rather "extra vigilant ... [compared to other people I work or have worked with]" The latter is how I read it, because I have definitely worked on teams where the happy path was heavily scrutinised, but error handling was treated as an afterthought, and rarely inspected too closely, leading to anything from error strings copied from another part of the application with names not updated to match the new location to throwing XException but only handling YException, so the XException bubbles up to a much less useful handler.
- wrs 3y ago
  Exceptions are by definition where some “unknown unknowns” are going to show up, so yes, it’s good to have simple code with as few assumptions as possible. At the extreme, you get Erlang-style supervision or “crash-first programming” where at the first sign of trouble you just immediately throw away all ephemeral state and start over.
  - wayfinder 3y ago
    A good reliable system pretty much has error handling every step of the way, down to crash-first programming at the very end. It’s more possible to recover from errors higher in the system but you can’t predict every problem so you need layers of error handling at increasingly lower levels with different recovery expectations.
- wayfinder 3y ago
  Same. I shut down a ticket last week that would create an “final” error handling path that happened to re-invoke half the code paths that could error.
maximus-decimus 3y ago
This is how I imagine the error code looks. How else can you even return the wrong error? ```c# public class FooError { public Message(){ //TODO: I copy pasted this from somewhere else. I still need to update to a meaningful message return "this is a BarError" } } ```
- arthur_sav 3y ago
  "Oops, something went wrong"
- bArray 3y ago
  My guess is that part of the error handling is appending to the logs. Maybe something like (I can't remember C#, so thinking about Java instead): try{ try{ windows_update_function_that_saves_to_disk(); }catch(DiskSpaceException e){ DiskLogger.log(e.printStackTrace()); // itself tries to save to disk System.err.println(e.printStackTrace()); } }catch(GenericException e){ // something went really badly wrong, generic error }
- reactordev 3y ago
  In C/C++ land, errors are often mapped to const size_t int values. Whether it's an enum or just a list of "codes". In this case, I suspect (like OpenGL) it's just a giant list of codes defined as "extern const uint32_t MY_SUPER_ERROR = 0x0001" and some other part of the code has defined the same value to another error type. Then it's trying to value match and give a human readable value (0x001) but based on the matched value (0x0001 becomes 0x1000) because MY_SUPER_ERROR is 0x1000 in some other part of the code. This happens when people in C/C++ land follow this logic: Lib Guy 1: "I need an error.h to store all my errors to make it easy for me" Lib Gal 2: "I need an error.h to store all of my error values so I can just use type names like a boss" Exe Guru 1: "Which <error.h> is this?" The other option is that an error was thrown inside error handling code which threw an error and was unhandled, throwing an error generically at the base.
  - mook 3y ago
    0x80070643 is ERROR_INSTALL_FAILURE, so yeah basically somebody clobbered the error code in some installation routine. It's in winerror.h, according to https://learn.microsoft.com/en-us/windows/win32/debug/system-error-code-lookup-tool https://learn.microsoft.com/en-us/windows/win32/debug/system...
dghughes 3y ago
Love it. I'm lmao now at such craziness.
pmontra 3y ago
Wait until we'll start seeing error messages like "I Cannot Fulfill This Request It Goes Against OpenAI Use Policy". Then we'll know why QA went bad.
johngossman 3y ago
Dating myself, but I used an OS/2 build that would occasionally report “This Error Message has been deleted”
- dtgriscom 3y ago
  ... but isn't that good?
happycube 3y ago
My favorite was "Something Happened" (smaller text) "Something Happened"
- deleted 3y ago
  [deleted]
the_third_wave 3y ago
"But sir, on what does the Windows operating system rest?" "Why, on the back of an error, of course." "Um... and on what, may I ask, does the error stand?" "Ah, but you're clever, young man. Too clever by half. It's errors, all the way down."
bandyaboot 3y ago
About a year ago I had a bug assigned that ultimately turned out to be caused by an exception in the logging code that only occurred in the specific case of logging an exception being thrown by the exception handling code. This was internal tooling so I made sure to have some fun with the changeling entry—making it as confusing to parse as possible.
fmbb 3y ago
It might not even be human error in QA. This might be a code error in the error code code error finding code.
sexy_seedbox 3y ago
> Error in the error code code is giving the wrong error code for the error Try MS Teams: https://github.com/MicrosoftDocs/msteams-docs/issues/8539#issuecomment-1525507165 https://github.com/MicrosoftDocs/msteams-docs/issues/8539#is...

hulitu 3y ago

> "because of an error in the error code handling routine," WinErr:013 Unexpected error - Huh ? This may be the famous "/* NOTREACHED*/".

drsopp 3y ago

Maybe it was caused by a bug in the debugger.

berkes 3y ago

This is why I am extra vigilant, pendantic and strict when writing or reviewing code that handles exception and error paths. More than happy-path code, I want this to be simple, rediculously easy and very loosely coupled. No inheritance, no abstractions, very shallow dependency trees and so on. Just once too often did a bug in exception handling cause a system to go down - It is often not or hardly covered in tests (Its exceptional after all) and very unpredictable: more than elsewhere do exceptions have the tendency to arise where you never expected them (it's in the definition, really).

JeffSnazz 3y ago
This attitude seems a little silly to me—being "extra vigilant, pedantic and strict" about happy-path code would necessarily imply the same about "exception and error paths". Generally speaking, bugs mostly appear in a binary fashion and not in varying degrees—ie your code either reflect expected behavior or doesn't.
- reactordev 3y ago
  You'd be surprised at how many await's it takes to produce a try/catch. The attitude of being extra vigilant, pedantic, and strict around exception and error paths forces the happy path to be as well defined as it possibly can be given the requirements. It's defensive programming. Assume everything will break in ways you don't know about when writing it. Especially true for async/await code. I don't find it silly. It's like a seasoned sarge telling you not to pull the pin on that baseball object you have in your hand.
  - JeffSnazz 3y ago
    > It's defensive programming. This would necessarily presume applying the same attitude towards the happy path—you're describing something short of that. Or to put it a different way: defensive programming necessarily implies a skepticism that you even are sure what the happy/error paths are!
    - reactordev 3y ago
      Oh you definitely apply the same attitude to happy path at the end after scrutinizing the exception/error path options.
      - JeffSnazz 3y ago
        > This is why I am extra vigilant, pendantic and strict when writing or reviewing code that handles exception and error paths. I realize that this is a different person from you, but that's the attitude I am replying to.
        hnrhn 3y ago
        Perhaps the implication is not "extra vigilant ... [compared to my level of vigilance on the happy path]", but rather "extra vigilant ... [compared to other people I work or have worked with]" The latter is how I read it, because I have definitely worked on teams where the happy path was heavily scrutinised, but error handling was treated as an afterthought, and rarely inspected too closely, leading to anything from error strings copied from another part of the application with names not updated to match the new location to throwing XException but only handling YException, so the XException bubbles up to a much less useful handler.
wrs 3y ago
Exceptions are by definition where some “unknown unknowns” are going to show up, so yes, it’s good to have simple code with as few assumptions as possible. At the extreme, you get Erlang-style supervision or “crash-first programming” where at the first sign of trouble you just immediately throw away all ephemeral state and start over.
- wayfinder 3y ago
  A good reliable system pretty much has error handling every step of the way, down to crash-first programming at the very end. It’s more possible to recover from errors higher in the system but you can’t predict every problem so you need layers of error handling at increasingly lower levels with different recovery expectations.
wayfinder 3y ago
Same. I shut down a ticket last week that would create an “final” error handling path that happened to re-invoke half the code paths that could error.

maximus-decimus 3y ago

This is how I imagine the error code looks. How else can you even return the wrong error? ```c# public class FooError { public Message(){ //TODO: I copy pasted this from somewhere else. I still need to update to a meaningful message return "this is a BarError" } } ```

arthur_sav 3y ago
"Oops, something went wrong"
bArray 3y ago
My guess is that part of the error handling is appending to the logs. Maybe something like (I can't remember C#, so thinking about Java instead): try{ try{ windows_update_function_that_saves_to_disk(); }catch(DiskSpaceException e){ DiskLogger.log(e.printStackTrace()); // itself tries to save to disk System.err.println(e.printStackTrace()); } }catch(GenericException e){ // something went really badly wrong, generic error }
reactordev 3y ago
In C/C++ land, errors are often mapped to const size_t int values. Whether it's an enum or just a list of "codes". In this case, I suspect (like OpenGL) it's just a giant list of codes defined as "extern const uint32_t MY_SUPER_ERROR = 0x0001" and some other part of the code has defined the same value to another error type. Then it's trying to value match and give a human readable value (0x001) but based on the matched value (0x0001 becomes 0x1000) because MY_SUPER_ERROR is 0x1000 in some other part of the code. This happens when people in C/C++ land follow this logic: Lib Guy 1: "I need an error.h to store all my errors to make it easy for me" Lib Gal 2: "I need an error.h to store all of my error values so I can just use type names like a boss" Exe Guru 1: "Which <error.h> is this?" The other option is that an error was thrown inside error handling code which threw an error and was unhandled, throwing an error generically at the base.
- mook 3y ago
  0x80070643 is ERROR_INSTALL_FAILURE, so yeah basically somebody clobbered the error code in some installation routine. It's in winerror.h, according to https://learn.microsoft.com/en-us/windows/win32/debug/system-error-code-lookup-tool https://learn.microsoft.com/en-us/windows/win32/debug/system...

dghughes 3y ago

Love it. I'm lmao now at such craziness.

pmontra 3y ago

Wait until we'll start seeing error messages like "I Cannot Fulfill This Request It Goes Against OpenAI Use Policy". Then we'll know why QA went bad.

johngossman 3y ago

Dating myself, but I used an OS/2 build that would occasionally report “This Error Message has been deleted”

dtgriscom 3y ago
... but isn't that good?

happycube 3y ago

My favorite was "Something Happened" (smaller text) "Something Happened"

deleted 3y ago
[deleted]

the_third_wave 3y ago

"But sir, on what does the Windows operating system rest?" "Why, on the back of an error, of course." "Um... and on what, may I ask, does the error stand?" "Ah, but you're clever, young man. Too clever by half. It's errors, all the way down."

bandyaboot 3y ago

About a year ago I had a bug assigned that ultimately turned out to be caused by an exception in the logging code that only occurred in the specific case of logging an exception being thrown by the exception handling code. This was internal tooling so I made sure to have some fun with the changeling entry—making it as confusing to parse as possible.

fmbb 3y ago

It might not even be human error in QA. This might be a code error in the error code code error finding code.

sexy_seedbox 3y ago

> Error in the error code code is giving the wrong error code for the error Try MS Teams: https://github.com/MicrosoftDocs/msteams-docs/issues/8539#issuecomment-1525507165 https://github.com/MicrosoftDocs/msteams-docs/issues/8539#is...