Anybody else experiencing a very unstable editor when using .Net 4.6?

I'd like to share my experience so far with the experimental .Net feature. I like the upgrade and most things seem to work fine, when they work (debugging, building for platforms etc), but overall, the Unity Editor crashes every 20 minutes.

We are using the new version in our team at university on slightly different machines and at home, but we all get an unusual amount of crashes, compared to previous Unity versions, ever since we switched our project to .Net 4.6.

Sadly, we could not reproduce any of the crashes, as it seems totally random, when they happen: Starting debugging, pressing play, attaching during playmode, starting Unity, adding an object to the scene, undo, basically there's no pattern.

Not sure how to help identify the issue, since I know that bug cases without reproducible issues are closed pretty soon, so I wanted to ask if anybody else is having the same trouble and had a chance to report anything useful.

 

We're on 2017.1.0f3. I'll make some more tests at home and maybe send a crash log via the bug reporter.

 

I've had similar experiences, particularly when running the project. Using the Visual Studio debugger also seems very unstable and seems to lead to crashes, or I have to attach to Unity multiple times. I've reported a couple of crashes, but I got an email saying I reported the same thing twice and one was closed. They were separate instances though, so not sure what's going on there.

Everything stabilized when I moved back to the old .NET.

 

Similar here. I haven't been able to debug on any Unity build using .NET 4.6. I use Visual Studio Code to attach to Unity. Once i press play Unity becomes unresponsive and I have to force quit it.

 

@superpig unfortunately your QA team don't seem to be aware of this or they're being over-eager - We've been running on 2017.x edge builds for months now with .NET 4.6. We get crashes a lot. Its okay - Its a beta. However it really grinds down our motivation to support you with crash reports without a project or repro steps when your QA write back asking for more info or requesting to close the ticket.

It also really feels like a blackhole as we get zero feedback on .NET 4.6 specific fixes - If you guys are doing lots of fixes they certainly don't pop up in the diff'd patch notes.

We haven't bothered sending in the hourly crash reports for a few weeks now.

 

Here I have a rather extremely annoying issue that doesn't produce crashes:

Unity does not pick up changes in CS files, or it does it whenever it wants, resulting in 'breakpoint will not be currently hit' in VS. I systematically have to 'Reimport' the CS file for it to pick the current version, extremely annoying you'd agree.

I'd gladly submit a bug but it'll certainly end like : we need a crash dump and a sample project, which for the first I don't have, and for the second just doesn't make sense as it happens on pretty much any project, i.e. it'll end like 'closed as non-reproducible'.

Being nostalgic of my early days with Unity where all was shiny, today I have to cope with the dark side of Unity every day, i.e. the fractal of bugs in the editor. Still wondering how such regression can silently slip in a supposedly out-of-beta release ?

 

You're not alone. It's annoying, however unfortunately I haven't been able to reproduce it consistently. Is there any chance you have more than one instance of Visual Studio and/or Unity running? Trying to see if we can get a common factor here. I can't recall 100% if it happens only when there's 2 instances but it'd be worth ruling that out.

Unity 2017.1.0p2 (sometimes 2 separate projects)
Visual Studio 2017 (again sometimes 2 instances)

Regarding actual crashes - for me these seem to appear mostly when Visual Studio is attached, it's not too bad otherwise.

 

I've been getting crashes when entering Play mode every 5-10 times approx. This has been happening since I started using 2017.1.0f3, but I also started using .Net 4.6 at the same time.

The error.log file says a few things:

mono-2.0-bdwgc.dll caused an Access Violation (0xc0000005)
in module mono-2.0-bdwgc.dll at 0033:c8675bb6.

Read from location 000000e9 caused an access violation.

I submitted the log & dmp file with a bug report (not the game project though). Just waiting on the bug number and I'll post it here. Edit: Case 938731

 

Sometimes, but it does happen even when there's only an instance running. I have the same environment + Win10 + Resharper.

One of the thing I'm suspecting is that Unity is just like Windows, for which there's an urban legend that says 'always do a clean install'. I'm saying this because as far as I can remember these issues surfaced when I started testing other Unity builds in parallel, since then these issues never vanished. I've uninstalled everything, cleaned up registry keys, re-installed VS and also went VS2017 but that never fixed anything.

