8 hours ago, ahoeben said:It is NOT NECESSARY to delete the cura.cfg file if you disable all except one display!
Removing that file will cause Cura to go through its initial setup wizard when you start Cura again.
Fair enough - I just know that it contains the position where the window was last open. Although if you read through the thread... we've already deleted cura.cfg at almost every step anyway.
Deleting cura.cfg as a blanket solution is potentially throwing out the baby with the bathwater. If it is not necessary, then don't do it.
2 hours ago, ahoeben said:Deleting cura.cfg as a blanket solution is potentially throwing out the baby with the bathwater. If it is not necessary, then don't do it.
Normally I'd just recommend renaming it or moving it to another folder to see if a fresh config file would fix anything, but in this case the baby had been thrown out a while ago and the bath can be refilled but the baby can't come back.
On 12/21/2023 at 11:57 AM, Slashee_the_Cow said:Okay, now if that wasn't your problem, let's try skipping the pesky "installation" step. Uninstall Cura. Download and install 7-Zip (also free, open source, and great). In Windows explorer, go to wherever you downloaded the Cura installer. Right click on the Cura installer, 7-Zip should have added its own context menu options so just go to 7-Zip > Extract files..., pick a folder to extract them into, then when it's finished go to that folder and try to run UltiMaker-Cura.exe
In between Christmas preparations, I tried this method but still nothing happens when I click on the "Ultimaker-Cura.exe".
It has got me stumped.
Enjoy the Holiday season everyone....
Steve
18 hours ago, antigravitypaddy said:I tried this method
Note that that method was a specific answer to a specific issue that the installer did not work. It is in no way a solution to get Cura itself to start.
What OS do you use? On Windows, only Windows 10 and Windows 11 are supported.
Edited by ahoebenOn 12/24/2023 at 11:47 AM, antigravitypaddy said:In between Christmas preparations, I tried this method but still nothing happens when I click on the "Ultimaker-Cura.exe".
It has got me stumped.
Enjoy the Holiday season everyone....
Steve
I have had the same issue as you Steve. The last version of Cura I could open was 5.0. Any version since then appears to install normal but will not launch when I select the .exe... Just a spinning wheel for a few seconds and then nothing. I also have Windows 10 home, single monitor etc. I have tried everything suggested in this topic...nothing. It would be great if there is a solution for this...
It seems you have problems with all newer versions. Perhaps you have a problem with obsolete plugins and/or malformed configuration files.
Since the spinning wheel is showing you should at least find a log file in those locations that can help to identifier your problems:
%appdata%/cura
--> stderr.log
%appdata%/cura/5.6
--> cura.log
It may be a good idea to start Cura without any configuration files that it can find and convert to a configuration file set for 5.6. Therefore you need to backup all directories in %appdata%/cura and then delete them all. You need to close Cura before doing so. After deleting all the directories you can start Cura 5.6 again. It should now start as a vanilla installation without any configurations and plugins.
Perhaps someone find it useful:
It's in polish, but you got the clue.
BR folks!
18 hours ago, mystichussar said:Perhaps someone find it useful:
It's in polish, but you got the clue.
BR folks!
I'm not really up on my Polish, but for those who are a little less up to date than me: that's in the Windows settings somewhere (I'm not sure where exactly because I don't have a laptop with discrete graphics running anything newer than Windows 7) selecting whether to use the integrated graphics or the graphics card for certain programs (instead of automatically for everything), and setting it to the graphics card.
1
Hi trying to install on another computer and have this trouble. Seems unresolved...
Tried everything on this thread, single monitor, changed directory, deleted all appdata
Installing on windows 10.
@Slashee_the_Cow, indeed the poster should at least give some minimum information to understand his post better...
The problem can happen with a desktop pc as well in case you have a cpu including graphics support and a additional graphics card.
Unfortunately that isn't the main route cause of the problem. The problem is mostly a faulty (or faulty installed) display driver - except from the fact that the graphics hardware don't support opengl >= 2.0 as this is the minimum version for running Cura. And more often was this introduced from the windows update where they fall back to an ancient display driver at some point.
The best advice for most users is maybe to check and update all installed graphic card driver's in the pc manually. Switching the graphic device is usually only a temporary workaround that will bite the user again later once more. It isn't a general solution as well as not every user have two graphics solutions build in and it assumes also that the second device uses updated drivers (what is maybe as well not the case).
🙂
Edited by DivingDuck
Installing up to version 5.3.1 works fine. Including installing it to a custom location, in my case the D drive. I'm installing it onto an Alfawise Z83 tiny PC, that lives in the garage with the 3D printer. I access it by remote desktop.
The PC only has 32GB of internal storage, barely enough for Windows 10 Home (WinPE version), since Windows is a disk hog, so I have installed a 128GB SSD via an internal USB port, HDD D:\, and put all my applications on D:.
If you try to install v5.4 and up you get the attached error message:
Error message from 5.4 and above.pdf
This message results from a call to a non-existent handle in the QTWidgets DLL, distributed with the version.
If version 5.3.1 is installed, it can be started correctly. If v>5.4.0 is installed *on top of* v5.3.1 (same directory), version 5.3.1 won't start, and throws the same error message. Installing on top of another installation isn't kosher, but it is an interesting experiment showing that the QTwidgets DLL is the problem.
It should be noted that I had v5.7.0 running on this PC. This PC has been used this way since v4.5, or so, and I just added the new versions as they came out. When I added the 128GB SSD, I damaged the OS image, and had to replace it. Since then I have been unable to reproduce the functioning installation.
Nevertheless, v5.3.1 installs and runs *every time*, v>5.4.0 never runs after installation.
My installation of Windows 10 Home is completely up to date, so this isn't a Windows staleness issue (polemics aside). I don't have Python installed on this machine, but the error is the call to a non-existent handle in the QTwidgets DLL, not Python.
There is clearly a problem with a call to a non-existent handle in the QTwidgets DLL distributed with versions >5.4.0.
The suggestion has been made to delete the log files in %appdata%\cura. I have attached the log files from the successful execution of v5.3.1 (please note that stdout.log is empty, and so this app refused to attach it?). I then deleted them, and installed v5.7.0, which, not unexpectedly wouldn't start. However, it *also did NOT create* any new log files while attempting to start.
So, deleting the log files in %appdata%\cura did not fix the problem, and in fact v5.7.0 doesn't even get as far as creating a log file. Perhaps the "debugging" was left on, and the offending call is to a logger?
Please post the specs of your mini computer. It might not be capable of running newer versions of Cura for some reason. I'm guessing if it only has 32GB of storage (probably eMMC) it probably has a criminally low amount of RAM.
Yes, please find below:
I'm running Windows 10 Home 64b with a Thinstuff Thinclient for remote desktop.
As I said the box has run Cura 5.7.0 before, since it came out actually. I'm only reinstalling now because I added a 128GB SDD, so that Windows can hog the entire C:\ drive, and damaged the OS image. Since I have page files on both, now I have approximately (I guess that with no PDFs, you also can't use ALT-247 for the approximation symbol) 12GB free on the C:\ drive.
Please note that I am very (as in very unfortunately) familiar with the exception due to a non-existent call in a dll, albeit in .NET. The "unhandled" bit bothers me tho'.
No log file is produced when this happens, and I don't know how it would be generated in python. But, in .NET, there is, or should be, an exception handler in each method. Then, when the exception is encountered, it can be logged, and the application can do something else besides crashing and burning. Since I don't see a log file (maybe I"m looking in the wrong place? I'm looking in %appdata%. 'cuz the OS won't let you programmatically write to the application directory) I don't think the exception is being handled.
New experiments. As I said Cura 5.7.0 used to run on this machine, before I damaged the OS image, and had to re-install. I removed Cura 5.7.0, burnished the OS (cleaned out all the caches, temp files, restarted, etc.), reinstalled Cura 5.7.0, as administrator, using the complete option, no custom paths. Before starting I recovered the Cura 5.7.0 directory image from backup on my NAS, and overwrote the Cura 5.7.0 install directory. I tried starting Cura, with the same results.
Looking in %appdata%, I saw that the last folder I had was 5.3, so I copied the rest of the contents of %appdata%\Cura from my backup on NAS. I then tried to restart Cura, with the same results.
Are some particular OS extensions, like the .NET libraries, C compilers, etc, required for proper execution?
At this point I have a complete image of the Cura and %appdata% Cura directories from backup on my NAS. But, I still have no joy, so this suggests to me that it is a registry or missing OS extension problem?
I installed Cura versions 5.7.0 and 5.3.1, each in their own directories, and copied the contents of all directories starting with "py" *in 5.3.1 to 5.7.0*. I noticed that the 5.7.0 has a "Pythonwin" directory, and 5.3.1 does *not*. Also, doing this changed the startup behaviour, now the start up message is:
Which, while not Joy, is a the ONLY change, anything I've done, that has produced a change from:
I think that there is a registry entry or OS extension that is missing? This PC had the Arduino environment and several USB instrument applications installed, previously. Sadly, there were also several things installed that were removed (because the &*%&*% OS consumes the whole SDD), and I don't remember what (I've had it since 2016). Consequently, randomly installing things to fix this doesn't seem practical.
The Cura system requirements state a minimum of 4GB of RAM is required. These requirements have obviously gotten higher over time, which is why an older version might work but newer ones don't.
(I've also tried running Cura on something severely underpowered for kicks, and it didn't work on that either)
As I said, Cura 5.7.0 ran on this system, I have several printouts that were done by this. In any event, Virtual Memory only slows things down and memory management problems would crash the OS, not throw an "unhandled exception". AND certainly not an unhandled exception because a DLL handle can't be found. Many times, while chasing an exception, I wished the explanation were so simple, but it is not, 🙂, even if Windows memory management isn't stellar.
Search for problems with Cura 5.x, the search will turn up many people reporting successful install followed by a failed startup.
Also again, why is the exception "unhandled" (and unlogged)? Does Cura have a command line switch to enable logging?
This is not something that can be troubleshot by opinion, it needs to be troubleshot by identifying the cause of the exception.
Also, there is a new folder, associated with Python, starting in version 5.4--Pythonwin. This folder contains a dll (mfc140u.dll v14.0.24234.1) and a python file (win32ui.cp310-win_amd64.pyd), are these the source of the problem (by the bye, all DLLs should be in the GAC, not the application folders)? Don't know, because I would be guessing. But, I do know that 5.3.1 installs and runs every time, and >5.4 installs but don't run, and I know that 5.3.1 doesn't have a Pythonwin directory and >5.4 do.
Also when I run Python 5.7.0 on my laptop, it uses 590MB, with python consuming another 26MB. I may consume more at startup, but the page files alone, on my Z83 are about 3GB. Even windows can manage this, or at least should. If you're willing to wait.
If the exception can be tracked to a misbehaviour of Windows Memory Management, then alea jacta est, but otherwise we are *guessing*.
I don't code in Python, and if I did it would be in Iron Python, so it is beyond my skill set to use the Github source. Does someone have an instrumented flavor of Cura >5.4.0, that would log this exception?
Installed python-3.12.0-amd64.exe, from the Python software foundation, and the error message *changes* to:
So, I'm off to find the wiz...uh QTcore.
It appears that Cura >5.4.0 requires Python 3.x, but the installer doesn't install it...
22 hours ago, ghbarbehenn said:As I said, Cura 5.7.0 ran on this system
So what's changed in the meantime? I'm presuming software and OS updates, even if not major, but they could have an effect
22 hours ago, ghbarbehenn said:In any event, Virtual Memory only slows things down
Slow memory > not enough memory.
22 hours ago, ghbarbehenn said:and memory management problems would crash the OS, not throw an "unhandled exception"
I don't think it would crash the OS if a program requested memory which simply wasn't available. And I can certainly imagine not being able to load a file like this that is always expected to be available isn't something you'd bother catching.
22 hours ago, ghbarbehenn said:AND certainly not an unhandled exception because a DLL handle can't be found
I would say "not if it's running out of memory while trying to load one" but if it always happens on the same one the odds of it being the same one are low, although possible if it's a particularly large file. Same exception comment as immediately above applies.
22 hours ago, ghbarbehenn said:Also again, why is the exception "unhandled" (and unlogged)? Does Cura have a command line switch to enable logging?
Cura has built in logging, generally to %APPDATA%\cura\stderr.log or %APPDATA%\cura\stdout.log
And as I said, there are so many possible exceptions that you can't reasonably handle all of them, unless you put every operation in a try/except block and set it to catch the generic Exception class but that would slow things down (and catching Exception objects is from a technical perspective bad programming, but it's hard to put in a handler for every single possible exception).
It's possible the developers have internal builds with more verbose logging, but making them publicly available wouldn't really help since you still have the problem.
22 hours ago, ghbarbehenn said:Also, there is a new folder, associated with Python, starting in version 5.4--Pythonwin. This folder contains a dll (mfc140u.dll v14.0.24234.1) and a python file (win32ui.cp310-win_amd64.pyd), are these the source of the problem
Cura comes with its own Python environment so outside changes shouldn't affect it.
22 hours ago, ghbarbehenn said:(by the bye, all DLLs should be in the GAC, not the application folders)
No they shouldn't. Haven't you heard of "dependency hell"? If different programs require different versions of a library you're going to have a problem, hence why most of them include their own copies.
22 hours ago, ghbarbehenn said:But, I do know that 5.3.1 installs and runs every time, and >5.4 installs but don't run, and I know that 5.3.1 doesn't have a Pythonwin directory and >5.4 do.
It's possible the files in there have something to do with it. It's possible they don't. Correlation is not causation, and it could just be an update to its internal Python interpreter.
22 hours ago, ghbarbehenn said:Also when I run Python 5.7.0 on my laptop, it uses 590MB, with python consuming another 26MB. I may consume more at startup, but the page files alone, on my Z83 are about 3GB. Even windows can manage this, or at least should. If you're willing to wait.
On my desktop it takes up about 630MB. Before I load any models. Load an extremely basic model and slice it, up to 690MB. Clear plate, open a project with a slightly more complex model (but still far fewer polys than I've seen in a lot). Bam. I'm up to 800MB. Clear plate, open somewhat more complex model. 1GB. Clear plate. Open a 204MB STL of a sphere that consists of about 4.2 million polys? Cura's up to 2.6GB.
I know these shouldn't affect memory usage at startup but my point is that Cura can get pretty memory hungry. I would say I'm surprised you can run Windows 10 at all with 2GB of RAM, but I have an old "netbook" that can do it. Well, not runs. Crawls. Inches along. Technically functions, but I wouldn't call it "running". It is swapping to a HDD.
22 hours ago, ghbarbehenn said:If the exception can be tracked to a misbehaviour of Windows Memory Management, then alea jacta est, but otherwise we are *guessing*.
I'll take bets that it's Windows' memory management. 99:1. Anyone interested?
16 hours ago, ghbarbehenn said:Installed python-3.12.0-amd64.exe, from the Python software foundation, and the error message *changes* to:
That looks like exactly the same error you got earlier when you played around with the program files. 5.7 uses a newer version of Python than 5.3.1, I can tell you that much - I finally have f-strings! - all while my computer had Python > 3.6 installed.
16 hours ago, ghbarbehenn said:It appears that Cura >5.4.0 requires Python 3.x, but the installer doesn't install it...
Comes with its own internal Python runtime. Doesn't require external Python installation. I've tried it on one of my lesser used machines.
Also, to help clear things up, IronPython is just a different Python interpreter. The language is exactly the same.
Well, first of all to *completely* clear things up Iron Python is *NOT* an interpreter, it uses the JIT compiler system common to all Visual Studio languages. Consequently, it is 10 to 100 times faster, and can access the entire dotNET ecosystem. In fact, Iron Python, C++, etc. (and yes even Visual BASIC) files can be mixed and matched in a Visual Studio project, because in the end it compiles them all to a common intermediate language that gets fed to the JIT compiler at run time.
Second, how does the VMM react to insufficient physical or virtual (page file) memory? By throwing a system error, not "can't access a handle in a DLL". OK, so windows VMM isn't as effective as the YUKS (Linux and the rest of the band) platforms. So, it will either throw a system error, e.g. "out of memory", or crash. The "can't access a handle in a dll is clearly an applications level error", not a system error. I'm not a codee, I'm an electrical engineer and my experience with the windows VMM is from pivoting multi-gigabyte matrices in SPICE. I have generated many "out of memory" errors, particularly in WinXP as it can only have (nearly) 4GB of physical memory. This is doubly true when you allow Windows to manage virtual memory, as I do, because it will increase virtual memory as needed. Limited by available disk space, of course. And when it works correctly.
The "can't access a handle in a DLL", message is not coming from the memory manager. The structure of the DLL is to have a table of calls mapping the called routine name to an offset in memory of the called routine. It is, essentially indirect. If the contents of the table contains an incorrect offset, you will get a page fault. The "can't access a handle in a DLL", is coming from the indirect lookup code, saying it can't find the requested routine in the lookup table, not that it couldn't find it in memory. Also, again, the Windows memory manager isn't as shiny as the YUKS one, so accessing forbidden memory, will generate a page fault, or send Windows into the weeds, not a courteous "I can't find that, please try again". Nevertheless, the missing handle exception returned by the Qt6Widget lookup should propagate back to the calling routine, allowing it to be captured and documented...
Third, as I've already documented when Cura > 5.4.0 starts and crashes, it does not create either a version folder or either log file in %appdata%\Cura. If it did, I would have already appended it like a I did for 5.3.1. Any log file at all would help, as I have no idea where the problem is occurring, although it appears to be in the painfully slow interpreted loading of all the different printer profiles. As an aside, why aren't these loaded as needed, life is short enough, it takes forever, even on my I7 laptop?
It is worth noting that after invocation the spinner comes up for a few seconds, then goes away, and it is 10 or 15 seconds before the error appears. So, this fault isn't occurring at init, yet *there are no log files generated* (or application version folder in %appdata%\Cura), this is what is baffling me. The missing handle error is coming from Qt6Widgets.dll, which for some reason is in two places in the application directory, instead of the GAC, where it belongs. Cura 5.3.1 uses version 6.2.4.0, Cura 5.7.0 uses version 6.6.0.0. I would of thought that this DLL contains the "controls" used in the UI, which doesn't come up until after the printer profiles are loaded?
I'm wrong about Python, as you say, but without a log file of any kind, what choice do I have to troubleshoot but change things until I get a response? So, I repeat is there a command line switch to enable logging, 'cuz *nothing* is created for versions > 5.4.0, full stop. I could attach a debugger, but generally the messages to the debugger are generated in the same exception handler that logs them, so...
Finally, I installed Cura 5.7.0 on the Z83, and before starting it copied the entire application (application and %appdata%\Cura folders) from my laptop, also running Win 10 Home 64b, and where it runs successfully, to the Z83. The results where exactly the same. So, there is either a difference between the WinPE version of Win10 Home 64b running on the Z83 and the mundane Win10 Home 64b running on my laptop, or something, external to the Cura installation is missing from the Z83. Perhaps I should dismount from Rocinante, but I very much doubt this is a memory problem, which wouldn't prevent logging until lights out.
Also, Cura is installed for the *current* user, not all users. Consequently, if started by a remote desktop session, it will stop if the remote desktop session is lost even for a second. "All users" is a built in choice in the windows installer, and presented by default, and it should be up to the user to decide which to use. And if not, it should be "all users", allowing disconnect from the remote desktop without affecting Cura.
Please don't go after community members.
They are only offering help.
It sounds like you feel you have found bugs in UltiMaker Cura, this needs to be reported via github not via ranting at community members on the community forum.
Report bugs here: https://github.com/Ultimaker/Cura/issues
Additionally it appears your issue relates to remote desktop? that isn't even officially supported or recommended by UltiMaker.
Details here: https://support.ultimaker.com/s/article/1667337917781
I apologize for my stridency, it was not intended to "go after" anyone.
But correcting me without understanding the platform in question was 'going after' me. Especially since the my original comment on Iron Python wasn't germane to the problem, it was intended to forestall any questions about my ineptitude in Python coding.
Also, telling me that logging was on by default, when my original post said that no log files were created, meant that the original post wasn't read, completely, before commenting.
And lastly, I have reported all these issues, and more, on Github. I document them, and a few days later they are closed, because "further or requested information wasn't received". This has happened several times, so I despair of that path for a remedy.
I have never had to do anything special, other than install the app for "all users", to make it it work with remote desktop. So as far as I know neither explicit support nor recommendation is required from Cura to make it compatible with remote desktop. And in fact, it works fine with remote desktop, as long as the remote desktop link isn't disturbed *at all*.
I do note that the installer doesn't ask if it should be installed for the current or all users, and it should, or default to all users. This is a default option presented by the Windows installer, YMMV for other installers. By the bye, I also reported that to Github, and it was "closed because further information wasn't provided".
I also reported that USB connection to the printer isn't consistent. I was told USB connection wasn't supported, and the issue closed. In Windows, Device cataloging, departure and arrival via the GUID is robust, so the above response is opaque.
For me remote desktop access is driven by a physical disability and access to the 3D printer. It really isn't an option for me not to use remote desktop, hence the reason I'm so eager to get it working on the Z83. Again.
ArunC posted a topic in UltiMaker Cura,
.thumb.jpeg.0b7a05eafc09add17b8338efde5852e9.jpeg)
Dustin posted a topic in Firmware,
Recommended Posts
Top Posters In This Topic
12
11
6
5
Popular Days
Dec 21
7
Apr 24
5
Apr 25
4
Apr 27
4
Top Posters In This Topic
ghbarbehenn 12 posts
Slashee_the_Cow 11 posts
DivingDuck 6 posts
ahoeben 5 posts
Popular Days
Dec 21 2023
7 posts
Apr 24 2024
5 posts
Apr 25 2022
4 posts
Apr 27 2024
4 posts
Popular Posts
ahoeben
It would be really helpful if you could let us know what installation directory you used previously (which did not work) and what you changed it to (so it now works correctly). That way we might be ab
Burgerpower01
Hi, I also ran into the issue where Cura would open with a white screen and be stuck on my Windows 11 PC. I had no issues previously. I am using Cura Version 5.5.0 To resolve this issue, I had to
Slashee_the_Cow
I'm not really up on my Polish, but for those who are a little less up to date than me: that's in the Windows settings somewhere (I'm not sure where exactly because I don't have a laptop with discrete
Posted Images
ahoeben 1,951
It is NOT NECESSARY to delete the cura.cfg file if you disable all except one display!
Removing that file will cause Cura to go through its initial setup wizard when you start Cura again.
Link to post
Share on other sites