Install DebugView as was requested from the log that you decided to ignore and provide a log.

Yes, even if the application disappears or crashes, you will get a log from DebugView.

Unless you do provide a log withing 24 hours, I will simply close this issue as I don't have ANY details that allow me to even remotely start to help you.

I need to know the ISO you used, and where exactly you downloaded it. It appears that the application crashes when parsing the ISO, which means that, unless I can get access to that specific ISO, I'm not going to be able to do much...

I need to know the ISO you used, and where exactly you downloaded it. It appears that the application crashes when parsing the ISO, which means that, unless I can get access to that specific ISO, I'm not going to be able to do much...

I downloaded ios via rufus

I downloaded ios via rufus

It still doesn't tell me what ISO it was. The ISO has a name, architecture, language, etc. What are they?
And do you actually observe a crash with an error, or does the application just go away.

Please bear in mind that I am not in front of your computer, I don't have access to your data and I can't read your mind, so you have to provide enough details for us to try to help you, as I still don't have enough data to do anything about your issue here.

No, I am asking about the version of Windows you downloaded through Rufus. Windows version: Windows 10 Pro x86 (Build 19045.3086) is the version of Windows you are running on.

When you downloaded the ISO from Rufus, as you state you did, you selected:

• A version of Windows (Windows 11, Windows 10, Windows 8)
• A release of Windows (most likely 22H2)
• A language
• An architecture

And then after the download completed, you ended up with a .iso file in the folder where you chose to download it, and that .iso file has a name, such as Win11_22H2_EnglishInternational_x64v1.iso.

I need to know all of these details.

And do you actually observe a crash with an error, or does the application just go away.

I did not notice an error that occurs, that the application disappears at the beginning of burning

It still doesn't tell me what ISO it was. The ISO has a name, architecture, language, etc. What are they?

Win10_22H2_Arabic_x32v1

I did not notice an error that occurs, that the application disappears at the beginning of burning

So you can press START after you selected the ISO?

In that case the log you provided with DebugView is incomplete because there should be additional lines after:

00000078	17.56792259	[6040]   Image does not have a Boot Marker 	

So, can you press START after you select the ISO, and do you get any additional lines in DebugView after Image does not have a Boot Marker?

So you can press START after you selected the ISO?

no

@JonnyTech, I missed that you weren't OP when replying, which didn't really help with trying to get the data needed. Windows 10, which is what OP uses, does have 32-bit versions. It's only Windows 11 that dropped x86_32 support.

So, can you press START after you select the ISO, and do you get any additional lines in DebugView after Image does not have a Boot Marker?
DESKTOP-4N1770N.LOG

I tried again and this reading of the problem and error

@Tarq2, thanks, I can finally replicate your issue!

It only seems to happen when using the _x86 version of Rufus (64-bit is fine), and I can also see it when scanning other Windows ISOs besides Win10_22H2_Arabic_x32v1.iso.

This also appears to be an issue that's restricted to the MinGW built version and not the MSVC built version, because as far as I can see, the MSVC built x86 version does not crash (because if it did, I would have seen reports from Windows Store users, who use an MSVC build).

@Tarq2, can you please try installing the official Rufus App from https://apps.microsoft.com/store/detail/rufus/9PC3H3V7Q9CH and see if that works better for you?

Now that I finally have enough data, I will of course try to figure out why the x86 MinGW crashes while parsing these Windows ISOs...

The issue appears to have to do with the delay loading of the virtdisk library which we enforce to prevent hijacking of the application through DLL side loading (See #1877).

From what I can tell, for MinGW32 only (i.e. MinGW64 does not have this issue) we run into the same problem as the one I described here, with the MinGW delay loading code producing a literal "That's it, I'm outta here" from the runtime when it encounters an issue.

More specifically, after a Windows ISO is scanned, we try to detect the Windows build from that ISO by mounting, using the Windows virtdisk APIs so we can poke at the relevant files. And it looks like the delay load call to OpenVirtualDisk() from MountISO() crashes the whole app when it's the x86 MinGW32 compiled version.

And, no, this is not an overall issue with delay loading for MinGW32, as we have other delay loaded calls in the application, and especially one that validates the ISO download script before we launch it, and those ones do not produce a crash.

<Sigh> I guess it's back to direct hooking into DLL API calls, like I had to do for wininet, since neither Microsoft nor MinGW are of any actual help when it comes to preventing side-loading vulnerabilities...

@pbatard just out of curiosity, is it only foreign language ISO's or Windows hosts? I contacted the others that I mentioned earlier and they claim to have no issue with English ISO's and English 32 bit Windows. Yet they still won't provide a log!

@JonnyTech i cant say if english US ISOs are affected (as I don’t want to download ISOs that aren’t of any use to me), but i tested an English International 32 bit ISO on one of my systems, and it caused Rufus to crash (when using the 32 bit version of Rufus)

It's all the recent Windows ISOs that I've tested, English, other languages, x86/x64, whatever, which makes sense since it's a crash as soon as a specific function call is invoked, and that function call will be invoked for any modern Windows ISO.

Please be very mindful that:

• This will not happen with any x64 version of Rufus
• This will not happen with the x86 version from the Store either, since that one was compiled with MSCV and delay loading in MSVC uses a different method.

Currently, the only release where you will see the crash is the rufus-4.1_x86.exe version from https://rufus.ie, since this issue was introduced in the second commit [0df68b6] we added after the 4.0 release, where we switched to delay loading the virtdisk library.

I downloaded ios X64, unlike I previously installed ios X86, and it booted successfully. Please wait for the installation to complete and then come back and report that the issue has been resolved

The problem exists

What is the version of Rufus that fits my system?

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.