AMI NTFS UEFI driver bug while using Rufus latest release (4.7p)

Hi everyone.

It's me, the greenhorn/housewife/tech-dinosaur, trying to learn a bit more again. Hoping for help regarding a driver bug. Here's the story:

I'm trying to install Win 11 Home 23H2 on a new computer we just assembled this month (first time DIY build, specs provided in my profile). @antspants kindly shared a couple of Win 11 Home ISOs with me, one in US English (build: 2861), and one in UK English (updated March 2025), so my husband could choose which one he wanted.

I used an up-to-date Google Chrome browser and the US English ISO downloaded without any interruptions. But some interruptions happened during the UK English ISO download, and I had to click 'resume' maybe 3-5 times to get it to complete. I've never downloaded large files like this before. I don't know if download interruptions can lead to any kind of corruption/missing stuff in the file or not. So just in case that might be a potential issue, we decided we would go with using the first (US English) ISO to make the bootable USB with Rufus. (The plan was to get it installed, do the 'tweaks' to make the system stay on 23H2 til EOL, then let the system bring 23H2 fully up to date).

So, in Rufus (the latest version, 4.7p) I did this:
Device: Kingston, 64 GB, NTFS.
(I did the sha-1 checksum thing mentioned on the Rufus github FAQ page and it showed a good match. Antspants is also sure the ISOs are fine, from a trusted source, and they have worked well for him. He still uses the US English one if he reinstalls Win 11.)
Device properties: Standard Windows Installation, GPT partition scheme, UEFI (non CSM) target system.
I clicked to enable runtime UEFI media validation. (A mistake maybe?)
Format options: file system-NTFS, cluster size-default.
I checked the advanced options for 'quick format', 'create extended label and icon files' and 'check device for bad blocks'. (There were no messages about any kind of bad blocks.)
Customization: I choose all except the region one and the one about secure boot & TPM since Rufus says secure boot doesn't have to be disabled anymore with its newest versions.

The USB booted the new computer easily and promptly. But then we got 3 warning messages on the screen. I'm not sure I fully understood what happened, but it seemed like maybe (?) it was because of me clicking to enable runtime UEFI media validation when doing the USB setup in Rufus? Because the new computer's screen warnings talked about md5 checksum stuff and referred to an AMI NTFS bug, telling us to read about it here: GitHub - pbatard/AmiNtfsBug: AMI UEFI NTFS driver bug test application

Seems like this driver bug creates vulnerabilities for persistent malware to get through the secure boot and settle in the UEFI, though it's only considered low risk of that happening. (Not sure what their definition of 'low risk' would be.) For us, though, we need to minimize risk as much as possible because we'll have to be doing sensitive work stuff on it as well as banking, government/tax, and healthcare stuff. So I feel a need to find out how to fix the vulnerability.

I cancelled the installation and then I tried to remake the installation USB with the 2nd ISO instead (the UK English one with march 2025 update). But I got the same notification from Rufus about a UEFI bootloader being revoked (which happened with the first ISO). That makes me think we'll get the same warning messages about the buggy AMI driver again, if we try the 2nd ISO for installation.

When I tried reading about the AMI buggy driver situation at the github link, as well as googling a bit and trying to search the forum here, I couldn't find hardly any info at all. What little there was felt like very confusing Greek to us and I couldn't find a simple layman's explanation about how to deal with the situation. We saw down near the bottom of that github page that it said, "using the UEFI NTFS driver from Releases · pbatard/ntfs-3g (unload the AMI NTFS driver and load the ntfs-3g one) does make the issue disappear." But I don't know how a person would unload or load these drivers in this situation. Not sure if the drivers are located in UEFI, or in Rufus, or in the Rufus-prepped USB. Don't suppose you have any tips for how to handle the buggy driver issue? or any links that might not have come up in my searches that could explain what to do, step by step?

In the release notes for the older Rufus 4.5 version, it said:

• Update UEFI:NTFS to latest (now always uses the ntfs-3g driver, rather than the buggy AMI NTFS one)
• Increase buffer size when copying ISO files, in an attempt to minimize the AMI NTFS UEFI driver bug

so we're a bit surprised to be getting the AMI buggy driver issue with Rufus latest release (4.7p). Antspants said he recalls this subject being talked about in the forum before but he can't find it and I couldn't either when I tried searching. (What else can I say?... Fast boot is disabled in the UEFI. Secure boot and TPM 2.0 were enabled by default in UEFI. I didn't try to change anything about that in the UEFI or in Rufus USB customization box since Rufus FAQ page said secure boot shouldn't have to be disabled when using newer versions of it.)

(Sorry for the long yarn about it. I wasn't sure how much info you would or wouldn't need, so I thought I should just tell it all...) Thanks for any help you might be able to provide. :)

