MAX_DRIVES might be too low causing Rufus to occassionally fail to detect drives #2029
Comments
|
This means that, as long as you don't see at least 64 See this part of our source that clearly shows that we only ever increment the counter we check against I can understand why you are trying to point the finger at Rufus for not enumerating all your devices, but the reality is that, if Rufus cannot list a specific device, and it's not a device that Rufus would filter by default (such as a fixed drive), then it's because the system did not report it to Rufus. I will therefore close this issue, as I see no element here that hint as your issue having anything to do with Rufus. |
|
I'm pointing at MAX_DRIVES due to these lines of code in drive.c, line 1080 in the GetDriveNumber() function as this is the only place where I can find the error message I found in the log. You'd have to scroll to the right on the log snippets to see the full error message but it shows that the device number that Rufus was getting was 65 in the attempt where I logged the issue. It's not about the number of drives I have but rather the DeviceNumber or DiskNumber that Rufus is receiving from windows in GetDriveNumber(). |
|
And as I just found out now, the issue isn't as difficult to trigger as I initially thought. I managed to get a full log of the issue using 3 different drives and 3 different USB ports. I got these 3 drives to work fine when I first encountered the issue and it disappeared, and 2 of those 3 USB ports where what I used then. Note that Rufus is receiving device numbers higher than 100 in this case. |
|
Ah, I missed that your earlier message was for a different check. Good point. Now the problem here is that we can't just randomly increase the maximum number of drives we accept for this specific part of the code, because we deliberately offset the drive number by So that means we want an offsetted limited range for our internal drive numbers, and I deliberately chose to limit that range to 64 entries because, of course, the more you limit the range, the more likely you will be able to catch stray drive numbers that are the result of a bug or an improper function call. This means there needs to be a compromise on the maximum number of drives we want to have in our selective range, that compromise being that it shouldn't be too small so that people run into it too easily (i.e we wouldn't want to have a range of At this stage, considering that you are the very first person in 10 years (!) to report running into our max range limitation, I'm not sure I want to alter anything, because my expectation is that you either have more than 64 drives on your system, or at least Windows is internally detecting more than 64 of them (because as far as I know, the numbers reported by So, unless I'm starting to see other reports of people running into that issue, I'm just going to have to leave people who are trying to run Rufus with more than 64 drives on their system stranded, because, at this stage, I just don't see much worth in investing time trying to increase that limit, or switching to a different check, and validating that it won't have negative effects on the existing code. I may add an entry in the FAQ to let people know that, if Windows lists more than 64 drives on their system, Rufus may not be able to locate the drive they want to use... |
|
I've investigated the issue further as I couldn't get Rufus to detect my drives anymore. I'm happy to report that, at least in cases similar to mine, I've found a reliable workaround. I only have 5 physical drives and one virtual DVD drive so Windows shouldn't need to use a device number higher than 20. Then I remembered that the Xbox for PC app uses virtual disks for most, if not all, games that are available through it. It uses one virtual disk per game that is packaged that way so installing 63+ games will likely cause Rufus to ignore any USB devices that are plugged in after all the virtual drives are mounted. Probably the best way to identify this issue is to look for a lot of devices named "Xvd" under Disk drives in Device Manager. The virtual disks are managed by a service named "Gaming Services". There are two services with that name and it looks like it is safe to stop them both. You only need to stop a specific one to unmount the virtual disks but it's just faster to stop them both than figuring out which is which first. The Xbox App should not be running, however, as it automatically restarts these services. It should be enough to right-click on the Xbox App tray icon and selecting Quit on the context menu before stopping the services, at least until Microsoft pushes an update that breaks this workaround. As far as I can see, the Xbox App only mounts the virtual drives when it needs to, but doesn't unmount them afterwards. I think in my case, the Xbox app updated causing the service to restart and unmount the virtual drives. This will make the issue to go away temporarily. If that was the case, anybody experiencing this issue can just restart both services, even while the Xbox App is running. This should make Windows use lower devices numbers until the Xbox App decides it needs to mount enough of the virtual drives to trigger the issue again. The only problem is that the Xbox App might decide that it needs to mount the virtual drives immediately after the services are restarted. One thing to note is that the File Explorer and the Disk Management MMC snap-in hides those virtual drives. Third party tools might show them but some of them will likely hide those drives too. I wouldn't have realized what was going on until I remembered the Xbox App uses virtual drives. I suspect if the Xbox Game Pass for PC gains enough popularity, an FAQ entry will be necessary. I also expect that modifying the code to address the issue won't be necessary, at least not anytime soon. I think anybody who is comfortable enough to create a bootable USB drive will likely be comfortable with stopping a couple of Windows services. |
Oh wow! I may have to review my assertion that the range limitation may not affect that many users, because this virtual drive creation by the XBox PC app may indeed become a problem...
Okay. So theoretically this should only become an issue for people who have launched many games and haven't rebooted their PC, or if for whatever reason the XBox app decides that it needs to mount a bunch of games for updates or something... I gotta think about this a little be more, and see how prevalent this might become. I may also alter the error message displayed in the log to let users know that, if they have the XBox app installed, they may want to try to restart it. And I'll definitely add a note in the FAQ about this. At any rate, thanks a lot for investigating this, and sorry for failing to see the actual error in your log and missing the mark on my first reply. I'm still hoping that not many people should be affected by this issue, but I'll definitely be monitoring if they are. |
Can an external application, such as Rufus, make an eject request for these mounted virual drives? Similar to ejecting physical drives, there may be an API available. With user notification, of course. |
I suspect the app checks for updates on a schedule, perhaps daily, and it mounts everything, or almost everything, regardless of whether there's actually an update for the game or not. I'm pretty sure I didn't play/install/update more than 20 games since I last restarted before the issue started to re-occur.
No worries. I know how easy it is to miss things in logs when there's so much information available. And that's still better than not having enough information. |
Since Rufus already runs in admin mode, I think it will have permissions to stop/restart the services which achieves the same result. It just needs to be able to identify the correct service(s) to stop/restart. I'm hesitant to suggest using a Windows API to eject the drives directly since, in my experience, the Xbox App is still a buggy mess. Unless the Xbox App itself provides such an API, which I doubt, "surprising it" by ejecting the drives will likely cause other issues. |
Same here. Plus, since we don't want to eject drives without warning the users and giving them a choice, that'd mean new API, new translations, and require time that I am not willing to invest on an issue that has yet to affect many users. There are plenty of corner cases, such as this one, that I could address in Rufus one way or another, but when you put them end to end, you start to spend your life addressing corner cases instead of improving the features and behaviours that most users will actually benefit from, so it's usually not a sound investment. As indicated earlier, I am not planning to go the extra mile on this specific issue at this stage, besides giving more information to the user about this in the log and in the FAQ (since those are genuinely 5 mins changes to apply, instead of what would most likely be a multi-day investement if I were to add eject, especially when factoring UI + translation requirements). |
|
I have now added an extra notice in the app when the error is triggered and created this new FAQ entry. |
|
Can confirm that the Xbox App is the main issue here since when downloading games from the Xbox App it makes a Xvd or Xbox Virtual Disk. This is likely done better support the game and make it easier to run on pc if there's no direct pc port for the game. Personally i have several hundred games installed and my Xvd amount is 92 at the moment and restarting will not do anything since there is a game installed on each of those, this makes me completely unable to use rufus on my main system which is unfortunate. |
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query. |
Checklist
<FULL LOG>below.Rufus version: x.y.z- I have NOT removed any part of it.Additionally (if applicable):
(✓)button to compute the MD5, SHA1 and SHA256 checksums, which are therefore present in the log I copied. I confirmed, by performing an internet search, that these values match the ones from the official image.Issue description
Rufus sometimes is unable to detect any drives due to the device number being too big. I've included the full log below, except for the end with the USB debug information I'm also including log snippets below that appear to be related to the issue.
I tried 4 devices (3 flash drives, 1 hard drive in a USB enclosure) with the List USB Hard Drives option checked. None of them were initially detected by Rufus. After trying repeatedly to get one of the drives detected (I tried using other USB ports at this point) and restarting Rufus, the issue appears to have resolved itself and all 4 devices could then be detected. Note that all the drives and USB ports I tried previously is now working.
Below is the part of the log wherein the issue somehow resolved itself. It shows a first attempt where the error still occurred and a 2nd attempt with a different drive which did get detected. Note that the detected drive was a drive that I tried to use but was not detected by Rufus due to the device number. I don't think I did anything to actually resolve the issue in between the two times I plugged in a device in the log snippet, other than just unplugging and unplugging the drives shown in the log. In between the attempts, I was probably just taking a peek the source code via Github to see if I can find a clue as to how to solve the issue.
I tried all the drives that Rufus was not able to detect previously and tried creating bootable USBs with the drives and encountered no issues this time. I've included portions of the log below showing the same device that was not detected in the log snippet above.
My guess is that Windows 11's maximum device number is higher than the current MAX_DRIVES, and I happened to get device numbers that exceeded that initially. After unplugging and plugging in drives, I probably caused Windows 11 to cycle back to lower device numbers allowing Rufus to then work. I don't know exactly how to recreate the issue nor what MAX_DRIVES should be for Windows 11 though.
Just a quick note about the log below, since I was closing and re-starting Rufus, only one drive shows in the log as failed. I was looking at the log in previous attempts and as far as I could see, the log showed identical error messages with just different device numbers being shown. Unfortunately, I was not able to take note of the details for those other attempts.
Log
The text was updated successfully, but these errors were encountered: