There is a non-trivial chance that the crash is caused by the project code, and not by the internal workings of Visual Studio.
As suggested by m_david in the OP related question, the first step is to add the following code at the beginning of Seed() ¹:
if (System.Diagnostics.Debugger.IsAttached == false) { System.Diagnostics.Debugger.Launch(); }
This will result in a prompt² that asks whether to start the debugger in a new instance of Visual Studio or another one at the moment.
After that, the debugger output will be written to the Debug output of this VS instance, and unhandled exceptions will be processed as breakpoints - with highlighting the line of code violation, details of the exception and all this.
In my case, the crash was caused by the recursive operation set() in a member of one of the objects, which led to a StackOverflowException .
¹ Or your constructor for a subclass of DbMigrationsConfiguration , if the failure occurs earlier. Or perhaps elsewhere.
² Remember to comment on this code when you do not need it.