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.
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".