Unity permanently locks up when hitting a break point

Does anyone else have this problem?

Unity 2017 and 2018, both Visual Studio and Rider:

While the debugger is connected, at the moment a break point would be hit, Unity freezes as expected, but in Visual Studio or Rider, it looks as if no break point has been hit. Pausing in VS/Rider does nothing. Closing the debugger connection in VS/Rider does nothing. Shutting down VS/Rider does nothing. Unity is permanently frozen and must be killed from the task manager.

It’s intermittent and I can’t recreate it consistently, and neither could Unity support. Sometimes it’s the first time a break point is hit, sometimes the 10th or 20th. Both edit and play mode. No pattern. But I don’t see it with other projects, just this one large complex one, on 2 different Windows computers. I’ve been dealing with this for over a year and it makes me want to throw Unity in a dumpster and set it on fire.

Can anyone else shed light on this issue?

Answer: THREADING BAD

I slammed at this until I could consistently recreate it. It happens when I start a new thread on the same frame as the break point is hit, when my logging engine saved to the filesystem. It only happens after my log file reaches a certain size and needs to be trimmed.

Also on this thread, Julien_ mentions adding Unity to the excluded processes in Windows Defender so I’ll give that a go. I could see Defender freaking out when a new thread spawns from an unresponsive parent process.