5

Each time I run Update-Database from the package manager console, Visual Studio 2015 is crashing. It happens to be running my migrations Configuration.Seed method at the time. Any idea where I should look to find out what's going on?

Ruchi
  • 1,238
  • 11
  • 32
jlavallet
  • 1,267
  • 1
  • 12
  • 33
  • If this could help : https://social.msdn.microsoft.com/Forums/en-US/29ef381f-f465-463c-b64b-aed07d07ac63/vs2012-package-manager-crashes-on-updatedatabase-using-entity-first-code-migrations-with-seed?forum=adodotnetentityframework – Ruchi Sep 03 '15 at 19:38
  • 2
    capture a dump (http://technet.microsoft.com/en-us/sysinternals/dd996900.aspx, http://msdn.microsoft.com/en-us/library/bb787181%28VS.85%29.aspx) of the crashing VS2015. Open the crash dump in windbg, fix the debug symbols (http://stackoverflow.com/a/30019890/1466046), run **!analyze -v** and post the output. – magicandre1981 Sep 04 '15 at 04:22
  • 1
    I found this post: [link](http://stackoverflow.com/questions/17169020/debug-code-first-entity-framework-migration-codes) and it helped me debug my Seed method which was throwing an unhandled exception. I'll try your suggestion @magicandre1981 to see why that would bring down VS, however. – jlavallet Sep 04 '15 at 12:45
  • 1
    Did you find a solution ? – Moelbeck Dec 11 '15 at 16:15
  • @MothCreek, I never did get back around to trying the solution proposed by magicandre1981. I did place a try catch around my seed method code and found where it was throwing an exception. Once I corrected that the seed method worked just fine. I would have expected to get a stack trace in the output window or package manager window though. – jlavallet Dec 12 '15 at 17:48

1 Answers1

3

There is a non-trivial chance that the crash is caused by project's code and not the inner working of Visual Studio.

As suggested by m_david in a question linked by the OP, the first step is to add following code at the beginning of Seed()¹:

if (System.Diagnostics.Debugger.IsAttached == false)
{
    System.Diagnostics.Debugger.Launch();
}

This will cause a prompt² to appear that will ask whether to launch the debugger in a new instance of Visual Studio or another currently running one.

After that, the debugger's output will be logged to Debug output of that VS instance, and unhandled exceptions will be treated as break points - with highlighting the offending line of code, exception details and all that.

In my case, the crash was caused by a recursive set() operation in a member of one of the entities, which resulted in a StackOverflowException.

¹ Or your DbMigrationsConfiguration subclass's constructor, if the crash happens earlier. Or possibly some other place.

² So remember to comment that code out when you don't need it.

Community
  • 1
  • 1
Dragomok
  • 604
  • 3
  • 11
  • 29
  • Thanks, this was really helpful! The issue was a validation issue in a new column that I had added to one of the tables. It didn't show up until I added this code. – trees_are_great Feb 12 '17 at 21:23