We had one of our project teams test out the Enscape 4.0 version. They decided to roll back to 3.4.4 because they experienced too many crashes. I am wondering if others have also experienced more crashes with this newest version of Enscape.
As crashes may of course depend on the machine itself (as well as other influencing factors) please also make sure that anyone with this issue simply forwards a support report with log files before or after rolling back to 3.4, this way we can directly see what the cause behind those crashes is to also let you know accordingly. Otherwise we cannot tell what exactly what the culprit here may be per individual machine without any report at all I’m afraid.
I will encourage everyone to submit logs. For what it’s worth, we have often found the process of submitting crash reports frustrating. We have to go over this generic checklist (update drivers, downgrade drivers, reinstall enscape, …) over and over again. It seems like we never get beyond this stage.
FWIW, when I submit a crash report with Autodesk it’s a very different experience. It goes directly to the development team. Is there a way to send crash reports directly to you? 
Thanks Pieter, if they could indeed submit their logs via a report each then that would be great. 
Furthermore, I have to add that in many cases a simple driver update or even re-install of Enscape can help at least with further troubleshooting, so it also depends on the situation itself. But, if you could just let me know once your users have submitted their reports, I can gather them up together to see if there’s a certain pattern for example that may give us a further hint as to why they experience these crashes in the first place.
Perhaps they are connected to each other and I do like to find out of course. Feel free to just ping me here again once that is the case and I’ll have a look myself right away.
Three of the four users on that team have submitted their logs.
I already received the standard reply:
In the past years, there have been several occasions where I did follow their advise (install latest release, update graphics), after which I was asked to downgrade the gpu driver, after which a new Enscape patch had come out, after which I had to update, after which a new driver came out …
It’s an infinite loop as far as I can tell.
Hi @Pieter_2 , I’ve taken a look at all three of the cases you submitted, and I am afraid the issue here is that none of them contained logfiles from 4.0 - they all only contained logfiles from the older preview versions. These will not be helpful to troubleshoot issues in 4.0, unfortunately. For all three machines, please be so kind as to re-install Enscape 4.0, try to recreate the issue, and then submit logfiles again - we can only escalate issues to our Devs when we have logfiles from the most current version of Enscape. Additionally, it looks like all three machines have pretty old GPU drivers, from December 2023. These would need to be updated as well, to eliminate them as the cause of the issue.
I don’t think that team is going to be very excited to reinstall Enscape 4.0 after what they just went through.
@Pieter_2 We can definitely understand the frustration, however there simply were no logfiles from the 4.0 version attached to any of the error reports you submitted, so anything we might suggest as a troubleshooting method would be complete guesswork since we don’t have anything to evalute right now.
Frustrated is putting it mildly.
I think this is where the root of the problem is. You are insulating your devs from your users with this approach.
I have submitted dozens of bugs on Autodesk products, and that process is soooo much better. They work with the information they have, and their teams dig in until they find the problem. The burden of proof is never on me.
With Enscape, bugs only get fixed if you have irrefutable evidence, which in practice is an impossible bar. Frankly, me and my colleagues are not getting paid to handle the QA of Enscape.
Hi @Pieter_2 , I completely understand your current frustration, and of course we want to do everything possible to find a solution for the crashes you are experiencing. However there are many different possible reasons for crashes to occur and without the specific logfiles from the machine where the crash happened, we can’t begin to troubleshoot or try to recreate the issue ourselves, which is an essential part of the process when trying to resolve a potential bug. We definitely are not asking for “proof” that this issue is happening - we certainly believe you that it is - but for instance if I try to recreate ‘crashing in Enscape 4.0’ on my machine, I can’t - it runs just fine. This is why we need the basic information from your machines, else we truly have nothing to go off of when trying to find the cause of the issue.
What could also be helpful is if you are able to determine steps you can take to recreate the issue - or, if this only happens on certain projects but not others, you can send us your project for us to test as well.
Well said @Pieter_2 , and thank you for your contribution to the community and pointing out the real problem that the user community is facing.
I need to be honset, both the feature voting request portal and support team feels like a box ticking department.
The process simply feels rigid with endless form filling, lack of engagement with users.
I may sound harsh here, and I understand people are “doing their job”.
But for the health and benefit of future Enscape development, it is worth re-evaluating the problem solving “process” & procedures you have implemented as a company.
Thanks Joey, I appreciate your support. It’s important that long time community members like you speak out. After that, all we can do is hope Enscape takes this feedback seriously.
@Helen_2 or @Demian, I understand you guys are working hard and doing your job. I am not trying to single out individuals here. It’s the process that was setup at Enscape for QA, support (and request portal, as Joe mentioned) that I have an issue with. Clearly it’s not working well enough.
Enscape’s quality assurance has failed for 3.5 (with the Rhino debacle) and now again with 4.0. I think one shouldn’t hind behind ‘there are so many models and graphics cards so we can’t possible start to reproduce it’.
The fact that so man people are complaining about stability means you don’t cast a wide enough net during AQ testing. Not testing on large enough projects, overlooking commonly used workflows (like working on large linked models with multiple collaborators in Revit), only testing on a too limited amount of hardware, …
Likewise, I don’t think it’s an excuse for Enscape to crash because once is using this or that driver. None of my other programs (like Blender) behave like this.
You’ve dropped the ball. That’s fine, it happens. But at least own up to it.
Now, for m problem at hand: as expected, none of my teams want to switch to Enscape 4.0 because word got around that it crashes all the time. What should I tell them?
we have 6 people working in a daily basis with ENSCAPE 4 and not one of them has reported an issue with crashing.
we have big and complex projects.
(sometimes from time to time it is taking longer to render some specific images, but that’s it.)
maybe it is your equipment?
maybe the way your pc / laptop is installed / configured ?
So there’s one team of 6 people that has not (yet) reported issues. All the others reporting issues must have faulty equipment. Sure.
looks like
You are likely just trolling, but for anyone else who’s reading this:
This team of 5 people was working on this Revit model for 3 months (Revit 2023.2) using Enscape 3.4.4. It crashes occasionally but not too often. The team is equipped with 6 month old laptops with a geforce 4080 and 64gb of ram.
When they installed Enscape 4.0 it started crashing often, for all 5 members of the team. When they installed 3.4.4 again it was working fine again.
Explain to me again how this is user error?