I've got Windows 10 installed running the latest version of both Visual Studio 2015 and Unity3d. Whenever I run my projects within Unity3D I am constantly getting "Fatal error in gc: get ThreadContext fail" within Unity3D. However, when I run the same code within VMWare or Windows/Mac native, the errors don't occur. This now leads me to believe its environmental issues within Parallels with how Garbage Collection functions under such conditions. Furthermore, when I compare Basic Unit Test analysis within Visual Studio on a Native Windows device (same hardware - MacBook Pro), the iterations of garbage collections appear to have a smooth peaks/troughs in the graphing. When I run the same code again within Parallels, I see constant spikes in behaviour which again leads me to believe that hardware virtualisation type issues are occurring. I've tried to increase CPU/RAM allocations via configuration, and I've also made sure that the parallels VM are housed within the same SSD primary hard drive to ensure minimal I/O issues are a likely cause. I'm not sure on how to troubleshoot this further, and it dramatically impacts my productivity daily as a result. Any advice or ideas on what I could do to narrow my search on finding a solution would be welcomed. NOTE: When you search for information relating the GC GetContext it states that its linked to "Virus Scanners" etc. This is not always the case. GetThreadContext will basically only fail if you call it on a thread that isn't suspended, so the most likely scenario is that there's a case in Unity where a running thread can be added to this internal list after all threads in the list have been suspended but before the GC has done a sweep to call GetThreadContext on them. The GC then tries to get the context of a thread that should be suspended but isn't and kaboom. GC scans are typically triggered when you allocate memory. The memory manager sees that it doesn't have enough to give you what you've asked for, so it collects, checks again, and if there still isn't enough then it gets more from the OS. So in this case, since we're talking about a race condition, any change to when an allocation triggers a collection vs. when threads are starting will affect the likelihood of this error occurring. This is why people have reported this being related to Kaspersky. Virus detectors sometimes basically connect to apps with a debugger, which changes the timing of when things occur, so disabling a virus detector when this crash is happening may "fix" the problem. As stated, this DOES NOT occur on other environments outside Parallels but is repeatable ONLY within Parallels.