Can't slice anything, getting return code 3221225477

[Digital1O1]

Application version 4.6.2 | 4.6.1 | 4.6

Platform Operating system : Windows 10 GPU : Nvidia GTX 1660 Ti

Printer Ender 3

Reproduction steps For the past week now, I’ve been trying to slice this calibration STL file, but regardless of what version of Cura I have, I can’t

The file can be found here : https://www.thingiverse.com/thing:2318105

Every time I hit the ‘slice’ button, it’ll go for a little bit, then crash as shown in the picture

But for whatever reason, if I lay the print on it’s side, it’ll slice

So I thought it was just the STL file getting corrupted or whatever, so I tried downloading other STL files from Thingiverse and the same thing would happen.

If I lay an object flat on the print surface, I can’t slice it. But if I were to lay it on it’s side, for whatever reason I can slice it, which is definitely NOT ideal.

Since then, I’ve done the following to resolve my slicing issue.

• Restarted my laptop and tried re-slicing the STL files
• Used programs like CCleaner to delete all the files on my Windows system, to include the registry files
• Wiped my entire laptop clean with a factory reset
• Double checked if Cura was ‘allowed’ through my firewall
• Increased my virtual memory

And nothing has helped so far.

When I went through the log file, I did notice this.

UM.Backend.Backend._onSocketError [214]: Backend crashed or closed. UM.Backend.Backend._createSocket [227]: Previous socket existed. Closing that first CuraEngineBackend.CuraEngineBackend._terminate [304]: Attempting to kill the engine process CuraEngineBackend.CuraEngineBackend._terminate [310]: Killing engine process CuraEngineBackend.CuraEngineBackend._terminate [313]: Engine process is killed. Received return code 3221225477 UM.Backend.Backend._createSocket [227]: Previous socket existed. Closing that first. UM.Backend.Backend._logSocketState [184]: Socket state changed to Listening

What caught my eye was the ‘Engine process is killed. Received return code 3221225477’.

I’ve tried googling the issue and I’ve found nothing

Screenshot(s) (Image showing the problem, perhaps before/after images.)

Actual results Can’t slice anything

Expected results Be able to slice a STL file

Project file Here's the WeTransfer link to the Cura Project I'm trying to slice

https://we.tl/t-ybxTY5vasG

Log file cura_bug.log

Additional information If it makes a difference, I do have Python 3.8 installed

And I have 16 GB of physical ram installed, so I know that there's plentiful computer resources.

On my other laptop, where I have linux installed, I can slice any STL file I download. I know it's a comparison between apples and oranges, but I'd figure I mention it here.

[nallath]

I don't think that python has anything to do with this, it's the engine that is crashing for some reason. I'm unfortunately on Fedora, and it works just fine for me.

Anyhow, a few questions:

• Is this the only model where it occurs for you?
• Does the problem occur with Cura 4.5?

[Digital1O1]

Hey Nallath!

The engine will crash with files that are 10 mb or larger. Files smaller than that I'm not running into any issues.

I've downloaded numerous STL files from Thingiverse that are that size and greater and have had no luck. Sometimes I'm able to slice a few files if I orientate them to the bed at an angle, but then I'll waste filament on using support structures and all that good stuff.

I've also tried using 4.6.1, 4.6, 4.2.1 and nothing has helped so far.

On my other laptop that's running Linux I'm not having one problem.

[smartavionics]

That code is c0000005 in hex, searches for that give pages like this...

https://stackoverflow.com/questions/17168982/exception-error-c0000005-in-vc

[Ghostkeeper]

@rburema or @konskarm are you able to reproduce this on Windows?

[konskarm]

I tried reproducing it on windows 10, but no luck. All the models in the thingiverse link slice just fine when laying flat. I just notice that it takes slightly longer to slice when its laying on its back (as shown in the first picture) compared to laying on its side.

[Digital1O1]

I've also tried the new 4.7 Beta and still no luck.

But I do have a question after doing some digging around in the Cura folders.

Hopefully this will make sense and I can get my point across clearly.

I know Cura has various Python scripts and uses Python 3.5 (Or a version similar to that). I currently have Python 3.8 installed on my machine and another instance of Python 3.8 installed in a VSCode extension called Platform IO since I'm working on some embedded projects.

Is there a slight possibility that the various versions of Python I have could result in the Cura engine to crash?

I'll mess around with the different versions of Python I have installed in the meantime, but I wanted to throw the idea out there first.

I'll update this thread if I find anything

[Digital1O1]

