Unity Freeze when connecting VS Debugger

Unity friends and community.
I have contended with this issue hoping to find a solution that was not delete the breakpoints.
I did the windows defender Unity editor exclusion, but i went a bit farther and i also added exceptions for:
visual studio process and Folder
my unity installation Folder
my unity hub Folder
and my current project folder
Doing this i did notice gains in project load time and compile times, as well as a noticeable drop in the activity in the windows antimalware service executable in task manager during both tasks.
--> While helpful ... None of this solves the actual problem.
Ultimately i did remove my breakpoints thinking .. " Great now i cant use effn breakpoints ... well this is gonna suck."
The problem did go away.
And - to my surprise - i was perfectly able to add as many breakpoints in any point in my project i wanted to in any number, and it loads just fine and snappy as ever.
My project uses reflection to call classes that visual studio does not see a logical route for me to reach so it defines the breakpoints as unreachable, both before removal and after. The "breakpoints located in unreachable code" is not a contributing factor to the issue.

***END OF FACTS AND BEGIN SPECULATION SECTION***​

------------------------------------------------------------------------------------------------------------------------------------------------------
And so like any great programmer .. sitting here trying to do anything but my project, i started thinking on this more; why?
so i started working back in my project over the weeks. and then it hit me: some files with breakpoints set in them were deleted or renamed for whatever reason and that there is the only outstanding connection :

i think it's possible that this pausing / freezing occurs if there is a breakpoint set on a class file that was deleted or otherwise moved, and the file contained a breakpoint in it, and the change was not tracked by vis stu for whatever reason.
This would explain why the clearing of breakpoints fixes the issue, and you can use them after with no issue.
This would also explain why its impossible to outright duplicate without some "project setup".
and no one has far as i can tell who has the problem and reported it has considered that as necessary steps for duplication of the issue.

 

Deleting all breakpoints worked for me on 2020.1.10f1 / VS2019 for Mac on Catalina 10.15.7
Thanks!

 

you save my life... thanks

 

Hey all, upvote this Visual Studio suggestion so they'll make a fix for this. No one else should have to come to this thread to be able to debug. Impossible breakpoints that break things should automatically be removed or at least ignored.

 

Yes, please upvote it. But more importantly, please add comments to the Developer Community feedback for how we might reproduce this. If you can share with us a project that reproduces it (privately, and can do NDA if required) that will go a long way.

We agree this needs fixed ASAP.

- Program Manager, Visual Studio Tools for Unity

 

When I open the link and log in I get this "We were unable to get this feedback item. It could be because you don't have access to it or it doesn't exist"

I can usually reproduce this bug by having several C# files open in Visual Studio and having breakpoints in a bunch of them, usually 5 or 6. I can't really be more specific than that, because as far as I know there is nothing special about any of the lines where I used the breakpoints.

 

@StephenW Sorry about that.

Try this link: If old breakpoints are being problematic, give user option/suggestion to clear them - Developer Community (visualstudio.com)

 

Deleting all breakpoints fixed it for me too. Try deleting all breakpoints when it is attached and unity is frozen.

 

@Valhalaru

Which versions of Visual Studio and Unity?

 

Deleting all breakpoints worked for me too - afterwards I added a new breakpoint in and it worked fine.
Maybe I had a conditional breakpoint like was mentioned or perhaps just too many breakpoints.

 

Still happens to me

 

I'm getting this as well. It may have happened one or two times in the past, but I'm getting it consistently today, which is making productivity... painful.

 

@angrypenguin,

Does deleting all breakpoints temporarily resolve the issues? This menu option is in the Debug menu or Ctrl+Shift+F9 by default.

 

No, it does not. Unity hasn't crashed as far as I can tell, because the "Busy" dialog has popped up. It is currently telling me that it's in ConsoleWindow.OnGUI.repaint, and has been there for two minutes on a machine that usually starts the game in seconds. The debugger is connected, but I deleted all breakpoints immediately prior to attaching.

With today's issue, Unity remains hung even after the debugger is disconnected. When I posted on Friday it was carrying on line normal once the debugger was disconnected, so maybe they're separate?

 

Sorry I don't know the specific version. It was the latest LTS version of Unity and Visual Studio Community 2019, in February 2021.

 

I use Jetbrains Rider it is annoying and makes Unity undebugable. Deleting all the breakpoints does not help for me

 

YUP still happens. Latest VS and latest unity

Ill try deleting breakpoints then

EDIT: YUP that was it. Sigh.

 

Yeah, I swapped to Rider in large part because of the above issue, and haven't looked back. VS is great, I'll still happily code in there, but for getting stuff done I just needed something that reliably works.

 

Honestly you wouldn't believe it. Rider crashed my project the last time i used it. And then on it's first major refactoring... Crashed half way through and left me to pick up the pieces of the trashed code.

You couldn't make it up XD

I suspect it wants a newer version of windows but I never could make it work consistently. PITY ME

