Cura: [4.2.1] Cura won't start on firsts attemps

[bvalat]

Application version
4.2.1

Platform
WIN 10 64

Printer
Ender 3

Reproduction steps
Try to start Cura

Actual results
Cura process is here but it hangs and stays at around 54MB

Expected results
Cura starts

Additional information
Happens after PC boot/reboot.
If i launch it several times it finishes to launch.
Once one successful start, i can close/start it several times without any issue.
Once i get it launched it works.
Was discovered during #6152
Since #6152 was a plain crash on a plugin load, i open this one for "just hanging" on some starts.

[bvalat]

[LipuFei]

@bvalat Could you try only starting one Cura instance see if it hangs?

[Routout]

I managed to replicate this. After reboot of windows Cura starts at third try. I kill the process twice from task manager. Tested three times, and always the same behaviour. After this cura starts normally. But again after reboot same thing.
But I couldnt find anything from event viewer or cura logs.

[bvalat]

I forgot to tell what you are seeing on my screenshot.
I booted my pc and started a cura process untill one shows the loading screen.
Those which hang do not display anything and the stderr et stdout are empty (0KB)

[bvalat]

The problem is that when it hangs, there is no log or starting screen.
Just the cura process go up to ~60Mb and then fall back to ~54-53mb and stays that way.
But if i launch it several times it finishes to launch.

[bvalat]

