"Loading UI" splash screen takes a long time, and material manager too, if connected to network drives

[cruzer619]

Application Version

4.9.1

Platform

Windows 10

Printer

Ender 3 Pro

Reproduction steps

open app stuck at "loading UI" for about 5-10 min sometimes longer. app finally opens and can work like normal.

open up preferences, click on any of them are fine except "Materials". stuck loading for about 5-10 min and then finally opens. on some making any changes takes about 5-10 mins.

Actual results

eventually after waiting about 5-10 mins (sometimes longer) you will be able to perform the things you want. Opening of files or making configuration changes.

Expected results

not having to wait 5 -10 mins to open the app or make changes.

Checklist of files to include

• [X] Log file
• [ ] Project file

Additional information & file uploads

cura-error-logs.zip

Also the only plugin I have installed is Octoprint and it is up to date. If I roll back to 4.8 I have no issues what so ever.

[fieldOfView]

Does the same pause while "loading ui" happen when you disable the OctoPrint Connection plugin?

[cruzer619]

yes does the same thing without the plugin loaded.. and takes 5 - 10 min to load Marketplace.

[fieldOfView]

Thanks for testing without the OctoPrint Connection plugin.

Does (temporarily) disconnecting your computer from the network change the startup time? Obviously it will break the Marketplace altogether.

[cruzer619]

doing so.. crashed cura. Here is the crash text from the crash windows. cura-crashlog.txt

[fvrmr]

Could you try to remove the 4.9 folder here: C:\Users\<your username>\AppData\Roaming\cura That will reset your preferences.

Can you let me know if that works for you.

[cruzer619]

after removing the folder. comes up quick after doing the initial setup. But as soon as you close it. And I waited like 5min and reopened Cura. Does the same thing, 5 -10 min sitting at Loading UI.. and same issue in Preferences when selecting "Materials" takes 5 - 10 min to load.

[cruzer619]

ok after looking around at some other errors users have about slowness and your fix in 4.9.1 about none connected drives. Seems there is still issues with it. I normally don't use Cura while i'm working, So I don't connect to my work file servers via our VPN. This time I did and slowness is gone. Everything is running as expected. As soon as I disconnect from VPN and all my networked mapped drives have RED X's on them. Behavior comes back takes forever. So to workaround this I manually disconnect all my mapped drives. And I'm able to open up Cura again. Down side its extra step for me now to get my work done.. So I'm forced to go back to 4.8 as my paycheck takes precedence over my hobby.. haha..

[fieldOfView]

Something to try is to NOT log in to your Ultimaker account in Cura. Being logged in to your Ultimaker account in Cura while not being connected to the network caused the crash you saw after disconnecting from the network.

[cruzer619]

ok verified. Cura doesn't crash when opening app offline (not connected to the internet) and not logged in.

[cruzer619]

were you able to reproduce my mapped network drive behavior?

[Ghostkeeper]

Not yet. None of our developers on Windows have seen such a slow start-up time, while we also work on VPNs.

This is the relevant part of the log file, where it seems to be slowing down:

2021-05-17 16:44:48,823 - DEBUG - [MainThread] PostProcessingPlugin.PostProcessingPlugin._createView [342]: Creating post processing plugin view.
2021-05-17 16:44:49,120 - DEBUG - [MainThread] PostProcessingPlugin.PostProcessingPlugin._createView [352]: Post processing view created.
2021-05-17 16:48:18,373 - WARNING - [MainThread] UM.Qt.QtApplication.__onQmlWarning [411]: file:///C:/Program Files/Ultimaker Cura 4.9.1/resources/qml/PrintSetupSelector/Custom/MenuButton.qml:42:18: QML Label: Cannot anchor to an item that isn't a parent or sibling.
2021-05-17 16:48:18,772 - WARNING - [MainThread] UM.Qt.QtApplication.__onQmlWarning [411]: file:///C:/Program Files/Ultimaker Cura 4.9.1/resources/qml/Account/UserOperations.qml:17:5: QML QQuickItem: Binding loop detected for property "height"

The QML warnings indicate that some interface elements may be positioned wrong. It's got nothing to do with any slowdown.

The PostProcessingPlugin messages are triggered when the main window is created, asynchronously. So the Cura code being executed there is still fairly fast. However 4 minutes later it's giving messages about that it finds mistakes in the QML elements of the main window (PrintSetupSelector, where you can change the material/nozzles of the active printer). So all that time it must've been processing QML entries for the main window in Qt's QML parser.

I have no idea how the QML parsing could ever be so slow when you have a mapped network drive.

Or did you install Cura on a network drive? What is the installation folder, as you selected on Cura's installer?