True story: I actually debugged for the first two months of this project with just Debug. Log - no really. I didn't crumble and use a full debugger until I had to debug 3rd party bugs (for the last two months sigh...). Hey ho

 

Share you couldn't repro. Ah well. it is intermittent. but once it strikes in a session there is no going back. Appreciate you trying.

 

I used Unity back when there wasn't a breakpoint debugger.

Well, we had Unity's modified version of MonoDevelop, but it was unreliable enough that I rarely considered it an option. VS Tools for Unity was a big deal when it came along.

 

Xbox360... Yeah. Unity was the easier option I decided upon... what you want to check you have a file on the harddrive? PFFTT!!! LOWLY USER BUILD HARDWARE (EDIT: Yes I still have that hardware LUL)

 

This is the most "Capstick Come's Home" conversation of this year, surely.

Kinda NSFW if your workplace is filled with prudes
And yes. I was actually brought up in one of those mining towns. Terrifyingly any one of those shots could be my childhood

 

This fixed my problem. Thank you!

 

I know right? what a heroic post

 

This is such a PITA working with the tools that deadlock.
I'm using the latest 2021.1 and VS 2019 16.11.5 enterprise.

I'm not sure how you could use the tools for more than a day and not run into this.
When I look at the link to the Microsoft developer community and see that they don't have enough information.
It like.. what more do you need? How much spoon feeding do you need?

This lockup bug has been happening for a very long time and clearly many run into it.

At the very least you could try to detect the lockup occurred and put a dialog up telling the user to delete ALL of their breakpoints.

 

I actually did read a pile of those threads. The guy took some time and didn't manage to repro. it happens.
Shame but honestly just clearing out dead Breakpoints in an annoyance but manageable. I second an upstream solution of course. but not managing to repro a bug is not unusual. I wish it wish

 

Yeah, we can't be too upset with that specific developer personally, I agree. It's entirely possible that an individual developer could just not be exposed to whatever is triggering the problem.

But organisationally, between Microsoft and Unity, this is a pretty fundamental and widespread issue. It impacts a large number of customers. If someone put a number of developers onto it exploring in a variety of different directions then there's a high chance that at least one would find a repro case, because it seems to be fairly common. The fact that one developer can't repro it really isn't an excuse for it having gone on for this long.

My guess as to why it's gone on this long is that the VS Unity Tools extension probably doesn't have a lot of economic incentive behind it.

 

Thinking back the gentlemen did not discuss his methodology and it is entirely possible to operate on large tranches of code and not hit this bug, I haven't for a couple of weeks just probably by pure chance. Greater details on an exact repro in a small test project would go a long way to making this go away. Moreover I haven't seen anyone post such a thing

 

'Common' is relative. Are there 'a lot' of Unity users experiencing this? Yes in terms of proportion of user feedback. But what's 'a lot'? 0.01% across hundreds of hours of development time each? It's a bug that may only happen every million man hours of development. When you have millions of developers all using Unity, it'll keep happening, but if you put a hundred guys onto the task of creating a repro case, they might not come across it in their lifetimes.

 

Enough that it seems to be semi-common knowledge in my local dev community. "Oh, that? Yeah, you've just got to remove all break points." I'm not just looking at the complaint threads and imagining that they're representative.

 

Tend to agree. Whilst not prevalent it has bitten me more than once and I'm just one guy...

You only need that one lucky monkey with the typewriter.. but enough about my coding...

 

Yes, and it's happened to me. But across how many millions of hours of development? That's the point. Saying enough people are affected that it should be easily reproduceable by a team is glossing over the actual metrics. I've had it happen to me once or twice in one project, over hundreds of hours, likely thousands even, of coding across several different projects. Once the breakpoints are deleted, problem solved. You'd need a team to spend hundreds of hours just coding multiple projects to have a chance to create a project where this happens; it's quite possibly they'd never be able to reproduce it.

So how can you say "one dev being unable to reproduce it isn't an excuse"? How many people should be thrown at this problem for how long, for a problem that's got an easy fix AFAICS. I see in this thread you've struggled more than most, but that's an outlier, possibly a unique situation, and clearly across millions and millions of hours of Unity development, no-one else is suffering the same persistent problem as you going by this thread.

But across how many hours of development? I'd guess for me, it happened something in the order of once for every thousand hours of development. Is the idea that MS/Unity should get a bunch of guys just coding on a project for a year until it happens to them?

 

But, by that token, you are just one sample point. and therefore your experiences of this are as statistically atypical as ours. No one really can know the cost of time lost. Would be nice to get it fixed.

 

From some napkin math, close to zero "millions" based on my sample. But hey, since I'm referring to my local dev community as my sample (and not online threads where people complain about it) maybe what's really happening is that it's a geographically specific issue?

There's no reason for them to start searching from scratch. There's also no reason for their sample to be "all Unity users" or even "AP's local dev community". Their sample can be "people who repeatedly run into this exact issue", because they have access to that.

