[fluoridation]

It's because the default program structure in C and C++ makes functions blocking, with the caller assuming that if the callee returned it completed. Jamming a non-blocking program structure smack in the middle of a blocking system is never pretty, and most people prefer not to deal with the additional complexity. For the same reason, even though Windows has overlapped IO and other asynchronous IO mechanisms, most people prefer to use the synchronous functions.

[iforgotpassword]

For disk IO you usually get away with it, especially now with SSDs. For networking you don't even have to use overlapped IO, sockets can be used with window messages, winhttp can be used async, etc. I think "it's more involved" is a really shitty excuse, especially if we're talking about a Microsoft product, not some obscure shareware software a guy is developing in his shed in the middle of nowhere.

[fluoridation]

I'm not excusing this particular case, I'm just explaining the perspective of most developers regarding synchronous versus asynchronous operations. In this particular case there's no reason to do it synchronously, since multiple processes are involved anyway. The crash handler should definitely not be waiting on a network operation to let the process terminate (that's not even getting into whether crash dumps should be getting uploaded by default to begin with), and the fact that this is a central part of the operating system's UI is even more egregious.