Update

I used Revo to un-install and remove any files in my windows registry for

• Python 3.8
• Python launcher
• Cura 4.7 Beta

And I'm still getting the same error code

[smartavionics]

I don't use Windows myself so this may not be a useful suggestion but is it possible to get a list of the DLLs that an application uses? Like the lsof utility on Linux can list all the files (including libs) that an application has open. That way you could see if Cura is using a rogue DLL.

[Digital1O1]

@smartavionics I'm not entirely too sure, but I'm willing to give it a shot and will come back with my findings sometime this week.

[Digital1O1]

@smartavionics @nallath So I have a SLIGHT update that could be worth mentioning....

So there is a windows equivlant to the Isof utility you mentioned and it's called 'Dependencies' and can be downloaded here : https://github.com/lucasg/Dependencies

When I load both the Cura.exe and CuraEngine.exe I noticed there were some red check marks by some of the DLL files that either state

1. 'x'.DLL module could not be found on disk
2. 'x'.DLL module has missing imports

And there's quite a few of them.

I'm honestly not too sure where to head from here.

I do plan on later this week making a 'Master list' of all the DLL files that are missing, couldn't be found, or have any problems in general.

And for those who are running windows, I ran the ScanDisk function from the CMD prompt to make sure all my Window DLL files were good and those checked out just fine.

If I find anything else, I'll update whoever is curious about this bug.

And if it matters, I'm running an AORUS 7 SA gaming laptop.

[smartavionics]

It's CuraEngine.exe that we are interested in for this issue.

How about this...

https://docs.microsoft.com/en-us/sysinternals/downloads/listdlls

[Ghostkeeper]

Is there a slight possibility that the various versions of Python I have could result in the Cura engine to crash?

Not if CX_Freeze is working correctly. That creates a version of Python as executable and packs Python files in the Cura.exe file. So it's using the CPython inside Cura.exe, not one of the Python versions from your computer. If it did use Python 3.8, you'd see a crash much earlier since Cura needs PyQt to render its interface. The version of PyQt that Cura comes with is compiled for 3.5.2, and would crash CPython 3.8. But like Smartavionics said, we're only interested in CuraEngine with this bug, so Python is out of the picture here.

CuraEngine has only one DLL that we directly call upon; libArcus.dll. The rest of the DLLs you see are included through MinGW which compiled it. MinGW provides access to the file system and more (e.g. to be able to load STLs from file, or to connect to local sockets) so those are the DLLs you see there. I never knew why some DLLs are missing when running executables though Dependency Walker or the like, but it happens with many applications on Windows so I don't think it really matters. It's probably functionality that we are not using, and are linked because we compiled CuraEngine on a different computer that does have them.

I think the problem is still more likely in our code, something causing a segfault. But it's really hard to tell without being able to reproduce it ourselves. And even harder to fix it then.

[Digital1O1]

@Ghostkeeper Be honest for me for a second...

Since a lot of people who swung by this thread weren't able to reproduce the problem, do you feel like it's probably just worth my time trying to learn how to use another slicing program?

Or is there anything that you would recommend me looking into to narrow the possible scope of the problem further?

[nallath]

You could try and compile Cura engine by yourself. If you're feeling very adventurous you could try running CuraEngine with GDB since that might tell us where it goes wrong.

[Ghostkeeper]

Agreed. Both of those options are really technical though. If those are beyond your reach, your best bet is hoping that someone else is able to reproduce the problem. Someone who does have the skill to run CuraEngine through a debugger and tell us what happens, or one of our developers or testers. In that case, if I were in your shoes, I wouldn't wait on that, no.

But if debugging CuraEngine is an option, it would save having to tune printing settings anew.

[Anacapala]

I had something similar - slicing starts then stops almost immediately. App is not hung and Cancel works. Slicing fails for any model in any orientation. Log entry at the failure was 2020-09-06 15:42:19,940 - DEBUG - [MainThread] CuraEngineBackend.CuraEngineBackend._onBackendQuit [898]: Backend quit with return code 3221225620. Resetting process and socket. 2020-09-06 15:42:20,327 - INFO - [MainThread] UM.Backend.Backend._onSocketError [218]: Backend crashed or closed. 2020-09-06 15:42:20,329 - DEBUG - [MainThread] UM.Backend.Backend._createSocket [231]: Previous socket existed. Closing that first. 2020-09-06 15:42:20,331 - DEBUG - [MainThread] CuraEngineBackend.CuraEngineBackend._terminate [315]: Attempting to kill the engine process 2020-09-06 15:42:20,333 - DEBUG - [MainThread] UM.Backend.Backend._createSocket [231]: Previous socket existed. Closing that first. 2020-09-06 15:42:20,337 - DEBUG - [MainThread] UM.Backend.Backend._logSocketState [188]: Socket state changed to Listening 2020-09-06 15:42:20,343 - INFO - [MainThread] UM.Backend.Backend.startEngine [90]: Started engine process: D:\Program Files\Ultimaker Cura 4.7\CuraEngine.exe