They can ask the developers complaining about the issue for projects where it's reproducible and start there. If that doesn't help narrow it down they can put the call out for people who'd be willing to allow an RDT session. Back when I was running into this it's very likely I could have given them live access to a repeatable repro case.

Maybe I still could. Haven't had to worry about it for a while now.

For those for whom the workaround did fix the issue, were you able to put the breakpoints back in and start debugging before you hit play the next time?

 

Yeah. It's just the mangled links to points in the code that no longer exist. A really studious person could probably figure out which link was fubar, just remove that. and carry on. is my experience.

The hang is infinite and visceral as you know, so plenty of time to tinker and consider

 

The only measure we have is user feedback. If everyone was significantly affected, the number of complaints would produce a very lengthy thread. As it is, we have all of two pages stretching back a few years in this thread. Ergo, in the absence of substantial evidence that there's a real problem, the sensible thing to assume is there's no real problem.

For those still facing significant issues, it's a bitch and I feel for them. But realistically there's nothing that can be done.

For the record, I once spent two years on an educational app that tied in to Flash using a .dll. Just after launching, Adobe changed the way Flash worked and my project died. The .dll was no longer supported. I reached out to the language developers who said, "sorry mate, but you're the only person in the world affected by this and we can't dedicate any resources to helping you out." Which sucked and wiped out two years of my life, but that's reality. SO I'm not coming at this from the perspective of someone who doesn't understand what these frustrations are like.

In short, it would be great if a fix was found for those having serious issues. However, my point is it's not easy (otherwise it'd be already fixed) and is not of significant impact to enough people to warrant the investment of time to fix it. You have to find enough people affected to convince MS of investing the resources, or find some other solution.

 

Agreed with everything except those points.

 

Until I found this thread I had given up on ever being able to debug unity and resigned myself to Debug.Log statements to figure everything out. Deleting the breakpoints worked for me.

Addendum:
Once I could actually step through the code I figured out the bug I was working on in minutes, after spending hours scratching my head.

 

affected or not affected, it is a question!

 

Signing in to say I've been facing this off and on for the last few days. Just encountered it on 2021.2.7f1 and VS 16.11.5 ~30 minutes ago before finding this thread and deleting my breakpoints.

 

Got this problem again today, for about the third time in the last year, so I would suggest a day or two of testing may not be sufficient to reproduce it.

In my case, the process seems to be something like:
Start debugging program okay
Add breakpoints while running
Add conditional or action breakpoints while running (work fine)
Click Stop button in Visual Studio (Unity still running)
Make code change in VS & click Attach to Unity
Switch to Unity & stop it running.
Rerun Unity.
Sometimes the hang occurs at this point (I get the Unity "long task" bar up about 40% of the time), other times it may work once or twice more before I get the hang. Pressing Stop in VS instantly frees Unity from the hang, but it will likely reappear on the next AttachToUnity. Note that closing & restarting Unity & VS does not cure the problem.
Deleting all breakpoints, or specifically the conditional/action ones via the breakpoint window (Ctrl-Alt-B) clears the problem.

Current versions are VS 2019 16.11.8 and Unity 2020.3.25f1.1418, but I know it has happened with earlier versions of Unity (both 2019 and 2020) and am 85% sure I also got it with VS 2017.

 

Was hit this weekend. Deleting all breakpoints seemingly fixed it, even if it wasn't clear it had since VS2019 kept reporting that any new breakpoints I set was unlikely to be hit, (atleast any line that was in virtual functions behind a shared interface)...ended u-p also restarting Unity and VS after removing all breakpoints and now it works again...maybe Resharper was confused too.

 

For those interest: in VS on Windows it's done with: Ctrl + Shift + F9

Apparently I had a breakpoint in an embedded package file which did no longer exist (had it embedded for testing). Debugging sometimes worked but mostly did not and even if it worked it was very slow and felt sluggish. Now it's super fast (as it used to be). Never would have thought of looking for a breakpoint on a deleted file. Why are those not removed automatically, so weird.

 

Happend in 2020. 3 Also.

Left for future reference.

My solution
1. regenerate project files (Preferences->Regenerate project files button)
2. Delete all breakpoints
3. attach debugger through menu 'Attach Unity Debugger on VS' (Debug -> Attach Unity Debugger)

I'd never thought 'break point' is the problem. but it is.

 

Thanks for this. I still had breakpoints set in code that was still in my project, BUT I had changed scenes and were no longer referencing them.

Once I deleted all breakpoints it fixed the problem. Also note that you have to delete them, don't just uncheck them.

 

Hey, I'm not alone!

 

Deleting the .vs folder fixed the problem for me. Improved debugging performance significantly too

 

So issue started 2018 and still ongoing 2023, 5 years later with unity 2021.3.16.

 

Still an issue with Unity 2021.3.21 It would be nice if there was at least a way to cancel the compile when it happens, as it is now i need to open the process explorer and kill unity for it to go away. Simply detaching doesn't always work.