Very slow "Scanning image... "

[Scampi-ml]

<!-- PLEASE READ THIS CAREFULLY:

1. You MUST read and complete the steps from the checklist below, by placing an x into each [ ] (so that it shows '[x]', NOT '[ x]' or '[x ]'), BEFORE clicking on 'Submit new issue'.

2. Failure to perform these steps, WHICH ARE ONLY THERE TO HELP YOU, will usually result in your issue being dismissed without notice.

3. If you are reporting an issue when trying to run Rufus, or when trying to boot a media created by Rufus, you MUST provide a log, period. Please do not assume that the developer(s) will be able to "guess" the specifics of your environment, what image you used, what type of media you used it with or the many many other critical parameters that the log provides data for. To investigate an issue, a log from Rufus is ALWAYS required.

4. If you still choose not to provide a log when reporting a problem, you agree that your issue will be closed without any further investigation.

YOU HAVE BEEN WARNED. -->

Checklist

• [x] I have been made aware that if my problem can be summarized as "I've created or tried to create a media using Rufus, and ...", and I am not including a log, this issue will be summarily closed.
• [x] I looked at https://github.com/pbatard/rufus/wiki/FAQ to see if my question has already been answered.
• [x] I performed a search in the issue tracker for similar issues using keywords relevant to my problem, such as the error message I got from the log.
• [x] I clicked the 'Log' button (🗒️) or pressed Ctrl-L in Rufus, or used DebugView, and copy/pasted the log into the section that says <FULL LOG> below.
• [x] The log I am copying is the FULL log, starting with the line Rufus version: x.y.z - I have NOT removed any part of it.

Additionally (if applicable):

• [ ] I ran a bad blocks check, by clicking Show advanced format options then Check device for bad blocks, and confirmed that my USB is not defective.
• [x] I also tried one or more of the following:
  • [x] Using a different USB drive.
  • [x] Plugging the USB into a different port.
  • [x] Running Rufus on a different computer.
• [ ] If using an image, I clicked on the (✓) 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

I am reopening this issue after searching the web and not finding a good solution.

Source:

• https://www.ubackup.com/explore/rufus-stuck-on-scanning-image-6007-ac.html
• https://github.com/pbatard/rufus/issues/375
• https://github.com/pbatard/rufus/issues/1575

Issue: When starting rufus4.6.exe everything is fine, however when selecting an ISO (see below) it starts scanning the image. This takes a very long time. Meanwhile the program is completely locked (grayed out). Canceling takes a very long time too. In one instance i had to shut it down using task manager.

Download in question: https://drive.massgrave.dev/en-us_windows_11_enterprise_ltsc_2024_x64_dvd_965cfb00.iso

Fixed: By reverting back to rufus-4.5.exe

Idea / long term fix: Have an option to disable scanning the iso, or ask if an image wants to be scanned

Log

Rufus x64 v4.6.2208
Windows version: Windows 10 Enterprise LTSB x64 (Build 19044.5131)
Syslinux versions: 4.07/2013-07-25, 6.04/pre1
Grub versions: 0.4.6a, 2.12
System locale ID: 0x0409 (en-US)
Will use default UI locale 0x0409
SetLGP: Successfully set NoDriveTypeAutorun policy to 0x0000009E
Localization set to 'en-US'
Notice: The ISO download feature has been deactivated because 'Check for updates' is disabled in your settings.
Found 517 revoked UEFI bootloaders from embedded list
Found USB 2.0 device 'Philips USB Flash Drive USB Device' (13FE:5500)
1 device found
Disk type: Removable, Disk size: 32 GB, Sector size: 512 bytes
Cylinders: 3773, Tracks per cylinder: 255, Sectors per track: 63
Partition type: SFD (Super Floppy Disk) or unpartitioned
Scanning image...
ISO analysis:
  Image is a UDF image
Disk image analysis:
  Image does not have a Boot Marker
Could not mount image 'C:\Users\xxxxxxx\Downloads\en-us_windows_11_enterprise_ltsc_2024_x64_dvd_965cfb00.iso': [0x00000079] The semaphore timeout period has expired.
Could not mount Windows ISO for build number detection
ISO label: 'CES_X64FREV_EN-US_DV9'
  Size: 4.8 GB (Projected)
  Has a >4GB file
  Uses: EFI
  Uses: Bootmgr (BIOS and UEFI)
  Uses: Install.wim (version 0.13.1)
Using image: en-us_windows_11_enterprise_ltsc_2024_x64_dvd_965cfb00.iso (4.8 GB)

[pbatard]

Please retry with Rufus 4.6, if you only ran one test with 4.6 and then switched to 4.5, as there has been no change in the scanning code between the 2 versions.

My guess is that the disk where the image resided was being accessed by another application (backup software, security solution) which of course would drastically make the scanning process slower regardless of the version of Rufus being used.

Also, please bear in mind that Windows may cache recently opened file, so you might have very slow access (if your source drive is slow for any reason) on first access, but much better speed on subsequent ones.

Therefore, if you just tried Rufus 4.6, found that it was slow, switched to 4.5, found that it was better, and did not retry Rufus 4.6 afterwards, then your results are inconclusive.