The main thing in my environment is that it's been installed a while ago (first Win10 version), upgraded all the way, i.e. seems like the Windows soup got confused over time, but I simply don't have the time to start fresh (might have to give a try).

 

You made a point there, actually I've forgot pasting these exception codes here, they're just like yours : access denied.

Unfortunately I don't have these dumps anymore and ironically I've tried to make the thing crash but it didn't ... Of the few dumps I've found in my drive, surprisingly they're all 0xC0000409 (unknown software exception !), even more puzzling when you search online : no official KB or whatever, only crap sites like 'fixmypc.com'.

 

Forgot to add, my last contact in a bug report, I got the following answer:

Thank you for the crash dump. I do believe the issue might be related to your computer. It seems that people experience similar 0xC0000005 access denied errors after Windows updates. However, there are various other reasons. You could look into this article: http://www.eassos.com/how-to/fix-error-code-0xc0000005.php

It seems to provide a lot of useful information on how to fix this issue.

That link suggests there might be a memory issue, in the past I've ran a Memtest86 for hours and it didn't found anything, which leaves the other option : a corrupted installation (the other suggested fixes in the link being simply silly or inappropriate IMO).

 

I got a reply on that case:

ListPool.cs is a file from a 3rd party pathfinding library from the asset store:
https://www.assetstore.unity3d.com/en/#!/content/87744

And that specific part (Line 176) is within a 'lock' as it is doing pooling of paths that are used across multiple threads.

I thought I was only 1 revision behind on that asset, but the developer has a 4.1 Beta that has "improved compatibility with Unity 2017.1"

The release notes have a point:

• Improved compatibility with Unity 2017.1, esp. when using the experimental .Net 4.6 target. Thanks Scott_Richmond for reporting the issues.

So in my case, I can probably update to the latest version and be more stable (just gotta find the time to dedicate to that).

I'm really happy with the stability of 2017.1.0f3 (compared to the betas), the daily crashing has only been a minor annoyance (restarting Unity is pretty quick).

I'll probably jump back into testing betas when the new garbage collector needs testing

 

I am not sure I have something with unity or not but I have unity 2017.1f3 and whenever I use it my system gets crash and I only need to restart it. Today I formatted my system just to verify the issue.
Hope its my system side and not unity side.

 

I'm using 2017.1.p2 in 4.6 mode and it crashes constantly. It's incredibly annoying. I've also experienced the thing where it does not detect changes in the .cs files and I have to manually reimport to get it to recompile. Often when it crashes, it does not pop up the crash reporter and there's no crash dump, which means submitting a bug is pointless.

On a related note, I want to voice my disapproval with tagging everything in every new release version as "Experimental" to get out of needing to officially support it. Especially now that Unity is subscription-only. The promise of Unity 2017 was that the forced subscription would somehow mean more stability and better release quality, but 2017.1 is pretty questionable, with most of it being experimental and unsupported, and half of the advertised features not even available in the installer and requiring a trip to github to actually install. You shouldn't even bother "releasing" a feature if it's going to be unsupported and experimental. Keep it in beta.

 

I think the purpose of this is to give it a wider audience so more bugs are identified. Many people (like myself) don't download beta versions and having a released version, even if experimental, are the first time they start checking out these new features.

 

That's not what release versions are for. They're not for trying to trick people who don't want to beta test into beta testing. If they need more beta testers, they should offer more incentives to sign up. Or, here's a radical idea, they should hire more actual testers. Release versions are supposed to be stable and officially supported, that's why they're called release versions.

 

I think you posted at the same time I posted that last post. I understand why you did it, but like I said, I don't think "Release" versions should be used to trick people into testing something that doesn't work. Part of the draw for users to join a beta is supposed to be that if they find bugs, they can get them fixed when the actual release happens. When you announce that you're going to keep pushing broken features into Release to do the "actual beta testing", it actually discourages people from bothering to use betas. Why bother helping with a beta when you know the "real" beta will be the current Release version?

 

"Trick" may have been too strong a word. I'm just saying I'd prefer it if Experimental features were kept separate from Release builds. But really, I'm just perpetually grumpy, and sometimes when the editor keeps crashing on me I have to go complain on the forum to keep my sanity, so take anything I say with a grain of salt.

 