Trying to learn said:

kindly shared a couple of Win 11 Home ISOs with me

Click to expand...

They’re Pro versions.

And to be transparent. The US English one was mine, works fine for me.
The UK English version I recently acquired and I’ve never tried it, but trust the member %110

If they’re installing the Home version, is it a laptop?
Probably due to an embedded version stipulated in the BIOS

There’s a fairly simple bypass for that. But you need to apply it (Edit the ISO) before you make the media with RUFUS

It’s should have both versions, at least the US ISO should. Multi-edition ISO

It should ask you during the beginning of the install

I accidentally deleted my comment. I was replying to @antspants and said, "Ohhh, wait a sec.. I'm confused. I thought you'd given me Win 11 Home ISOs? It's Home that we need for this new DIY desktop build, as we can't afford the license key for Pro (it costs a lot more than the Home key in our country and we're strapped just now due to work loss and prolonged illness expenses)."

antspants said:

It’s should have both versions, at least the US ISO should. Multi-edition ISO

Click to expand...

Oh, that's a relief. :)

antspants said:

It should ask you during the beginning of the install

Click to expand...

We never got that far because of the warnings during the bootup about the buggy driver. We cancelled the installation so we could try to find out more info and see if we could somehow fix the driver issue before doing the installation.

Just to be clear

Which version gave you the warning?
Did you try both ISO’s?
Even though the US English version is older, the first windows update should bring it up to speed

Something you should know about a Windows 11 comparable computer and Windows Update

When you run Windows Update, there’s every chance it will start downloading 24H2 to install

To prevent this, at first bootup, you’ll have to disconnect the Internet and run this tutorial to stop Windows Update from fetching 24H2

None of that helps with your original issue though.