I fixed it by loading a default profile. The sequence, as best I can remember it was: . Print current model with settings that had worked OK for some time . Change material from Custom PLA to Custom ABS . Choose to restore settings to default . Adjust some print temperatures . Try to slice - warning that model is not printable . Check settings and adjust 2 that were obviously wrong, such as brim width 625!

Try again. Current model and half a dozen others fail slicing in the same way.

Application version 4.7.0 Operating system : Windows 10 16Gb GPU : NVidia GeForce GTx 1080

[rburema]

@Anacapala Could you please attach the model? We can't really do anything if we can't see what's going wrong with that particular model. Better yet, make a new issue and reference this one, since it might be something different that is wrong. (Engine crashes can happen for completely different reasons.)

[Ghostkeeper]

Better yet, a project file, since you indicate it only happens with certain profiles, but you didn't indicate what printer or nozzle you were using.

[Anacapala]

@Anacapala Could you please attach the model? We can't really do anything if we can't see what's going wrong with that particular model.

Not much point - I can't repeat it. Trying to repeat it does not create the unprintable warning of the invalid settings after changing the material setting. If that problem doesn't occur then the slicing problem doesn't occur. It's possible I can't repeat that because I am not starting from the original settings. I have posted here merely as a clue that the problem might be in the settings, and the settings problem might be the result of changing settings and choosing to restore values to default. Beyond that, I can't add much.

[matheusgratz]

Hello! I got the same error, and I arrived here.

Sorry to resurrect the dead.

My model was not slicing, but when I change ", Top Surface Skin Layer" to zero (I've changed that before the error) and Cura started to slice normal again.

I've decided to do that because when I changed to a "standard" Cura profile, the error disappeared.

Bye

[rburema]

Hi @matheusgratz could you share logs or the project file, or even better, both?

[matheusgratz]

Sure.

LOG: LOG.txt File: Petsfang Ender 3 v2 Base

[rburema]

With a 'project file', I meant a project .3mf, which includes the used printer and settings, for a good chance of reproduction. You can make a project file by 'File > Save Project' (so not export, which will also create a 3mf by default, but a 'plain' one without all of the information Cura needs).

That said, I see you are slicing with the Arachne Beta. (And thank you for trying out Beta's by the way!) This however is an early Beta which still contains a sizeable number of bugs! We'd still like to know about those of course, but there is a discussion thread where we collect all of these here.

[matheusgratz]

With a 'project file,' I meant a project .3mf, which includes the used printer and settings, for a good chance of reproduction. You can make a project file by 'File > Save Project' (so not export, which will also create a 3mf by default, but a 'plain' one without all of the information Cura needs).

Ohh, sorry for the misunderstanding. Please, find the file with "Top Surface Skin Layer = 1" (which did not slice). CE3PRO_BB_E3dv6.BASE.E3v2.E4.STK_2.7.21.3mf.zip

That said, I see you are slicing with the Arachne Beta. (And thank you for trying out Beta's, by the way!) This however is an early Beta which still contains a sizeable number of bugs! We'd still like to know about those of course, but there is a discussion thread where we collect all of these here.

Sure, I'll post it there.

[rburema]

@matheusgratz Seems to occur with more models, but on that printer, and with on 'Top Surface Skin Layer = 1'. Also when I run from source in the current Arachne branch.

It does seem to hang on a different point then though ... I got an exception in the 'CheckRange' function of clipper lib.

I'll put it up for the next standup to discuss with the team.

[rburema]

@matheusgratz We did some investigation, and it seems your specific problem (which is not the same as this github one started with) it the same as an issue already known to us (internally) as CURA-8096, reported to us here.

That fix is slated to be in the release candidate for whatever version Arachne is going to be in (5.0 in all probability).

In any case, as workaround would be if you can live without bridging until it's fixed: Disable 'Enable Bridge Settings' under the experimental section of the custom settings (which your profile has turned on by default) and it should slice without a crash.