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.
What version are you using? We are fixing crashes as they are reported, so please try patch releases as multiple fixes have already gone on. Keep checking the release notes for new fixes.
Note that when it comes to crash bugs, we do have crash analysis and statistical tracking in place. Naturally it’s better if you can include reproduction steps, but even if you can’t, it’s always worth sending us a report, as it’ll feed into the analysis system and can still give us some insight into the problem.
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: How to fix Windows error code 0xc0000005?
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).
ListPool.cs is a file from a 3rd party pathfinding library from the asset store:
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
This is an annoying issue, and is certainly a bug. I can say that for many projects, I’ve not experienced it, and I’ve not heard about it from anyone internally. But these issues with breakpoints not loading are often very sensitive to the specific source code in the project, as it may be related to the way the C# compiler generates the .mdb files.
So if it is possible to provide a sample project that reproduces the problem in this case, it would be very helpful.
Also, is this happening with the new scripting runtime only? Or does it happen with the old scripting runtime as well?
I know that it can be frustrating to submit a bug report for an intermittent crash, and get back a response from our QA team that they cannot do anything about it. That is not entirely correct. While we may have trouble fixing the specific bug, we do track and bucket all crash reports to help debug on a larger scale. Each crash report we get is valuable, because it helps us isolate the causes of these difficult-to-reproduce problems.
We’ve also been talking with our QA team about providing more accurate responses when they respond to bug reports like this. So don’t be discouraged, please send in bug reports for random crashes! The really do help.
I’d recommend moving to 2017.1p3 (and continuing to keep up with patch releases as much as possible) for anyone using the new scripting runtime. We’re fixing a number of bugs (including some for random-ish crashes), but we did not start to get a significant number of these reports until 2017.1 was released and the usage numbers when up. Our fixes lag a week or two behind as they work their way through our release process.
In the end though, I really want to thank everyone for trying the new scripting runtime. I know that your time is valuable, and dealing with random errors is not fun. We can only do so much testing internally, and we cannot replicate the industrial-strength work you are doing on a day-to-day basis. So the information you provide is invaluable to get us to the point where the new scripting runtime will be supported and default.
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.