At any rate, the scanning is a mandatory part of Rufus' process. There is literally no point in opening an image if it's not going to get scanned, as Rufus will not be able to do anything with it. So the suggestion to ask the user whether they want to scan the image is not something I can even remotely consider.

You also want to make sure that you don't have a security solution interfering with Rufus, where you might have whitelisted Rufus 4.5 (in which case your security software would not interfere what it is trying to access) but not Rufus 4.6.

I find that a lot of "Rufus version X is broken! The same thing works fine in version X-1" reports I get have to do with people who use heavy handed security solutions, where they whitelisted Rufus version X-1, but forgot to do the same with version X.

At any rate, I opened the image you pointed to on my machine (which is not a recent PC... its CPU is about 10 years old, and the image was also not saved on an SSD drive) and it scanned in less than 1 second, so I'm afraid I have to conclude that your issue is most likely purely environmental.

[Scampi-ml]

Thx for your reply. I am testing 4.6 again. Like you said "try it again" and i did. Inserted USB key, opened 4.6 and selected the same ISO. It loads instantly. I guess your right. HOWEVER as you said it may be a caching issue, so i changed the ISO from its original name to a _x in the file, just to create a new file.

It is still "stuck" on scanning. So ye every time you load a new ISO i needs to scan it? I don't think my drives are slow, i run dual Samsung 990 pro's in Raid 0, here is a bench of my current drives

Log

Rufus x64 v4.6.2208
Windows version: Windows 10 Enterprise LTSB x64 (Build 19044.5131)
Syslinux versions: 4.07/2013-07-25, 6.04/pre1
Grub versions: 0.4.6a, 2.12
System locale ID: 0x0409 (en-US)
Will use default UI locale 0x0409
SetLGP: Successfully set NoDriveTypeAutorun policy to 0x0000009E
Localization set to 'en-US'
Notice: The ISO download feature has been deactivated because 'Check for updates' is disabled in your settings.
Found 517 revoked UEFI bootloaders from embedded list
Found USB 2.0 device 'Philips USB Flash Drive USB Device' (13FE:5500)
1 device found
Disk type: Removable, Disk size: 32 GB, Sector size: 512 bytes
Cylinders: 3773, Tracks per cylinder: 255, Sectors per track: 63
Partition type: SFD (Super Floppy Disk) or unpartitioned
Scanning image...
ISO analysis:
  Image is a UDF image
Disk image analysis:
  Image does not have a Boot Marker
Could not mount image 'C:\Users\Scampi\Downloads\en-us_windows_11_enterprise_ltsc_2024_x64_dvd_965cfb00_x.iso': [0x00000079] The semaphore timeout period has expired.
Could not mount Windows ISO for build number detection
ISO label: 'CES_X64FREV_EN-US_DV9'
  Size: 4.8 GB (Projected)
  Has a >4GB file
  Uses: EFI
  Uses: Bootmgr (BIOS and UEFI)
  Uses: Install.wim (version 0.13.1)
Using image: en-us_windows_11_enterprise_ltsc_2024_x64_dvd_965cfb00_x.iso (4.8 GB)
Scanning image...
ISO analysis:
  Image is a UDF image
Disk image analysis:
  Image does not have a Boot Marker
Could not mount image 'C:\Users\Scampi\Downloads\en-us_windows_11_enterprise_ltsc_2024_x64_dvd_965cfb00_x - Copy.iso': [0x00000079] The semaphore timeout period has expired.
Could not mount Windows ISO for build number detection
Disk type: Removable, Disk size: 32 GB, Sector size: 512 bytes
Cylinders: 3773, Tracks per cylinder: 255, Sectors per track: 63
Partition type: SFD (Super Floppy Disk) or unpartitioned
Failed to scan image

---

at this time it is still on "canceling - please wait" afther that =>

[pbatard]

Well, you are also getting:

Could not mount image 'C:\Users\Scampi\Downloads\en-us_windows_11_enterprise_ltsc_2024_x64_dvd_965cfb00_x.iso': [0x00000079] The semaphore timeout period has expired.
Could not mount Windows ISO for build number detection

which isn't normal.

You may alos have misconfigured your PC when it comes to the ability of mounting ISOs (which is a native Windows facility provided by Microsoft since Windows 8 and that is expected to work fine on a vanilla PC).

In short, you also need to look at your PC configuration to understand why applications like Rufus cannot mount ISOs, because there's no reason it should produce an error.

All in all, it still smells like interference from a dodgy security solution, like an overzealous antivirus or something...

[Scampi-ml]

Oh i don't have a antivirus, just stock windows defender crap :) Could that error be because i canceled the scanning process? I did hit cancel.

OK, so new test:

• Closed rufus, and started 4.6 again
• Same ISO (with _x in the filename) opens instantly
• Load a new iso (dvd_965cfb00_x - Copy.iso) needs to scan again => Scanning image...
• Load ISO (with _x in the filename) needs to scan again => Scanning image...

So it can hold only 1 ISO in cache?

[pbatard]

The cache issue is just a supposition. I'm afraid it's up to you to troubleshoot what it is in your environment that is causing the issue. I have really have no insight on what it might be, and, as you may understand, there's only so much time I can spend trying to formulate hypotheses and have you try to validate them, when nobody else is encountering this issue.

At some stage, environmental issues do become the responsibility of the person who encounters them to troubleshoot them on their own... Sorry.