Cura: Cant start cura

[Austinthemighty]

Cura keeps prompting me with an error that says
There is no disk in the drive. Please insert a disk into drive D:.
every time i hit one of the buttons like ok, try again, cancel, or the x to close it, it just keeps popping up, the only way to stop it is to go into task manager and end the task, also this is a fresh install of 2.4.0

[Vandrasc]

Do you have a sd card/usb inserted in your machine which is assigned to the D drive? If so, try to remove it before starting Cura.

[Ghostkeeper]

We've seen this problem sometimes with SD card readers and USB splitters that they report an SD card or USB stick being present while there is actually no card or stick in there.

[Austinthemighty]

ok, i do have a sd card reader plugged in, and it is showing that there is a D: drive

[fieldOfView]

There is code that is supposed to stop this from happening:
https://github.com/Ultimaker/Cura/blob/master/plugins/RemovableDriveOutputDevice/WindowsRemovableDrivePlugin.py#L71
The strange thing is that nothing in that code changed substantially between 2.4 and 2.5

[fieldOfView]

It seems to be limited to removable drives that have the D: letter. Could it be related to the fact that Cura for Windows is built with data coming from the D: drive on the build system? The co_filename property still points to the D drive. Could it be that python or py2exe is trying to access the original files?
http://python-reference.readthedocs.io/en/latest/docs/code/filename.html

[Ghostkeeper]

Could be. We add UM/Application.py/../resources as search path, actually.

[awhiemstra]

We only add that when running from source. Additionally, I do not know of anything that uses co_filename except for traceback printing, which just prints it as a string.

[Ghostkeeper]

Looking through the source for __file__ yields:

• Five times where it only uses __file__ when not frozen (what awhiemstra described).
• A whole bunch of unit test related stuff and the benchmark.
• X3GWriter, which is not in the official release.
• The examples for libArcus and Uranium.
• setup.py for Cura to find the UM directory.
• Plug-in registry, line 237 in getPluginPath.

None of these seem to be a problem. Only the last one worries me a bit, but it gets the path of a plug-in which is not packed into the executable, so it's probably fine. Interestingly I didn't find anything about loggers.

[fieldOfView]

I am more worried that it might be something in py2exe.

If my hunch is correct, ANY card-reader that is identified as D: that does not have a card in it would showcase the problem. On my dev machine, D: is a recovery partition so it never manifests. I'll see if I can reproduce this on another machine.

[danilius]

Got this same error just now. Workaround was of course to reinsert the removable drive. But that this still persists from 2.4 is a bit weird. Probably not affecting enough users to get any love.

[fieldOfView]

More too hard to reproduce, I guess

[danilius]

Oh no, it's quite easy to reproduce. If I had clear documentation how to set the code up for debugging on Windows I could probably trace the bug. It has been a few years since I have written code seriously, but I doubt I have forgotten much. If anyone is willing to hand-hold me in getting a debugging setup going I will give it a whirl.

[fieldOfView]

I meant "hard to reproduce on a machine a developer has access to, so he/she can see what is going on and test solutions first-hand"

[danilius]

Ah, good point.

[fieldOfView]

Something I would want to try to check a hunch is the following:

1. make sure the issue reproduces reliably (in your case: remove the sdcard from the reader)
2. close Cura, and in the Cura program files folder remove the entire plugins\RemovableDriveOutputDevice folder
3. start Cura and check if the issue still occurs (my hunch is that it actually still reproduces).

Next:

1. close Cura and remove or rename cura.cfg in AppData\Local\Cura
2. start Cura and check if the issue still occurs

[fieldOfView]

The way to workaround it by the way - other than keeping a card in your reader - seems to be to change the driveletter of the reader from D: to something else. This may also be why it is a bit harder to reproduce, because many systems have a Windows 10 recovery drive as D:, so an sd card reader will never be D:. It is my hunch that any empty removable drive on D: would cause this problem, and it may not be in our code.

[danilius]

@fieldOfView I tried out the steps you mentioneed above, and the problem persists, so your hunch was correct.

No idea if this is helpful or not, but if I kill the process in Task Manager, the dialog box does not go away until a button is clicked, so the issue might be ocurring in a different process than Cura itself.

[Ghostkeeper]

It's Windows giving the warning in a different process, but it's still Cura that tries to access D:.

[danilius]

It has been a while since I have coded for Windows, but as fas as I recollect, if you were accessing a non-existant drive in a given process, any warning dialogs would be running within the context of that process. If that is the case, then something is going in behind the scenes that is not of your making, in which case tracking dowt the problem is going to be fun.

[StageMonkey]

I had this problem come up recently. I'm using Cura 2.5 on Windows 10. All I did was open File Explorer, select "This PC" (AKA My Computer), and I could see that there was what appeared to be a removable Drive D even though I didn't have anything in inserted...so I right clicked on it and hit "Eject". Cura opened like normal after that. I don't know why I had a phantom D drive when there was nothing plugged into my USB or SD slot. But that seemed to work for now.

[danilius]

An additional bit of info here, and why this is not going to be resolved by the CURA team: turns out that the Nvidia WebHelper has exactly the same problem. So, this has nothing to do with CURA, it's a Windows problem.

[nallath]

This issue has been fixed. Should no longer be an issue for 2.7

[danilius]

Jolly well done. Curious to know what the solution was, or more precisely where the problem stemmed from.