If i launch curacli.exe it hangs there :
`[MainThread] UM.Qt.QtApplication.__init__ [77]: Adding QT5 plugin path: C:\Program Files\Ultimaker Cura 4.2\PyQt5\plugins

[Ghostkeeper]

@Ellecross has seen this on their computer as well.

[Ellecross]

Yeah I've been seeing this the whole day yesterday, but now I'm showing it to @rburema it doesn't occur. :> It's having the presence of a developer around you that makes stuff work. Heh. I'll keep an eye out for this.

[bvalat]

For me it's not working after a fresh boot.
After launching multiples instances and getting one working, if i kill them all and relaunch, it still works.

[lexcyn]

On my desktop, this is not an issue, only my laptop. The workaround is to set the shortcut to Cura with Windows 8 compatibility and it will start first try.

[LipuFei]

@bvalat If you agree, for one of the Cura.exe that hangs and does nothing, could you create a crash dump of that process and send the crash dump file to us? You can use the follow email addresses:

• l.[email protected]
• [email protected]

This GIF shows you how to create a crash dump using the Task Manager.

I cannot reproduce this problem, so the only thing I can think of is to inspect that staled process see what's going on. Thanks!

[bvalat]

Mail sent with dump.
I can confirm that enabling win8 compatibility mode is avoiding hanging.
If i disable it after this fist launch, cura is working fine without it.
So it's realy a first launch success problem.
I manage to launch it without win8 by slowing my computer down.
I think there is a race condition somewhere.
Maybe on packages.json wich is read and written just before hanging.

[Ghostkeeper]

@LipuFei the software-cura address can't be reached from externals. Only @ultimaker.com addresses can send to it. And that's a good thing since it would spam our entire team.

[LipuFei]

Hi @bvalat Thank you for the process dump!

I did find a few things, but I still have no clue why this happens. I'll write a summary of my findings below, at least to provide more information.

The first image is the debugging info in WinDbg for your process dump. First you can see that the main thread is blocked on ntdll!NtWaitForSingleObject but I don't know which object because I couldn't get the symbols working for ntdll. Before this happened, it was trying to load a DLL library file, which is also a Qt plugin, which was originally triggered by trying to create a QPixmap.

Then, I used VS2017 to figure out which files it was trying to load (see the second screenshot). So, I found that:

• The DLL it tries to load is imageformat\qgif.dll in the Cura installation folder. This is Qt's library for handling GIF files.
• From the third screenshot, you can see that the QPixmap is trying to load cura.png from the Cura installation folder.

The cura.png file is loaded when Cura tries to create the splash window (see code link below), and the stack trace from the process dump seems to agree with this. This also explains that on your laptops/PCs, when Cura hangs, there's no splash window at all. Because the splash window couldn't finish being created.

I also haven't found out why using the Windows 8 Compatibility Mode helps.

@bvalat You could try using Process Explorer to find out which processes occupy certain files. You can use the menu "Find" -> "Find Handle or DLL" to do that. I have also attached a GIF at the bottom on how to do this.

https://github.com/Ultimaker/Cura/blob/362c7d09fb290e00de0e03ca64ebb4ea9f27e3ff/cura/UI/CuraSplashScreen.py#L12-L18

[bvalat]

I thing it's an heisenbug.
I tried to launch Cura with windbg (open process and go) and it works every-time....

[LipuFei]

@bvalat Sounds like a timing issue or a race condition. If you launch it normally now, does it work? If it gets stuck, could you try to fetch the stack trace from the main thread with WinDbg see what's going on?

[LipuFei]

Hi @bvalat , I'll close this issue for now. We need more information in order to do something with it. You can reopen the issue if the problem still persists for you.

[SkillfulHacking]

I'm having this issue as well, I have created a core dump of the process and wondering if you would like to take a look at it? Cura loads up and displays splash screen but it hangs loading the main interface with a white screen. This is my second time using this version, the first time it loaded fine, I sliced a few files and then loaded an stl that was too large for the build plate so I scaled it down to 10% after scaling the app hung and it never placed the object on the build plate.

[rburema]

Could you attach the dump? github will accept zipped files (or files renamed zip)

[SkillfulHacking]

Unfortunately they only allow 10mb attachment, compressed this one is 191 MB, decompressed 342 MB, also I tried starting in win 8 compatibility mode no dice.

[rburema]

Yeah it's a bit inconvenient ... Please put it somewhere (WeTransfer for instance), then mail the link to one of us (for example: r.burema/ultimaker/com -- replace slashes with the relevant glyphs).

[SkillfulHacking]

https://drive.google.com/file/d/1DgkZNT4iB9Lf1iK5BHqbEOMwGt5xWl2l/view?usp=sharing

[SkillfulHacking]

Mine seems to hang after loading shader files, when I run with windbg the last thing loaded was the nvidia dlls, I updated to the latest version of the driver/rebooted and experienced the same issue.

[SkillfulHacking]

[Ghostkeeper]

We've been trying to trace this down as well since it started happening for one of our QA engineers.

Thanks for the dump. That'll be very useful. Our current suspicion is that it has something to do with the network connection (maybe checking for updates?) and every network is different.

[LipuFei]

@SkillfulHacking Thanks for the DMP file! I think it has something to do with the graphics card driver and the attached monitors maybe.

[SkillfulHacking]

The monitor was a good lead, I disconnected my second monitor and rebooted, the application was able to load on my primary display. Not sure what the technical cause is but here is some additional information on my setup:
1080TI GPU
Primary display: Samsung QLED LC27FG73FQNXZA running at 144hz
Secondary display: Asus VS248 running at 60hz.

For some reason (last time I used it I moved to 2nd display) it kept trying to load on the secondary display. if this happens in the future is there a way I can force it to load on the primary display(without unhooking the 2nd monitor)?

[fieldOfView]

In %APPDATA%\cura\4.2\Cura.cfg, in the [general] section, remove the lines starting with window_left and window_top

[LipuFei]

The monitor was a good lead, I disconnected my second monitor and rebooted, the application was able to load on my primary display. Not sure what the technical cause is but here is some additional information on my setup:
1080TI GPU
Primary display: Samsung QLED LC27FG73FQNXZA running at 144hz
Secondary display: Asus VS248 running at 60hz.

For some reason (last time I used it I moved to 2nd display) it kept trying to load on the secondary display. if this happens in the future is there a way I can force it to load on the primary display(without unhooking the 2nd monitor)?

Hi @SkillfulHacking , are both your primary and secondary monitors connected to the same graphics card (NVIDIA) or different cards (for example, the 2nd one connected to the integrated Intels card)?

[SkillfulHacking]

Yes both are connected to the same graphics card, there is also a 3rd display attached, which is my oculus rift but that has not been turned on for a few days.

[rburema]

If they (oculus) still use the same sort of methods as with the (2nd) development kit, all bets are off. They (their drivers/software) did some pretty invasive stuff to the point that it broke my windows install / the BIOS a couple of times when I tried to set it up first. Even after I got it to work, my installation of windows was still unstable.

[Routout]

This problem still persists at 4.3. Only way to start Cura reliable is to run it in Win8 compatibility mode.
Normal mode I have to kill cura.exe several times before it will run.

[smartavionics]

FYI see https://community.ultimaker.com/topic/29797-experimental-windows-cura-build-based-on-pyqt-513/ maybe it's worth trying?

[Routout]

FYI see https://community.ultimaker.com/topic/29797-experimental-windows-cura-build-based-on-pyqt-513/ maybe it's worth trying?

Unfourtunately this failed to start also. Tried ver Cura-mb-master-win64-20191012

[smartavionics]

Hello @Routout , thanks for the feedback, sorry it didn't fix your problem.

[fixeditall]

I fixed it. It's just a problem with the windows firewall and AVG antivirus preventing the first launch of the program. This explains how to fix it. This fix should work for multiple versions. Pass this on to the development team. http://embscomputerart.com/fixing-cura-4-3-0/

[rburema]

@fixeditall We suspect most(??) of the remaining startup problems are firewall related, it's good to see some confirmation 'in the wild'. (For anyone wondering: The connection from the qt/python frontend to the c++ backend works via a port on localhost.)

[Routout]

Now startup screen stays on with Cura 4.4, with earlier versions it disappeared. It hangs on loading plugins.

[rburema]

@Routout The splash screen means we should have some logs at least; can you send those to us? They should be in %appdata%\cura\4.4

[Routout]

Unfourtenately nothing on cura.log until Cura starts properly after 3-4 tries.

[Ghostkeeper]

Pass this on to the development team. http://embscomputerart.com/fixing-cura-4-3-0/

Should be noted that CuraCLI.exe is not used by Cura except by some of the plug-ins for CAD integration in the marketplace, so that is probably unnecessary to make an exception for in your firewall.

Since a firewall on your computer is blocking Cura from doing anything, there is not much that we can add to our code to fix this problem. Everything we add is just not going to be ran because the firewall blocks it. There are only 2 things we can really do:

• Negotiate with AVG to have them make an exception in their software. I wouldn't know how to start contact with them though.
• Figure out why AVG triggers on Cura. I think it's the local socket connection though that they think is scary, so it's a major design change for us to call CuraEngine in a different way and we probably won't want to do this for just a false positive in some software that people are running alongside Cura.

[LipuFei]

Hi all, we have created a Cura build with Qt 5.14. It uses the latest code base. Could you help us to test it? Thanks!

Link: https://we.tl/t-hkA0yVK9n1

[Routout]

4.5.99 gives me this error when I'm trying to run it.

[LipuFei]

Hi @Routout , there's still some issue with packaging Qt 5.14. We will upload another installer when they are resolved.

[smartavionics]

Hi @LipuFei , FYI, this is what I am currently using for Qt 5.13 and the current master sources...

diff --git a/packaging/setup_win32.py.in b/packaging/setup_win32.py.in
index 2889b0d..ef17a84 100644
--- a/packaging/setup_win32.py.in
+++ b/packaging/setup_win32.py.in
@@ -86,6 +86,15 @@ def load_pyqt5_qtquick(finder, module):
     finder.IncludeModule("PyQt5._QOpenGLFunctions_2_0")
     finder.IncludeModule("PyQt5._QOpenGLFunctions_2_1")
     finder.IncludeModule("PyQt5._QOpenGLFunctions_4_1_Core")
+    finder.IncludeModule("PyQt5.sip")
+    qt_path = os.path.join(os.path.dirname(PyQt5.QtCore.__file__), "Qt", "bin")
+    required_qt_dlls = [
+        "Qt5Quick.dll",
+        "Qt5QuickTemplates2.dll",
+        "Qt5QuickControls2.dll",
+    ]
+    for file_name in required_qt_dlls:
+        finder.IncludeFiles(os.path.join(qt_path, file_name), file_name)

 hooks.load_PyQt5_QtQuick = load_pyqt5_qtquick

@@ -96,6 +105,8 @@ def load_pyqt5_qtnetwork(finder, module):
     required_ssl_files = [
         "libeay32.dll",
         "ssleay32.dll",
+        "libcrypto-1_1-x64.dll",
+        "libssl-1_1-x64.dll",
     ]
     for file_name in required_ssl_files:
         finder.IncludeFiles(os.path.join(qt_path, file_name), file_name)
@@ -115,7 +126,7 @@ hooks.load_shapely = load_shapely

 search_path = sys.path.copy()
 search_path.insert(1, "@EXTERNALPROJECT_INSTALL_PREFIX@/lib/python3.5/site-packages/")
-search_path.insert(2, "@CMAKE_PREFIX_PATH@/lib/python3.5/site-packages/")
+search_path.insert(2, "@CMAKE_PREFIX_PATH@/lib/site-packages/")

 # Dependencies are automatically detected, but it might need
 # fine tuning.
@@ -132,6 +143,7 @@ build_options = {
         "uuid",
         "serial",
         "zeroconf",
+        "netifaces",
         "requests",
         "idna",
         "UM",

[smartavionics]

And cura_app.py is also modded...

diff --git a/cura_app.py b/cura_app.py
index cb9779266..5675b4d57 100755
--- a/cura_app.py
+++ b/cura_app.py
@@ -12,6 +12,15 @@ from UM.Platform import Platform
 from cura import ApplicationMetadata
 from cura.ApplicationMetadata import CuraAppName

+if Platform.isWindows() and hasattr(sys, "frozen"):
+    DIR_NAME = os.path.dirname(sys.executable)
+    # add DIR_NAME and DIR_NAME/lib to the path so DLLs can be found
+    paths = os.environ.get("PATH", "").split(os.pathsep)
+    if DIR_NAME not in paths:
+        paths.insert(0, os.path.join(DIR_NAME, "lib"))
+        paths.insert(0, DIR_NAME)
+        os.environ["PATH"] = os.pathsep.join(paths)
+
 try:
     import sentry_sdk
     with_sentry_sdk = True
@@ -156,9 +165,9 @@ def exceptHook(hook_type, value, traceback):
 # Set exception hook to use the crash dialog handler
 sys.excepthook = exceptHook
 # Enable dumping traceback for all threads
-if sys.stderr:
+if sys.stderr and not sys.stderr.closed:
     faulthandler.enable(file = sys.stderr, all_threads = True)
-else:
+elif sys.stdout and not sys.stdout.closed:
     faulthandler.enable(file = sys.stdout, all_threads = True)

[LipuFei]

Hi all, here is a new Cura build with Qt 5.14 and the latest code base. Could you try it out?

Download link: https://we.tl/t-ooy6ZecsI1

[LipuFei]

@smartavionics FYI, with the changes you mentioned above, one DLL was missing for PyQt 5.14: Qt5QmlModels.dll

[smartavionics]

OK, thanks. That must be new for 5.14.

[flackwell]

Father Christmas brought me a 3d printer, so I installed Cura 4.4 on Win10. It ran fine for 10 days or so, then just when I was getting used to it and liking it, it started hanging at startup. The splash screen displays, it says "Updating configuration" (usually), or sometimes "loading plugins", then nothing.

I read this thread and others on github and Ultimaker. I've tried everything suggested in these - uninstalling and reinstalling, Win8 compatibility mode, configuring Windows firewall, deleting the lock file (there has never been one in my case). They all seem to get it going - once - but after shutting down the PC and reloading Windows Cura is back to hanging at startup again. So I'm not sure that any of these alleged fixes actually works; whether or not it starts seems to me to be random, and the fact that is starts after implementing one or other of them may just be coincidence.

I'm not a developer any more, I don't think I can add any new information, but I thought I would post this just to point out that more of us than just the few people on these threads are affected. This issue has been ongoing for a long time now, and needs sorting. So far I've eventually managed to get Cura to run when I've needed it, but sometimes it takes 15 mins or so pratting, and there is a limit to how long I will tolerate this before I give up and start using a different slicer.

[fieldOfView]

Without logs, error messages and a description of your hardware (what gpu, what sort of screen setup) and installed software (antivirus, firewall). there is really little that we can do to help.

[flackwell]

OK, sorry for being a bit grumpy on my first post. I am willing to help if I can, but fear that I can't add much. Trawling through the internet shows multiple threads discussing what appear to be this problem (5348, 6732 and this one on Github, several others on the Ultimaker site. It seems to go back at least to version 3.6.0 in Feb 2019 (see https://community.ultimaker.com/topic/26019-bug-cura-360-hangs-at-launch/). There is a comment further up this thread (by Ghostkeeper, 4 Dec 2019) that seems to imply that you are taking the view that it's a corner case involving a specific software combination, which you are unlikely to bother to fix. I wanted to make the point that it may be more general than that - I don't run AVG antivirus.

To answer your questions: my PC setup is very out-of-the-box and vanilla. Graphics: Intel HD Graphics 630, GPU Kaby Lake GT2. I attach a cpu-z listing of my hardware; if that isn't enough detail for you, you'll have to tell me how to get more. The listed monitor 0 is not currently connected and has not been at any time that I've tried to run Cura.

Software: Windows 10 Home, version 1809, OS build 17763.864. Windows firewall is enabled, and unmodified apart from the tweak referenced in fixeditall's post on 17 Nov 2019. Antivirus software Avast program version 19.8.2393 (build 19.8.4793.547), virus definitions 200111-0. These all update on the fly, so may change or have changed. I have tried disabling both the firewall and the antivirus without success. Cura version 4.4.1., currently running in compatibility mode for Win 7 (because Win 8 compatibility mode stopped being effective, if it ever was in the first place).

Logs: when it hangs I have never found a stdout.log or stderr.log with a size greater than zero. There has never been a lock file. Also you always seem to say (eg on 5348) that the logs don't contain any useful diagnostics for this problem, so there didn't seem any point.

Error messages: none, it just hangs.

Generally the symptoms seem inconsistent and not reproducible. The only pattern I can discern is that once Cura has loaded OK, it will continue to do so if closed down and then relaunched on the same Windows session. But once the machine has been powered down and rebooted, all bets are off.

M4-WIN10.zip

[Routout]

I just tested different versions and for me 4.1.0 is the first one with this problem. 4.0.0 runs well even after reboot.

[Routout]

Test version have still this startup problem, and main window doesn't open at all when cura starts after multiple tries.
cura.log

[fieldOfView]

seems to imply that you are taking the view that (...) which you are unlikely to bother to fix.

For the record, I am just a community member spending time on a Sunday trying to find out what is going wrong running Cura on your system.

People saying "I have the same thing" without telling anything about their environment is frustrating; "we" know that this is an issue, "we" just can't find a way to fix it yet because we don't know what causes the problem. And yes, that sometimes makes me grumpy as well.

[Routout]

Fyi I'm running Cura on Lenovo laptop.
Operating System: Windows* 10 Pro (10.0.18362)
Processor: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz
Processor Graphics in Use: Intel(R) HD Graphics 520
Winwows security and firewall.

[Ghostkeeper]

Test version have still this startup problem, and main window doesn't open at all when cura starts after multiple tries.
cura.log

Just a hunch and I don't give it a lot of chance, but could you use Win+Arrow keys to move the theoretical Cura window around a bit, after starting Cura (and waiting a few seconds for the window to appear)? From your log it looks like it's started completely and waiting for user input, so maybe the window appeared outside of the dimensions of your screen.

[flackwell]

Cura failed to start again this morning. Hangs with the splash screen displaying "Updating configuration..." PC configuration identical to that described in my previous post. Unusually (for me) the stderr.log file had stuff in it. I've put the cura.log and stderr.log files in the attached .zip.

I also tried to look at the hung cura.exe process with windbg, but I've never used windbg before, so my clumsy attempts are likely complete gibberish. But for what it's worth, I've also included my attempt to get a stack trace.

Looks like it's trying to call CuraEngine.exe via a socket on the localhost, but never gets a response. Is there a race condition between cura.exe and CuraEngine.exe?

Ghostkeeper: the hung cura,exe process doesn't appear on the taskbar and I can't alt-tab to it, so I can't get at it to try moving it around.

Edit: should have added that Cura launched OK on the third attempt. Between tries I did nothing apart from end the hung process with task mangler and rerun it. This tends to reinforce my view that none of the alleged fixes is actually effective, at least in my case, and whether it starts or not is random with some probability. In other words, the problem is a timing issue or race condition.

cura_files.zip

[Ghostkeeper]

I think you guys are all having different issues that just have the same outcome of Cura.exe either freezing or closing. Your log files are different. In Flackwell's case I see that it didn't load the interface at all but indeed seems to stop at starting CuraEngine. There could be multiple reasons:

• Some firewall is blocking CuraEngine because it finds it scary.
• Some firewall is blocking local socket connections.
• Some VPN client is catching local socket connections to 127.0.0.1.

[flackwell]

I'm doubtful that Ghostkeeper's firewall suggestion can account for the facts, at least in my case.

1) I don't run a VPN client of any sort, so the third possibility can be discounted.

2) I only run Avast Free edition, which doesn't include a firewall. To my knowledge, the only firewall I have running is Windows Firewall.

3) Windows Firewall is rule based. Its behaviour should be predictable and repeatable. If a connection passes a rule and is allowed on one occasion, then the same thing should happen on every occasion unless the rules are changed. So firewall blocking wouldn't explain why cura.exe started on my third attempt this morning when I changed nothing between attempts, least of all any firewall rules.

4) However it does seem to me that what would be useful is more evidence and less speculation. Next time I attempt to launch Cura I will enable Windows Firewall logging beforehand - it is disabled by default - and I will post here anything of relevance that I find. Unfortunately firewall logging is fairly intrusive, which is why it is usually disabled. If the problem is timing related, as I suspect, it is possible that it will affect timings sufficiently to alter the system behaviour. But we can only try.

[Routout]

Test version have still this startup problem, and main window doesn't open at all when cura starts after multiple tries.
cura.log

Just a hunch and I don't give it a lot of chance, but could you use Win+Arrow keys to move the theoretical Cura window around a bit, after starting Cura (and waiting a few seconds for the window to appear)? From your log it looks like it's started completely and waiting for user input, so maybe the window appeared outside of the dimensions of your screen.

Win+arrows didn't help.

[Routout]

For me Cura 4.4.1 hangs here.

[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\da\AppData\Roaming\cura\4.4
[MainThread] UM.Resources.__initializeStoragePaths [435]: Data storage path is C:\Users\da\AppData\Roaming\cura\4.4
[MainThread] UM.Resources.__initializeStoragePaths [447]: Cache storage path is C:\Users\da\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) HD Graphics 520
[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 ...
[MainThread] UM.PackageManager._loadManagementData [139]: Loaded bundled packages data from C:\Program Files\Ultimaker Cura 4.4\resources\bundled_packages\cura.json
[MainThread] UM.PackageManager._loadManagementData [139]: Loaded bundled packages data from C:\Program Files\Ultimaker Cura 4.4\resources\bundled_packages\uranium.json
[MainThread] UM.PackageManager._loadManagementData [156]: Loaded user packages management file from C:\Users\da\AppData\Roaming\cura\4.4\packages.json
[MainThread] UM.PackageManager._saveManagementData [224]: Package management file C:\Users\da\AppData\Roaming\cura\4.4\packages.json was saved
[MainThread] UM.PluginRegistry.initializeBeforePluginsAreLoaded [86]: Loading plugin configuration file 'C:\Users\da\AppData\Roaming\cura\4.4\plugins.json

[Routout]

Here CuraCLI after Cura 4.5.99 finally runs for me after several tries.

curacli.txt

[Ghostkeeper]

Here CuraCLI after Cura 4.5.99 finally runs for me after several tries.

curacli.txt

This log is effectively the same as the log that was posted when it didn't run :disappointed:

[Routout]

I have tried Cura 4.4.1 without windows firewall and av, with different firewall and av. Uninstalled all my vpn programs. The problem is somewhere else than those.
Is it possible that display adapter or driver is reason for this? I noticed that @flackwell have Intel HD 630, and I have Intel HD 520. And he have exact same behaviour than I have.

[Ghostkeeper]

Yeah, could be. It's saying it started the OpenGL context fine though, in the log. Tried updating drivers?

[Routout]

It seem that at least for me it was the display driver. I had Lenovos own newest driver, and Intel driver msi didnt install becauseof Lenovo oem driver. But I noticed that I could install driver from the zip file manually.
So earlier problematic driver version was 26.20.100.6913 and now updated is 26.20.100.7584. Cura have survived three reboots already!

Both drivers have OpenGL 4.6

Edit: This is for Cura 4.4.1

[Routout]

New Intel driver 26.20.100.7584 still have same problem with Cura 4.5.99. Cura seem to load fine, but no main window.

[Routout]

@flackwell Could you try Intel HD 26.20.100.7584 driver version too?

[flackwell]

OK, I'll give it a go, but I'm a little busy right now. Maybe at the weekend.

Have to admit my driver is rather out of date: 25.20.100.6373 dated 18/11/18. Intel chuck out updates once a month or more, it's difficult keeping up. And on their drivers page, the Apollo Lake, Gemini Lake, Amber Lake, Whiskey Lake, and Comet Lake architectures are listed for 26.20.100.7584 but not Kaby Lake which I have. So I wasn't sure about it, and not having any (obvious) (other?) display problems I decided if it wasn't broke I wouldn't fix it.

Cura hasn't failed for me since my last post, but I've been running with Windows firewall logging enabled. Too soon to draw any conclusions.

[m-kozlowski]

It does indeed look like an intel video driver issue.
Managed to take a look on hung process with process explorer / process monitor.
It's stuck in single thread which stack trace varies, but it's always something around DumpRegistryKeyDefinitions, which is part of ig9icd64.

!ZwRequestWaitReplyPort+0x14
!DwmIsCompositionEnabled+0x278
!DwmUnregisterThumbnail+0x308
!DwmFlush+0x4f
!DumpRegistryKeyDefinitions+0xbea
!BaseThreadInitThunk+0x14
!RtlUserThreadStart+0x21

[Routout]

Cura have been working fine after driver update. Feels faster too after Win8 compatibility mode.

[rburema]

Some updates on chasing this windows/intel bug/crash:

• The intel driver update seems to work for some people at least, but we're not _completely_ certain yet that it solves all the issues (also some people might be stuck with the current one for a long while because of the policies of their respective companies and whatnot).
• Since the hang seems to happen when an opengl context is deleted (because we start the opengl context up twice, because we first _check_ if we can actually start a 4.1 context, and not get a software accelerated one), we think we may be able to work around the problem by just not deleting opengl context(s) (either by reusing the one that's made or just force the underlying library to not delete it).
• If we can somehow not do that, then we can add 'force to opengl 2.0' and/or 'force to opengl 4.1' flags and/or preferences, so that people can still work around the issue.

Thanks to everyone thinking along with us & helping out with this in other ways, you've been a big help! ❤️

[flackwell]

I've been running with Windows firewall logging enabled, to try to get more evidence about whether the firewall is implicated in the problem in some cases, as has been suggested. This morning 17 Jan 20 cura failed to load again - stopped with the black splash screen displaying "Updating configuration..." (as usual for me).

The attached firewall.zip contains the following files:

1) pfirewall_OK.log - a firewall log from 14 Jan when Cura loaded OK
2) pfirewall_OK.ods - same as above but in spreadsheet format and a bit easier to read
3) pfirewall_fail.log - log from the attempt on 17 Jan when it hung
4) pfirewall_fail.ods - as above
5) stderr_fail.log - stderr.log from the failed run
6) cura_fail.log - cura.log from the failed run

The relevant firewall activity seems to be the loopback connections via localhost 127.0.0.1 at 20:32:05 on 2020-01-14 when it worked, and 07:55:54 on 2020-01-17 when it hung. In both cases the firewall has allowed the connections; there is no evidence of any blocking or any different behaviour by the firewall between the two runs.

I'm not knowledgeable enough to know whether the src-port being different in the two instances means anything.

stdout.log is empty. Nothing pertinent in event viewer.

firewall.zip

[flackwell]

Have updated my graphics driver to 26.20.100.7584. Sample of one, first attempt after the update cura loaded OK. Early days, we'll see.

@Routout: do I understand correctly that you have reverted to not running in compatibility mode? I'm still in compatibility mode for Win7.

[Routout]

Have updated my graphics driver to 26.20.100.7584. Sample of one, first attempt after the update cura loaded OK. Early days, we'll see.

@Routout: do I understand correctly that you have reverted to not running in compatibility mode? I'm still in compatibility mode for Win7.

No compatibility mode needed anymore.

[bvalat]

Sorry for my abscence, i had no time for 3d printing for quite some time.
Before wprinting again i updated both Cura and my intel hd500 drivers.
I happy to say that 4.4.1 is working like a charm on my computer with latest intel driver (26.20.100.7755)

[mahtDFR]

I happy to say that 4.4.1 is working like a charm on my computer with latest intel driver

Great to hear, thanks.
Closing now.

[flackwell]

Just wanted to add that it's been fine for me too since I updated the graphics driver.

Would have posted this earlier but I waited a week to be sure and by then the topic had been closed.
Thanks especially to @Routout for prodding me into doing the update.