If I understood the basics of the situation correctly, I guess maybe it boils down to 2 things?:
1) Rufus 4.7p isn't supposed to be using the buggy AMI driver anymore (as of version 4.5 onward) -maybe the man forgot to include that change also in 4.7 when he made it?
2) From the github page about the buggy driver, it seems like I'd have to "unload the AMI NTFS driver and load the ntfs-3g one", but I don't know how to do that (don't even know if the buggy driver is in the ISO itself, or in the Rufus-made USB contents, or in the UEFI?)

I wonder if I should just try downloading and using Rufus 4.5? (the one with the release notes that specifically say this issue is fixed)

Trying to learn said:

the one with the release notes that specifically say this issue is fixed

Click to expand...

The fix would have been carried over to newer versions.
I swear I read a few posts about this in forum but for the life of me can’t find the posts

Another thing, if this is a newer system, how come you’re using RUFUS?
Sorry of I missed something, it’s 2:30am here

antspants said:

Just to be clear

Which version gave you the warning?
Did you try both ISO’s?
Even though the US English version is older, the first windows update should bring it up to speed

Something you should know about a Windows 11 comparable computer and Windows Update

When you run Windows Update, there’s every chance it will start downloading 24H2 to install

To prevent this, at first bootup, you’ll have to disconnect the Internet and run this tutorial to stop Windows Update from fetching 24H2

Specify Target Feature Update Version in Windows 11

This tutorial will show you how to specify a TargetReleaseVersion version of Windows 11 you want to move to or stay on in Windows Update until it reaches end of service in Windows 11 Pro, Enterprise, or Education. Windows Update keeps Windows 11 updated by automatically downloading and...

www.elevenforum.com

Click to expand...

I changed the text of the OP here a bit from the private message I sent you last night, to add some more details. So I mentioned above that Rufus gave a message about revoked bootloader during the process of getting the USB ready the first time with the US English ISO. I just ignored it (per the Rufus FAQ section about that, since it seemed like it was just a matter of trust and we trusted that your ISOs were good. When I tried to install on the new computer, I got the buggy driver warnings before any installation could even begin. We thought the 'revoked bootloader' and 'buggy driver' warnings must be about the same thing. The screen gave me the option to continue with the boot or to cancel. I cancelled.

Then I checked in Rufus to see if the same thing would happen with the other UK English ISO or not. The same revoked bootloader message from Rufus happened again, so we assumed that meant we would also get the same buggy driver warnings if we tried to use that other ISO for installation on the new computer. So we didn't do it. We thought we should try to find out if there was any way to correct the buggy driver issue so that we wouldn't get those warning messages when trying to install with either of the ISOs you gave us.

Do you think if we had proceeded to complete the installation, then did the fix to force the system to stay in 23h2, then got the system to update itself, that those updates would fix the buggy driver issue? Or do you think it's something I should be trying to do PRE-installation, per my last comment above?

(re the 24H2 issue, yeah, I learned what I should do to 'freeze/lock' the system in 23h2, so it will only seek updates for 23h2 and not push 24h2 on us. I have step-by-step notes written down for doing that once the offline installation is complete.)

antspants said:

The fix would have been carried over to newer versions.
I swear I read a few posts about this in forum but for the life of me can’t find the posts

Click to expand...

same

antspants said:

Another thing, if this is a newer system, how come you’re using RUFUS?
Sorry of I missed something, it’s 2:30am here

Click to expand...

Ohhh, sorry it's so late there. Didn't mean to keep you up.

Rufus -because it's a completely new computer. It only has the UEFI at the moment and we need a way to install the OS on it. It has to be with a bootable USB (no optical drive in this computer). I don't know how to make a bootable USB. I could try to research that to learn, but Rufus is easiest for me, especially because it helps me bypass microsoft account and prevent bitlocker, which are the 2 things we definitely don't want or need.

I'm hoping it might somehow be a simple thing to "unload the AMI NTFS driver and load the ntfs-3g one" (as said on the Rufus github page about it) to fix the buggy driver issue. But they didn't say on that page how exactly to do that and I'm hoping somebody in the forum might know. (Being a non-techie, I also don't even know if the buggy driver is located in the ISO itself, or in the Rufus-made USB contents, or in the UEFI.)

Trying to learn said:

Ohhh, sorry it's so late there. Didn't mean to keep you up.

Click to expand...

You didn’t

Are these the settings you used to create the USB with RUFUS?

• Under Device, select the USB flash drive you want to format and use.
• Under Boot selection, click/tap on the SELECT button, and navigate to and select the Windows 11 ISO file.
• Under Image option (if available), select Standard Windows installation.
• Under Partition scheme, select GPT.
• Under Target system, select UEFI (non CSM).
• Under Volume label, you can enter any name you like for the USB flash drive, or leave the default name.
• Under File system, select FAT32 or NTFS.
• Under Cluster size, select the (Default) (ex: 4096 bytes) it has listed.

OR As the PC is going to support Windows 11

In a Brink tutorial in this forum:

• Option Three: Create Windows 11 Bootable USB Installation Media in Command Prompt

The US/English works. I’ve sent it to others. But this bug only popped up about mid last year if I recall correctly.

antspants said:

You didn’t

Are these the settings you used to create the USB with RUFUS?

• Under Device, select the USB flash drive you want to format and use.
• Under Boot selection, click/tap on the SELECT button, and navigate to and select the Windows 11 ISO file.
• Under Image option (if available), select Standard Windows installation.
• Under Partition scheme, select GPT.
• Under Target system, select UEFI (non CSM).
• Under Volume label, you can enter any name you like for the USB flash drive, or leave the default name.
• Under File system, select FAT32 or NTFS.
• Under Cluster size, select the (Default) (ex: 4096 bytes) it has listed.

OR As the PC is going to support Windows 11

In a Brink tutorial in this forum:

• Option Three: Create Windows 11 Bootable USB Installation Media in Command Prompt

The US/English works. I’ve sent it to others. But this bug only popped up about mid last year if I recall correctly.

Click to expand...

Hi again. :)

Yeah, it might've been in Feb or March of 2024 when it was discovered by Pete Batard and whoever else was doing the MD5 checksum project with him, if I understood his github page about it correctly. (GitHub - pbatard/AmiNtfsBug: AMI UEFI NTFS driver bug test application) I don't know if other people might've also found it before that time or not.

I don't know how long the AMI driver was being used before it was discovered to be buggy in this way, but Mr. Batard mentioned on his page that it's been in widespread use by ASUS, Gigabyte, Intel, etc.

Yes, I used exactly those Rufus settings (file system was set as NTFS) and a few more under the advanced options, as I mentioned in the OP.

Do you think the buggy driver is in the ISO itself, or is it something Rufus puts on the USB when it's making the USB bootable? I'm curious where the driver is actually located...

Trying to learn said:

Do you think the buggy driver is in the ISO itself

Click to expand...

I couldn’t tell you. Probably the ISO due to Microsofts UEFI blocklist (newish) which can disallow older boot loaders.

Have you tried disabling “Secure Boot” in the BIOS until Windows is installed? Then you should be able to re-enable it.

I suppose a definitive work around here, would be to go for broke with 24H2.
As much as there are some complaints, there are also many members who are doing fine with it.

I won’t install it on my main PC because it is 11 years old and it started acting up after new builds mid last year with 23H2, 24H2 didn’t improve anything. Hence my old ISO.

You’re new system may very well work just fine.

• Option One: Download Latest Windows 11 24H2 64-bit ISO using Media Creation Tool

Due to your internet issues, expect another 2 hours wait. What did the ISP eventually do or say? Did you compare the fibre options cost?