[fieldOfView]

See https://github.com/Ultimaker/Cura/commit/ef51897b716ecb42aedef12932f9df2e965f3f5e
So basically tell windows to stop whining.

[danilius]

Wouldn't we all love to be able to tell Windows to stop whining whenever we wanted to.....

[nallath]

The problem was that windows API's are a bit weird.

We did the following;

• For each drive
• Check if drive is removable
• Check size of drive (in case of sd card, this can be 0)
• if not 0, add it as a removable drive for Cura

The third step ocasionally caused issues for certain versions of windows, as it would actually try to mount it if there was no drive (and thus, fail). In most cases this failure would result in a size of 0 and cura would happily move on. In some cases it would then start spamming messages to the user.

The "fix" is basicly telling windows to shut up and not bother the user (which kinda makes sense, as Cura handles it). The weird thing is that we're calling some windows API, so any user facing message is not really something you'd expect...

[dwahler]

I'm still seeing this error with the 2.7 beta. Cura won't start as long as my SD card reader is plugged into a USB port.

Is there any additional information I can provide to help troubleshoot?

[Ghostkeeper]

Oh. Perhaps @Austinthemighty can test this with the 2.7 beta too?

[danilius]

Seen this error with 2.7 as well.

On 23 August 2017 at 09:35, Ghostkeeper [e-mail] wrote:

Oh. Perhaps @Austinthemighty https://github.com/austinthemighty can
test this with the 2.7 beta too?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Ultimaker/Cura/issues/1602#issuecomment-324260921,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHqirfkDdt7WeaRBypzPOA7dfo5ZseKIks5sa-ROgaJpZM4Msbdg
.

[fny82]

I just downloaded 2.7.0 and I am consistently encountering this error.

[Austinthemighty]

@Ghostkeeper i will try the 2.7 beta once i get home

[h3tr1ck]

I am also seeing this pop-up appearing on version 2.6 and 2.7. My machine has a generic multi-card USB device built in that Cura is seeing as a removable drive. If I disable this in the device manager cura boots fine but then I can't use the front USB ports on my machine.

[Ghostkeeper]

Perhaps the workarounds listed in #2372 could help for now.

[Ghostkeeper]

From @RGN01 in one of this issue's duplicates:

Nallath, unfortunately v3.0 did not fix this issue.

I've just installed 3.0 from 2.7. I get that dreaded 'no disk in drive X:" message. After lots of investigation I discovered that it is trying to access a drive allocated to a multi-memory card reader. The particular slot uses a card format that I haven't used for about a decade so I'm pretty sure that I've never used it with any prior version of Cura.

If I disconnect the card reader then it works OK but I need it for the other cards.

Can this not please default to one of the fixed drives, or at least check that the drive is accessible before committing to use it?

There's two things that contribute to this problem: One is that Cura seems to be accessing the X: drive for some reason. We don't know what it is but it seems to be either a problem in cx_freeze or somewhere where we still access the __file__ property of a class. The X: drive is the drive that our build server is currently using. The other problem is that Windows indicates that this drive is accessible, but then starts to complain with a pop-up to the user when Cura actually accesses the drive. That is something between your USB drive and Windows. Because we do check whether a drive is accessible and your operating system reports that it is.

[MFHFozzy]

Ive seen this problem before, in Gimp. The symptoms were the same. The actual drive letter doesnt seem to matter. Only that a removable disk drive is attached to the system and does not have a disk in it.
Disabling the removable drive fixes the problem, re assigning drive letters does not.

[ianpaschal]

Can someone who was experiencing this issue confirm if it's still happening in the latest build (3.2.1)?

[Ghostkeeper]

We're still getting reports about this on the forum, at least from the 3.2.0 beta. But seeing as how nothing was done to attempt to fix this since then and the build system hasn't changed much, I wouldn't expect that this is fixed yet.

[Tofoillote]

Hi there, still can't find any solution in my 3.4.1 version :( just won't start.

[fieldOfView]

@Tofoillote, unless it repeatedly shows the error "There is no disk in the drive. Please insert a disk into drive X:.", it is a different issue. If it is a different issue, please open a new issue and supply all the information that is needed with a new issue, or noone can help you.

[Tofoillote]

Ok, so, the solution was so dumb !
Put a card in every SD or Micro SD card reader I have on my computer so It succeed start for first use.
Next it works properly.

[Ghostkeeper]

If you put a proper file system in the X drive it should prevent the error.

We still don't know what is reading from the X drive and why. The X drive is the drive that our Windows build server is running from and it freezes the paths to the Python files when it builds Cura into the executable. So the paths to the X drive are in there, but they shouldn't actually be used because we never actually need the introspection of where the Python files are located and we certainly don't need to read any files there.

[diegopradogesto]

Is this still an issue in 4.2?

[RGN01]

Sorry, I can't help. As a result of that issue and not finding a way around it I was forced to use a different slicer and have not looked back.

[Tofoillote]

same here.
no issue so I've changed slicer since 4.0 not working too.

[Ghostkeeper]

We got another report about this here: https://github.com/Ultimaker/Cura/issues/8700
They had a network drive on the X: drive letter that was causing slowness.

I've been theorising that it could be either CPython itself trying to load modules relatively (e.g. because someone is doing from . import * or something) or it could be one of our dependencies accessing the __file__ attribute.