[cruzer619]

nope Cura is installed locally on my computer.. as long as I have drives that look like this below (internet photo). Takes a long time to load. As soon as I removed them all. Cura works perfectly. I did a little more testing. If I only have one/two disconnected red x drive. It is reasonable to load but after 3 drives then it takes a long time to load. Also, I went back to version 4.8 and I don't have this issue no matter how many drives discconnected.

[Hawkert26]

I have the same issue. As long as network drives are connected, it works fine otherwise it is a tedious wait.

[liqdfire]

@fvrmr I was experiencing an application hang when starting at "Loading UI" in version 4.9.0 I tracked it down to the dialog_save_path key in the cura.cfg file. I was pointing to I:\ which is the drive letter assigned to my sd card reader, and the card reader was not attached to my system, thus I:\ did not exist.

I changed it to C:\ and Cura started without issue, I changed it back to I:\ and it hung on startup. I re-attached the card reader, and left the config value at I:\ and it started without issue.

[cruzer619]

In my case that isn't the issue. Everything in my cura.cfg file is pointing to "C:" Drive.

[fieldOfView]

Everything in my cura.cfg file is pointing to "C:" Drive.

Have you also checked the recent_files under [cura]?

[cruzer619]

Everything in my cura.cfg file is pointing to "C:" Drive.

Have you also checked the recent_files under [cura]?

Yes, everything is pointing to the "C:" drive.

[cruzer619]

Since I wanted to go back to 4.9.1 and whipped out some old batch script knowledge.. This is my workaround using a batch script to open cura. Pretty much it disconnects all my network attached drives before opening opening cura. Its simple batch file and works. For me I had 7 network drive letters to remove. And then I made a manual batch script to bring back the drives when I vpn back in to work.

batch script

@echo off net use * /d /y timeout 1

start "" "C:\Program Files\Ultimaker Cura 4.9.1\Cura.exe"

end batch script

Here is the modified shortcut.

UPDATE:

Simply set Cura.exe to "run as admin" will work.

[Ghostkeeper]

@fvrmr I was experiencing an application hang when starting at "Loading UI" in version 4.9.0 I tracked it down to the dialog_save_path key in the cura.cfg file. I was pointing to I:\ which is the drive letter assigned to my sd card reader, and the card reader was not attached to my system, thus I:\ did not exist.

I changed it to C:\ and Cura started without issue, I changed it back to I:\ and it hung on startup. I re-attached the card reader, and left the config value at I:\ and it started without issue.

The only place where this preference is being used is here:

https://github.com/Ultimaker/Uranium/blob/4f088d99c135518f3dde1dafad9c78e9e30a211f/plugins/LocalFileOutputDevice/LocalFileOutputDevice.py#L112

This is code that should only execute once you clicked the "Save to Disk" button or the "Export" option from the file menu. Not at start-up! I also put a hook on the Preferences.getValue function which indeed finds no calls to get that preference during start-up.

[nallath]

In my case that isn't the issue. Everything in my cura.cfg file is pointing to "C:" Drive.

Could you try disabling the "Removable Drive Plugin" and see if the problem persists (we're just trying to pin down what part of the code is causing it, it's not intended as a permanent work around).

[cruzer619]

In my case that isn't the issue. Everything in my cura.cfg file is pointing to "C:" Drive.

Could you try disabling the "Removable Drive Plugin" and see if the problem persists (we're just trying to pin down what part of the code is causing it, it's not intended as a permanent work around).

unfortunately problem still persists when disabling removable drive plugin... is there a way to run cura with all plugins disabled.. then I can go one by one, enable and see what is causing it.. if it is a bundled plugin.

[nallath]

unfortunately problem still persists when disabling removable drive plugin... is there a way to run cura with all plugins disabled.. then I can go one by one, enable and see what is causing it.. if it is a bundled plugin.