Ironically, I've tried to reproduce it on a new project but failed ... so seems like it happens on a specific project, whenever it occurs again i'll file a bug report and attach it.

Also, it happened using the new runtime, not sure about the old one (there's so many benefits using the new one that I've stopped using the old one).

 

Crashing for me on 2017.1.1p1

 

I am still seeing a ton of crashes and mainly freezes even on 2017.3.0b2 which is killing my productivity. Sent in reports and got a reply in a couple days saying they could intermittently repo but now no word on if anything is being done about it more than a week later :/ Case 950310 if anyone is interested.

I've tried the majority of the patch releases as well so I jumped to 3.0 beta out of desperation. Now I have jumped back to 2.0 which is just as bad.

P.S I am not even using the .net 4.6. This is with the stable 3.5!

 

Thanks for that Josh! Let me know if there is anything I can provide

 

I am also experiencing intermittent crashes when I enter play mode in the editor. This issue started when I changed the mono runtime to .NET 4.6 , which I now regret dearly.
I filed two bug reports, but haven't heard back from Unity support personnel so I posted the crash log on the forum (https://forum.unity.com/threads/uni...the-game-from-the-editor.504418/#post-3286793), hoping to find some answers. Lo and behold, other people are having the same issue.
I hope this can be addressed in 2017.3 or whenever Unity decides to make .NET 4.6 stable. Until then, I am falling back to the stable runtime.

 

Yesterday I published a bug report -> https://issuetracker.unity3d.com/is...ering-slash-leaving-play-mode-on-mono-4-dot-6
And I wrote a lot about this bug here -> https://forum.unity.com/threads/frequent-crashes.489173

 

First bug I filed - #967206
Second bug I filed - #968359

both are for the same issue and I have attached the complete Editor log with the crash report and the stack trace.

 

I just opened a ticket from a thread I started in the beta forum. I'm getting frequent crashes all stemming from dll not found. In my case it's a UI heavy scene so there is one path that usually triggers it, but the code paths do vary (the most frequent one is in the bug report). Definitely smells like an dll reload ordering issue of some kind.


Case number is 979570.

 

This problem seems to happen more frequently on Windows Editor than in OSX and it is quite annoying

 

The first thing I do after opening a new project is to change the .NET runtime (and recently I've even actually used features unavailable in the older one). I haven't noticed any instability on macOS, and I keep the editor going for hours once I get started.

Those who can test all operating systems definitely should try working on their projects on different platforms for a while.

 

So I found a workaround for at least one variant of this. Given how it works I'm kind of disappointed that Unity isn't sharing workarounds when they know it might work, and they also know that this bug can hit people really hard just by the nature of it. Literally I was getting like 30 or so crashes per day. Now I get maybe one a day.

The work around is to look in the editor log and look at what isn't loaded. Now find a spot early in your scene load before where it's crashing, and just write some code that uses the code that failed. In my case it was failing at one spot, where it was trying to do a push onto a generic Stack. So the first thing I did in awake was create a stack and push something onto it.

This approach should work for most any dll not found error that's a result of Unity not actually loading it in time. Because once loaded that's it, it's done (unless they have completely hacked how assembly loading and app domains work).

 

Mine are not random though, way to consistent in where they fail and when. Literally 1 out of 4 times or so when I start the scene, and was always the same stack trace. Now I still get some random crashes here and there but not that one that was consistently failing at the same spot.

 

wouldn't memory corruption result in an access violation anyways most likely? I don't see how that could cause a dll not found error.

Edit: Well I take that back ya it could if it failed while loading it.

 

The repro scene is from a very large project. If it doesn't get fixed in 979570 I'll try to create a minimal repro case. The scene that constistently crashes is a heavy ui scene and the stack trace always originates from a very specific call, so I'm assuming creating a canvas with a bunch of the the correct ui elements would trigger it.

It could be same problem, just that my scene in question does a lot of whatever triggers that crash.

And on second look it does kind of look like it might be that same issue, because even the other less frequent stack traces are all ending in trying to add something to a mono collection of some type.