Closed damienraven closed 4 years ago
Did you already try running Cura in compatibility mode? We've had some reports that this might fix it.
Hey @damienraven,
Thanks for reporting this issue. We've, indeed, encountered this issue for some time now. But what is interesting in your ticket is the fact that the splash screen is a black square. As a result, it would be really great if you could fill in the below template, so that you could help us determine whether your issue is different from what we've already seen so far.
Cura setup:
Identification of the issue:
Question: Does the Cura splash screen appear? Is this behavior consistent? Please send us a screenshot of the splash screen - if applicable. Answer:
Question: Does the Cura.exe process appear in the "Background Processes" list in the Windows Task Manager (Ctrl + Shift + Esc)? Answer:
If the answer to the above question is 'Yes', please create a dump file from Task Manager. To do so:
a) Locate the Cura.exe process in the "Background Processes" list;
b) Right click on the process;
c) Select "Create dump file";
d) Once the dumping process has been completed, a window will appear that will display the path where the dump file has been saved to. Since it will be quite large, please compress it and send it to us. This will assist us in determining during which call the application actually halts.
Question: Is the stderr.log file blank or does it contain some logs already? This logfile is located in %appdata%\cura (you can paste this path on Windows Explorer). In case the logfile is not blank please send it to us. Answer:
Question: Does Cura start when running in Compatibility mode (i.e., right click on the Cura.exe file → Properties → Compatibility tab → Check the "Run this program in compatibility mode for:" checkbox → Select Windows 8 from the dropdown list)? Answer:
Did you already try running Cura in compatibility mode?
For clarification, "compatibility mode" here means Windows 8 compatibility mode.
Hi, I have the same Problem, but CuraCLI.exe won't work either.
Application version 4.4, 4.3, 4.2 and 4.4 from chocolatey
Platform Thinkpad X1 Yoga gen. 3 with MS Windows 10 x64, version 1909, build 18363.476
DxDiag.txt (File removed Dec. 2020)
Printer Marlin bugfix-2.0.x - not connected
Reproduction steps Run Cura.exe or CuraCLI.exe as User or Administrator, with or without compatibility mode (W8). Cura freezes while starting, sometimes the black box doesn't appear but the icon in the taskbar appears always for a second or so.
Actual results Cura.exe or CuraCLI.exe: Black splash box.
When I run CuraCLI.exe I get the following.
PS C:\Program Files\Ultimaker Cura 4.4> .\CuraCLI.exe
[MainThread] UM.Qt.QtApplication.__init__ [78]: Adding QT5 plugin path: C:\Program Files\Ultimaker Cura 4.4\PyQt5\plugins
[MainThread] UM.Qt.QtApplication.__init__ [88]: Adding QT5 plugin path: C:\Program Files\Ultimaker Cura 4.4\PyQt5\plugins
[MainThread] UM.Resources.__initializeStoragePaths [417]: Initializing storage paths
[MainThread] UM.Resources.__initializeStoragePaths [427]: Config storage path is C:\Users\Michael\AppData\Roaming\cura\4.4
[MainThread] UM.Resources.__initializeStoragePaths [435]: Data storage path is C:\Users\Michael\AppData\Roaming\cura\4.4[MainThread] UM.Resources.__initializeStoragePaths [447]: Cache storage path is C:\Users\Michael\AppData\Local\cura\4.4\cache
[MainThread] UM.PackageManager.__init__ [52]: Found bundled packages JSON file: C:\Program Files\Ultimaker Cura 4.4\resources\bundled_packages\cura.json
[MainThread] UM.PackageManager.__init__ [52]: Found bundled packages JSON file: C:\Program Files\Ultimaker Cura 4.4\resources\bundled_packages\uranium.json
[MainThread] UM.View.GL.OpenGLContext.detectBestOpenGLVersion [105]: Trying OpenGL context 4.1...
[MainThread] UM.View.GL.OpenGLContext.detectBestOpenGLVersion [115]: Yay, we got at least OpenGL 4.1 core: 4.1 Core profile
[MainThread] UM.View.GL.OpenGLContext.detectBestOpenGLVersion [162]: OpenGL renderer type for this OpenGL version: Intel(R) UHD Graphics 620
[MainThread] UM.Qt.QtApplication.initialize [142]: Detected most suitable OpenGL context version: 4.1 Core profile
[MainThread] UM.Qt.QtApplication.initialize [149]: Initializing job queue ...
[MainThread] UM.Qt.QtApplication.initialize [153]: Initializing version upgrade manager ...
C:\Users\MYUSERNAME\AppData\Roaming\cura... .\stderr.log and.\stdout.log are empty, the .\4.4\plugins directory is empty.
Cura.exe or CuraCLI.exe can only be closed by killing them with the TaskManager.
Expected results No freeze.
Identification of the issue:
Question: Does the Cura splash screen appear? Is this behavior consistent? Please send us a screenshot of the splash screen - if applicable. Answer: No: Sometimes the black box doesn't appear but the icon in the taskbar appears always for a second or so.
Question: Does the Cura.exe process appear in the "Background Processes" list in the Windows Task Manager (Ctrl + Shift + Esc)? Answer:
Yes it appears as Background Processes
If the answer to the above question is 'Yes', please create a dump file from Task Manager. To do so: a) Locate the Cura.exe process in the "Background Processes" list; b) Right click on the process; c) Select "Create dump file"; d) Once the dumping process has been completed, a window will appear that will display the path where the dump file has been saved to. Since it will be quite large, please compress it and send it to us. This will assist us in determining during which call the application actually halts.
Yes, sure. (Compressed with 7z)
Cura_dump.7z (File removed Dec. 2020)
Question: Is the stderr.log file blank or does it contain some logs already? This log file is located in %appdata%\cura (you can paste this path on Windows Explorer). In case the log file is not blank please send it to us. Answer:
blank, but exists
Question: Does Cura start when running in Compatibility mode (i.e., right click on the Cura.exe file → Properties → Compatibility tab → Check the "Run this program in compatibility mode for:" checkbox → Select Windows 8 from the dropdown list)? Answer:
Doesn't change anything.
I had a similar problem. I was getting the splash screen every time, but stuck at "initilizing package manager...". I tried the Win8 compatibility, no change. Logs were empty. Cura_Cli was hanging after the loading of uranium.json. Then i noticed that there was a cura.lock file always present, even with Cura closed. I deleted it, et voila', Cura loaded.
The lock file should get ignored after 10 seconds of waiting on it.
Can confirm, same results here on Win10 Education 1903. Trying to deploy to a classroom lab and the application just hangs. Changing the Compatibility Mode for "C:\Program Files\Ultimaker Cura 4.4\Cura.exe" to Windows 8 does seem to resolve the issue.
I tried to run cura.exe --debug in PS and CMD (cura 4.4 from chocolatey). I got a crash report with an error trackback:
Traceback (most recent call last):
File "<frozen importlib._bootstrap>", line 968, in _find_and_load
File "<frozen importlib._bootstrap>", line 957, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 664, in _load_unlocked
File "<frozen importlib._bootstrap>", line 634, in _load_backward_compatible
File "__startup__.py", line 12, in <module>
File "<frozen importlib._bootstrap>", line 968, in _find_and_load
File "<frozen importlib._bootstrap>", line 957, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 664, in _load_unlocked
File "<frozen importlib._bootstrap>", line 634, in _load_backward_compatible
File "Console.py", line 24, in <module>
File "X:\4.4-exe\build\inst\bin\cura_app.py", line 137, in <module>
RuntimeError: sys.stderr is None
and the logs:
Current thread 0x00000b18 (most recent call first):
File "X:\4.4-exe\build\inst\lib\python3.5\site-packages\cura\CrashHandler.py", line 306 in _logInfoWidget
File "X:\4.4-exe\build\inst\lib\python3.5\site-packages\cura\CrashHandler.py", line 156 in _createDialog
File "X:\4.4-exe\build\inst\lib\python3.5\site-packages\cura\CrashHandler.py", line 77 in __init__
File "X:\4.4-exe\build\inst\bin\cura_app.py", line 123 in exceptHook
I looked into that line (only on gh)
if sys.stderr: # Trackback says sys.stderr = None
faulthandler.enable(file = sys.stderr, all_threads = True)
else:
faulthandler.enable(file = sys.stdout, all_threads = True) # Write should go to stdout insted.
I also tried to run an unknown arg (--asdf). Now I got an output in stderr.log and stdout.log in:
C:\Users\MYUSERNAME\AppData\Roaming\cura
stdout.log
[MainThread] UM.Qt.QtApplication.__init__ [78]: Adding QT5 plugin path: C:\Program Files\Ultimaker Cura 4.4\PyQt5\plugins
[MainThread] UM.Qt.QtApplication.__init__ [88]: Adding QT5 plugin path: C:\Program Files\Ultimaker Cura 4.4\PyQt5\plugins
stderr.log
usage: cura [--version] [--external-backend] [--headless] [--debug]
[-qmljsdebugger QMLJSDEBUGGER] [--help] [--single-instance]
[--trigger-early-crash]
[file [file ...]]
cura: error: unrecognized arguments: --asdf
... but not in console. Maybe intended? Maybe crash report problem related? I haven't had any time to dig into.
I looked into that line (only on gh)
Huh, that's weird. So it checks if sys.stderr
, which passes, but then still crashes on sys.stderr
being None
one line later? I think the version on Chocolatey is then outdated, because this code changed on October 25th. Can you try with our own release here on Github?
Tried it with "Ultimaker.Cura-4.4.0-win64.exe" from the gh releases. Exactly the same result.
What also makes me curious: sys.stderr is None
. I have never worked with an embedded version of Python but PS and CMD have a stderr stream:
import sys
import locale
print(f'{sys.version=}')
print(f'{sys.version_info=}')
print(f'{locale.getpreferredencoding()=}')
print(f'{sys.stderr.isatty()=}')
print(f'{sys.stderr.mode=}')
print(sys.stderr)
assert(sys.__stderr__ == sys.stderr)
print("Error 418: I'm a teapot", file=sys.stderr)
results in:
PS C:\Users\MYUSERNAME\Desktop> python .\test.py
sys.version='3.8.0 (tags/v3.8.0:fa919fd, Oct 14 2019, 19:37:50) [MSC v.1916 64 bit (AMD64)]'
sys.version_info=sys.version_info(major=3, minor=8, micro=0, releaselevel='final', serial=0)
locale.getpreferredencoding()='cp1252'
sys.stderr.isatty()=True
sys.stderr.mode='w'
<_io.TextIOWrapper name='<stderr>' mode='w' encoding='utf-8'>
Error 418: I'm a teapot
I'm sure python 3.5 should work as well.
// edit
Okay... on a VM on the same machine with the same version of W10 cura works flawlessly. But running Cura.exe --debug results in the same problem. Maybe the --debug is only for running from source.
// edit 2
On the same machine on arch linux community/cura 4.3.0-2
has no problems with the --debug, but on another W10x64 machine, where cura works as intended, with different hardware, but same configuration/software/Windows version the same error happens. I think, that's entirely a different issue.
// edit 3
Ah, ok on arch it runs from source.
FYI --debug works fine when running the AppImage (i.e. not from source) based on the current master branches.
Our beta releases are built to run with --debug
, so you'd see the problem there too.
Let's see. I finally had the same issue again (last time I checked this thread I tried to start Cura from Windows Menu and had no issues, so I haven't a report to make).
Cura setup:
Version where you first encountered the issue: [Please enter the Cura version where the issue was first observed] In a more recurring issue, this happened on 4.4.0, but sometimes happened on 4.3.0 as well.
Version(s) where the issue did not exist (if applicable): [Please enter the Cura version(s) where the issue was not happening] At 4.3 worked fine in most of the cases. Before these versions, I never had any problem like this.
Identification of the issue:
Question: Does the Cura splash screen appear? Is this behavior consistent? Please send us a screenshot of the splash screen - if applicable. Answer:
Question: Does the Cura.exe process appear in the "Background Processes" list in the Windows Task Manager (Ctrl + Shift + Esc)? Answer: This also can be seen on the screenshot I already attached.
If the answer to the above question is 'Yes', please create a dump file from Task Manager. To do so: a) Locate the Cura.exe process in the "Background Processes" list; b) Right click on the process; c) Select "Create dump file"; d) Once the dumping process has been completed, a window will appear that will display the path where the dump file has been saved to. Since it will be quite large, please compress it and send it to us. This will assist us in determining during which call the application actually halts.
Answer: This created a 400Mb file. I have compressed (a single 7z file around 90Mb) and shared by the dropbox link below (it will expire on 15/03/2020). https://www.dropbox.com/transfer/AAAAAGUQvqP-V7o5JeszdupnX4XUeAxtLN70oOYQnS3W7YWEJ3Op92s
Question: Is the stderr.log file blank or does it contain some logs already? This logfile is located in %appdata%\cura (you can paste this path on Windows Explorer). In case the logfile is not blank please send it to us. Answer: Both files are blank (stderr.log and stdout.log).
Question: Does Cura start when running in Compatibility mode (i.e., right click on the Cura.exe file → Properties → Compatibility tab → Check the "Run this program in compatibility mode for:" checkbox → Select Windows 8 from the dropdown list)? Answer: No, results on the same result as if not on compatibility mode.
Hi,
I have exactly the same problem, with 3.4 version and after.
Actual version and config:
Application version 4.4.0
Platform Windows 10 Pro 64 bits, 12Gb RAM and Nvidia GeForce GTX 970 with driver 442.19 (most recent). The windows firewall is disabled and also the Cura.exe is on the Allowed list.
We've attempted some fixes for this in Cura 4.5. You can try running that version.
We've also added an additional configuration setting. Since there is no interface to allow you to change it, you can only edit this in the configuration file. You'd go to C:\Users\<username>\AppData\Roaming\cura\4.5
and open the file cura.cfg
with a text editor. In there, under the header [view]
you can add the following line:
opengl_version_detect = force_modern
Can you try that and see if that works for you?
Hello,
Trying to install 4.5 version and start = freeze
Add "opengl_version_detect = force_modern" and start freeze too
Edit: Upgrade video driver to 442.50 (02/27/2020) and reboot, start cura and it's okay ! :)
Trying again to use tomorrow, i feedback you.
Edit2: Works only one time, after close and open freeze again :/
Thanks for help
Hello,
Works after re-install Windows 10.
Regards
If this is an already reported issue, I'm sorry. I can't find anything that is really like this. Application version 4.4.0
Platform Windows 10 Pro 64 bits, 16Gb RAM and Nvidia GeForce GTX 970 with driver 441.41 (most recent, launched on 11/26/2019). The windows firewall is disabled and also the Cura.exe is on the Allowed list.
Printer Movtech 400 Smart (but I think that this doesn`t matter)
Reproduction steps
Actual results Cura doesn`t start unless using CuraCLI.exe
Expected results Cura starts using Cura.exe and the Start Menu icon.
Additional information When launching Cura from the start menu or the Cura.exe it writes nothing on the Cura.log file. The file attached is written when launched on the CuraCLI.exe. cura.log