Ugh. I was really hoping it would be that :(

Other than doing it one by one via the installed tab, i don't think there is a way to do it.

[cruzer619]

ok disabled all bundled plugins and problem still presists.. so its not a plugin. :(

[Ghostkeeper]

:( Confusing. Probably would be good to re-enable those again then.

Since you indicate that the "materials" screen also takes very long to load, perhaps something is up with your material profiles. These are also loaded in the "loading UI" stage because that's when it creates a list of the available materials for your configuration. I've tried adding a few of them but it keeps loading fine for me.

There is one more thing we can try to reproduce this. A bit of a strong measure. Could you:

• Navigate to %APPDATA%\roaming\cura (the resource folder of Cura).
• Compress the entire 4.9 folder in a .zip archive.
• Post that here?

Since 4.9, Cura no longer stores log-in tokens in the cura.cfg file so it should be safe to share that, unless other plug-ins still store sensitive information in there (like Octoprint, but that would require access to your network anyway I suppose).

Using your entire resource folder we should be able to restore your exact state of all profiles and settings. Maybe this will shed some light on what it's doing.

[Ghostkeeper]

Re-reading this thread I see that the issue was also gone once you disconnected from your VPN and the network drives were removed.

Cura should only read from the C: drive and from %APPDATA%, and write to %APPDATA%. Is there something syncing %APPDATA% with the network maybe, making it slow to write to or read from?

[cruzer619]

Re-reading this thread I see that the issue was also gone once you disconnected from your VPN and the network drives were removed.

Cura should only read from the C: drive and from %APPDATA%, and write to %APPDATA%. Is there something syncing %APPDATA% with the network maybe, making it slow to write to or read from?

my %appdata% variable goes to c:\users\cruzer\AppData\Roaming. Also I have re-enabled all bundled plugins.

do you still want a compressed file of my "roaming\cura" folder??

[Ghostkeeper]

No, I don't think it'll reveal much as long as I don't have the same type of network drives. And I can't have the same type since I'm on Linux.

[jenniferlee1818]

cura.log stderr.log any fix for this? I have the same issue on Windows 10. 4.9.1 worked great. 4.10 gives me exactly this same problem. Also besides the long wait for Loading UI and Materials, I get the same lengthy wait for Profile manager.

[Ghostkeeper]

@jenniferlee1818's log file shows a long wait at a different place though. Is the issue also reduced if you temporarily disconnect any network drives?

I don't think we really changed a lot in the loading of the main window between 4.9.1 and 4.10.0 that would warrant there being this much of a difference.

[jrwaters2]

I'm having this issue as well. However, the long waiting period is at a) Startup and b) Any configuration screen, not just materials.

I posted my logs at https://github.com/Ultimaker/Cura/issues/9139 . . . should I move that information here?

Using Windows 10. My startup wait was 16 minutes last time I measured.

I should mention - if I run Cura as an Administrator, all of the lags disappear. Hope this is a helpful workaround for others.

Thanks Jack

[cruzer619]

@jrwaters2 do you have network attached drives but disconnected ( hence red X ) as my picture shows above? from looking at your other post doesn't seem that way but wanted to verify. If so you can get around the issue with the "workaround" I post above as well. Until they figure out what is trying to scan those "disconnected" network drives and why the long lag startup times.

UPDATE: I didn't see the part that running as Admin and it all works.. If you have my scenario I will give that a try when I have some time and run as admin.. if that is all.. then thats easy to change in a shortcut to always run as admin.

[cruzer619]

@jrwaters2 well s*n -f a b-tch.. that worked, sweet!!!!.. Now I don't have to disconnect my work drives.. Just have to modify shortcut below and your set.. Less things to worry about.. Thanks for that.. woohooo!!!!

[jrwaters2]

@jrwaters2 do you have network attached drives but disconnected ( hence red X ) as my picture shows above? from looking at your other post doesn't seem that way but wanted to verify. If so you can get around the issue with the "workaround" I post above as well. Until they figure out what is trying to scan those "disconnected" network drives and why the long lag startup times.

UPDATE: I didn't see the part that running as Admin and it all works.. If you have my scenario I will give that a try when I have some time and run as admin.. if that is all.. then thats easy to change in a shortcut to always run as admin.

Hey, I don't have VPN connected or active network drives. I also checked my Cura config file and all drive references were to c:.

[jrwaters2]

@jrwaters2 well s*n -f a b-tch.. that worked, sweet!!!!.. Now I don't have to disconnect my work drives.. Just have to modify shortcut below and your set.. Less things to worry about.. Thanks for that.. woohooo!!!!

Excellent - glad to have helped someone!

[cruzer619]

@Ghostkeeper and the rest of developers.. So sounds like in 4.8 and greater, some process needs elevated credentials to run when certain environments like mine or Jacks's (jrwaters2) to run correctly. I'm hoping this helps you track things down. Its been running fine for the past 3 days with run as admin checked marked. No slowness what so ever on startup and can modify things in settings. For me this is a resolved issue, but I will leave it to you guys if you want to close this or not. To help others with similar issue. And I will gladly help in any testing that is needed to help better resolve the issue.

[katyo]

I have similar problem with cura 4.10 on NixOS.

[nallath]

I'm hoping this helps you track things down. Its been running fine for the past 3 days with run as admin checked marked.

It does help somewhat, now at least we know it has something to do with rights. It does narrow it down a bit, but it still leaves a lot of things that it could be. It is a big step forward though.

For me this is a resolved issue, but I will leave it to you guys if you want to close this or not. To help others with similar issue. And I will gladly help in any testing that is needed to help better resolve the issue.

I consider this to be a workaround. It's great that we have it, but the full solution would be finding out how to make sure that the admin rights are not needed.

[cruzer619]

@nallath understood and really appreciate all the hard work you guys have done. Again anything to test I will do.

[jrwaters2]

Even though I stated before I was not using Network Drives, I did look deeper into this. I noticed I had one network drive mapped and concluded it is related to the problem. When I clicked on the drive, explorer would hang - perhaps on the order of the 16 minutes like Cura but I ran out of patience to measure it.

Any way, there is a Microsoft bug and one of the ideas solved the problem for me. I no longer have to run Cura as admin. See https://answers.microsoft.com/en-us/windows/forum/all/mapped-drives-hanging-windows-10-file-explorer/b80a4e71-2156-47fd-b5ad-b2127d7d0ced?auth=1&page=2.

To quote the user "WheresSupport" on that page:

Just in case anyone is still dealing with this there does appear to be a functioning work around. It'll at least get us by until we can finally and fully deprecate our SMB1 shares.

The trick is to add the registry key "ProviderFlags" as a REG_DWORD with a value of 1 (0x00000001) to HKEY_CURRENT_USER\Network*SMBv1 Drive Letter*

Then reboot or log on/off. It fixes the perpetual "reconnecting" status of the SMBv1 drive at logon and everything has been functioning normally and quickly for users we've added that registry key. Only needs to be added to the drive letters under Network that correspond to SMBv1 shares.

Credit goes to user LeeB1430 in this thread.

This doesn't mean that Cura is innocent. The mapped drive in question clearly has problems but it is never referenced in my configuration and doesn't seem to be causing issues for any other application. So, I'd ask if Cura is scanning mapped drives when it doesn't need to? Or perhaps initiating some seemlying innocent OS action that interacts with mapped drives.

[Ghostkeeper]

Cura has historically accessed the D: drive and the X: drive, because the build server we used to build Cura was building it on that drive. You see, Cura's front-end source code is Python files, and we package those inside the executable with a program called cx_Freeze. However, all Python modules also provide a variable called __file__ which should point to that .py Python script. That Python script no longer exists since it's inside of the .exe now. So cx_Freeze makes that script save the __file__ variable to whatever it was before it got packaged. On the build server that was some path involving the X: drive.

Cura should never use the __file__ variable except in plug-ins (which don't get packaged). We've searched our source code for those uses but they don't exist. However we couldn't guarantee that for Cura's dependencies. Cura uses dozens of Python libraries which may still be using the __file__ variable. Those might have been accessing the X: drive.

We've now moved our build server to use the C: drive instead. So whatever dependency that was might now be trying to see if certain files exist on the C: drive (which could be a security risk, but is likely innocent since those get security reviewed too).

You can't map a network drive to C: so I don't think that is your problem. But perhaps something similar is going on.

Another possibility would be the Removable Drive plug-in, since that looks which drive letters exist. However this was already ruled out by people in this thread testing if the issue is still there when the plug-in is disabled. A similar, but less likely case, would be the USB Printing plug-in doing something similar. The USB printing plug-in checks for COM ports on Windows. I don't think these drives would be connected via COM port though. Apparently they are SMB drives.

A final possibility I can think of: Cura creates two file dialogues at start-up, one for saving files and one for loading. They just aren't visible yet until you try saving/loading a file. These file dialogues show your network drives, so they cause Windows to look for which drives exist. Perhaps that could be slowing the application down.

[jrwaters2]

This is interesting - thank you for the background. In my case, the mapped drive was G:.

The delay is not only at startup - it is when Materials Manager or Settings are opened as well so the startup theory would have to take that into account.

The Windows issue is definitely beyond Cura. My next theory is that something is triggering Windows to scan mapped drives (versus some explicit reference). I'll noodle over it more to see if I can find some link - i.e. some action that might trigger this.

In the meantime, I think the workaround to add the ProviderFlags registry key is the best because it gets closer to the root issue.

[nallath]

A final possibility I can think of: Cura creates two file dialogues at start-up, one for saving files and one for loading. They just aren't visible yet until you try saving/loading a file. These file dialogues show your network drives, so they cause Windows to look for which drives exist. Perhaps that could be slowing the application down.

But if that is the case, we might be able to solve that by creating those in a loader.

[jrwaters2]

A final possibility I can think of: Cura creates two file dialogues at start-up, one for saving files and one for loading. They just aren't visible yet until you try saving/loading a file. These file dialogues show your network drives, so they cause Windows to look for which drives exist. Perhaps that could be slowing the application down.

But if that is the case, we might be able to solve that by creating those in a loader.

The file open and save operations don't cause any performance degradation . . .its only startup and accessing preferences (material manager or profiles). But I love the brainstorming. Put it all in-head and theories come out . . . maybe :-)

[Ghostkeeper]

The file open and save operations don't cause any performance degradation . . .its only startup and accessing preferences (material manager or profiles). But I love the brainstorming. Put it all in-head and theories come out . . . maybe :-)

What I meant is that the action of "showing the file open dialog" really just turns the visibility on, but the whole dialogue is created during start-up: They just aren't visible yet until you try saving/loading a file. So if the slowness happens during the creation of those file dialogues, it could cause the start-up to be slower. As Nallath says, we could solve that by putting them in a loader to load them in lazily. That would mean that the slowness happens when the file dialogues are first needed (so when you first try to open a file).

[jrwaters2]

I'm not qualified to speak to any other benefits of that approach. However, when I was having the issue, my delay was 16 minutes (in other words, not acceptable at any point in the process, whether initialization or otherwise)..

Also, the fact that it would happen just accessing materials manager - i.e. it wasn't just associated with showing the file open dialog, made me think it wouldn't help. In fact, I didn't experience any delay when accessing the file dialog box though perhaps another user did.

Never looked at Cura source code so of course I could be missing some obvious point . . .if so, my apologies.

Best Jack

[Ghostkeeper]

Indeed, 16 minutes (or 8 if that 16 is from loading 2 file dialogues) is not acceptable at any point. If the user wants to open a file, they are not going to wait for 8 minutes for the file dialogue to open.

It's logical that the material management page also triggers this problem. It contains two file dialogues as well, for the import and export (and a third one in 4.11 for an export-all function): https://github.com/Ultimaker/Cura/blob/d24b28c9b912aa140e096129505568e6ebbf2088/resources/qml/Preferences/Materials/MaterialsPage.qml#L327

These are individual file dialogues though. We don't specialise them a whole lot, except for what happens when you press "save", the filters and the folder it starts on. We might be hitting a bug in Qt here: https://bugreports.qt.io/browse/QTBUG-6039 . However, that issue was recently fixed and backported to Qt 5.15.1. We are using 5.15.1 since Cura 4.9, so you'd expect it to no longer be an issue then.

[jrwaters2]

Wow. Symptoms for QTBUG-6039 seem the same.

I think this is related to SMB1 for what that is worth. The workaround I'm using now is to add ProviderFlags in my registry for that drive. According to https://think.unblog.ch/en/no-network-drives-after-windows-update/, ProviderFlags will:

The Registry Key ProviderFlags controls the recovery of network shares they use Server Message Block (SMB) version 1 when they are stored in the registry.

That might explain why more people don't see the issue. If you do want to make a test build of 4.10.x with different initialization, I'll be happy to characterize it. By characterize it, I mean:

1. Remove my ProviderFlags workaround
2. Load the new Cura and look at a) startup time, b) time to load materials manager, c) time to display file dialogs, etc
3. Add ProviderFlags workaround back
4. Do step 2 again

Just let me know. With ProviderFlags, life is good, no delays of any kind. So, I think that workaround is acceptable but if you are looking to go deeper . . . .

Best Jack

[Ghostkeeper]

I don't think it's acceptable for Cura to adjust the Windows registry to change that ProviderFlags entry. Cura should not be adjusting registry keys outside of its own domain. It could mess with other applications. That registry entry could be there for a good reason.

[jrwaters2]

I agree with you completely. Maybe I can explain further.

Windows shared drive support is fraught with bugs. I run an engineering team and we had some smart folks spend weeks figuring out issues and inconsistencies associated with disconnected network drives in particular.

I believe this is a similar situation. Its not directly caused by Cura. If I try to access the disconnected drive, for example, without Cura involved, it does the same thing.

So, I would not suggest Cura to change the registry . . . I consider this to be a Windows bug. Manually changing the registry is my workaround until Microsoft fixes the issue.

Ideally Cura would not even trigger this but fundamentally I think it is a Microsoft issue and Cura def. should not change the registry IMHO.

[cruzer619]

@Ghostkeeper since we think the issue is with Qt version. Would it make sense to rollback to whatever the version was on 4.8 and see if that fixes the issue? that is of course if that version can run on 4.9/4.10. As with 4.8 latest version I didn't have that issue whatsoever.