It probably hasn't been addressed because user experience is depressingly low priority for microsoft...
And i wonder if you could actually convince them that letting the start menu hang while a report gets uploaded is actually a bug, rather than a valued feature.
I'd say the reality is even more ironic - they collect so much data and reports, pretending this is to help to improve the user experience, but in the end it makes the experience so much worse.
It still irks me to no end when a Microsoft product asks me to rate my experience. Teams is constantly badgering me to rate the call quality. Is there a threshold percentage of users indicating good/bad that would lead to any change?
I've been giving it one star consistently since it was introduced. It's still shit. I'd love to know what happens to that feedback.
I once had a teams bug wherein I couldn't join a call whenever Google Chrome updated as it would fail the version number check and give me an error telling me I needed to use Google Chrome. I took a screenshot of this patent insanity and sent it to Microsoft support. A bit of discussion later and the response was something like "we know that Teams is continually evolving software and is not perfect at this time".
Normally the upload is in the background but here clearly the crashed process was considered so vital that the UI had to wait for it, which in turn meant it had to wait for the last instance to quit (after it was dumped). So the lesson here I think isn't that there should never be synchronous waiting for crash dump uploads the problem as I see it is
1) The fact that a process that important could crash.
2) That the upload was synchronous AND silent. Pick one. Just show me a tray message saying "Process blah crashed and we are uploading the crash dump click here to configure your preferences for automatic crash dump uploads".
I mean that RuntimeBroker.exe was considered so important that the UI process (Explorer.exe?) couldn't proceed to show the start menu while it wasn't running, and instead had to wait for it to run.
That RuntimeBroker couldn't restart until the last instance was dumped is what's true for all processes. But that doesn't explain why the UI block waiting for it and not show the start menu.
RuntimeBroker may be required to show the complete/correct start menu because it relates to app permissions for store apps and similar, but Microsoft (again) likely overestimated the importance of their app store.
And i wonder if you could actually convince them that letting the start menu hang while a report gets uploaded is actually a bug, rather than a valued feature.