Is it common to have Visual Studio freeze itself when attached to Unity while debugging a script?

If the execution line of code steps out of a script function, Unity and Visual Studio can easily hang, resulting in no responses from both of them. I had to force close both applications using Task Manager on Windows.

To easily reproduce this, set a breakpoint anywhere in a custom C# script, attach Visual Studio debugger to Unity, and play the game in the editor. Once the breakpoint has been hit, keep pressing F10 in rapid succession. Eventually, Unity editor and Visual Studio will freeze, with the occasional Visual Studio Delay Notification icon appearing in the bottom right corner.

I see that the script can easily freeze up both Visual Studio and Unity if the script in question involves Networking and NetworkViews. It has become unresponsive for me a lot of times while I am working on my networking project.

I am wondering if this is a common occurrence in Unity development. If yes, is it a UnityVS problem, Unity editor problem itself, or something else?

 

Do you happen to know the UnityVS's official method of bug reporting? Usually, there would be a way to send project files across or something.

 

Ah, it's a known issue, therefore it's a very common issue. Thanks for the link. It really helps clear things up.

 

This seems to have come back in VS2017: Even in an empty scene. Any ideas?

 

What I usually do, is build from Unity, and deploy/run for testing from VS. This way Unity won't hang.

 

It should just work. Whether I attach first, run Unity second, or run Unity then attach. Having it work in one way and freeze the other, is pretty lame. It's pretty frustrating. I'm not sure how this goes out the door. What's QA doing? You're one of if not the biggest game engine company in the world, and people can't debug in your engine? Pretty embarrassing.

Random debugger freezes (very consistently upon detaching, sometimes when attaching). Breakpoints are not consistently hit. Can't set watches or see values of variables in coroutines. VS2015, 2017, Unity 2017/2018, doesn't matter what version or combination of tools you could name or come up with, we tried it. Tried different runtime/scripting backend environments, some cause freezing more than others, but all freeze.

Any _basic_ usage of the debugger, just make a simple pong game, will yield all these issues. What does this say...?

 

Mine freezes in an empty scene with a single Debug.Log() -- but it used to work fine until I refreshed Windows (strange- doing that usually fixes bugs).

I tried installing VS with the Unity installer >> Tried reinstalling VS using VS Standalone + Tools for Unity (usually comes with the Unity installer) >> Tried reinstalling Unity.

No dice.

 

I provided Microsoft with crash logs, and they managed to fix the issue today (I tested with their patch release 3.9.0.2). I hope the official fix will be out soon.

 

@onnep Do you have a link to that patch you could share?

 

Yes, I'm stuck because of this too. There's some error only when app is running on Android device. Unity and VS both freeze when I try to debug.

Please share link to this updated patch release.

Edit:
Latest change log of UnityVS is still ver 3.8.0.6 https://docs.microsoft.com/en-us/vi...og-visual-studio-tools-for-unity?view=vs-2017

I uninstalled just UnityVS Tools and reinstalled from VS Installer, its still 3.8.0.6

Also, VS2017 15.8.4 11-Sep release doesn't mention of new UnityVS https://docs.microsoft.com/en-us/vi...17-relnotes#-visual-studio-2017-version-1584-

 

Hi folks,

Sorry about the inconvenience. We've been unable to reproduce locally, but with the help of a few customers we've been able to find the culprit: a deadlock in the communication library we're using to talk to the debugger server inside Unity's scripting engine.

We're working on rolling out the fix across Visual Studio versions.

In the meantime, if you're impacted, feel free to reach out at vstusp@microsoft.com and we'll provide you with the fix.

 

@jbevain hey, thanks for fixing it. Email sent.

 

We've fixed this in our latest servicing release of Visual Studio 2017 (version 15.8.5, comes with Visual Studio Tools for Unity 3.8.0.7), which is rolling out today.

Make sure you update your Visual Studio version.

Thanks to everybody who contributed thread dumps to help us nail this deadlock we couldn't reproduce, and to those who validated the fix. Again, sorry for the inconvenience!

 

Awesome thanks Jb! Can't wait to try it. Is there any chance you guys could release that patch for VS2015 as well?

 

Yes, we're going to service our release for VS 2015 as well with the fix.

That being said, we strongly encourage you to switch over 2017, as you're missing on literally years of bug fixes.

 

We've updated the gallery with VSTU 3.8.0.7 for Visual Studio 2015 with the fix.

 

Awesome Jb, thank you!

We'd love to switch, unfortunately VS2017 is pretty much unusable for us. Every navigation feature we used in VS2015 is made explicitly _worse_ in 2017. "Find All Reference" used be instantanious in 2015, with a flat list output, even with large scale searches. Now it takes at least a second to process reglardless of scale. we use that feature very aggressively, having a 1+ second delay is a big productivity killer. "Go to Definition" used to also be instantanious, regardless of scope even on cold loads. Now it takes a couple of seconds on cold loads, then catches up on hot ones (subsequent finds).

 

I wanted to add my method of getting this to happen just in case but I am hoping this update will make my message moot. This was an awesome thread to stumble upon as this thing has driven me up the wall a number of times now!

In my case, if I install a bunch of assets I tend to have many assemblies and, man, how annoying is it to make a change to one script (add a new script in Unity, delete one, double click on an error in the console to open VS) and then I have to wait for all those assemblies to be reloaded every time I go back into VS. I sit there for a minute or three just watching it saying "Loading [bla]", one after the other after the other....

But, if I do something that will cause VS to explicitly say "This was edited externally and requires a reload, do you want to continue?" i.e. Unity crashed or I restarted Unity manually etc. Some times I would get to VS and find a chain of windows queued up to reload the project. Well, that's not accurate... I mean it asks me to reload the project and immediately afterwards it will ask me to do so again, then again... Some times, though, I get to VS and it wants me to reload the project (for whatever reason) but it just won't even let me press the button to say "Go ahead". Trying to close the window will just result in VS telling me it's busy.

FFS, I tell the application to quit and it tells me "No, I'm busy. Stop bothering me". So I open task manager and I force quit it there. That frees up my ram but VR still stays open in the Task manager and in my task bar. I have to quit the task a second time before VS finally closes. Then I can finally reopen it, wait for it to load the project again, slowly.... and then I can finally get back to work... till I double click on something in Unity and have to wait for VS to reload all the packages I installed and so the cycle continues.

So yeah, hopefully this update fixes this issue also so I'm off to update right now. Thanks!