Rufus may attempt to reformat UEFI:NTFS partition on Windows 10 1703 (Creators Update)

[pbatard]

Now that Windows mounts all partitions from removable drives, instead of just the first one it recognizes, it is possible to end up in a situation where, when UEFI:NTFS is being used, Windows will assign the UEFI:NTFS the letter that Rufus expects the main NTFS partition to use, and thus, Rufus will try to reformat the UEFI:NTFS partition:

Format operation started
Requesting disk access...
Opened \\.\PHYSICALDRIVE5 [\Device\Harddisk5\DR6] for write access
No drive letter was assigned...
Will use 'G:' as volume mountpoint
Analyzing existing boot records...
Drive does not have an x86 Master Boot Record
Volume does not have an x86 Partition Boot Record
Clearing MBR/PBR/GPT structures...
Erasing 128 sectors
Deleting partitions...
Partitioning (MBR)...
Adding extra partition
Reserved 33 tracks (1 MB) for extra partition
Writing UEFI:NTFS partition...
Closing existing volume...
Waiting for logical drive to reappear...
Formatting (NTFS)...
Using cluster size: 4096 bytes
Quick format was selected
Volume is too small
Format error: The volume size is invalid.
Re-mounted volume as 'G:' after error
The thread 0xa70 has exited with code 0 (0x0).

[NSbuilder]

I had an issue lately that rufus 2.13 make the uefi:ntfs visible ( with a drive letter ) when using Windows 10 anniversary ( or it was Windows 10 creators update... I don't remember ) to make a bootable usb with the creators update ( dual bios and uefi mode ).

Unfortunately, I forgot to take the log and when I tried in another computer it didn't seemed to do that ( In the second computer I have used a vhd so maybe that's why the issue didn't occur ).

[pbatard]

I had an issue lately that rufus 2.13 make the uefi:ntfs visible ( with a drive letter )

It's not Rufus. It's Microsoft, with a NEW behaviour of Windows 10 1703 (Creators Update).

Before Creators Update, and for REMOVABLE drives (most USB flash drives are REMOVABLE, most USB HDDs are FIXED), Windows would only mount the first partition with a file system it recognized, and this regardless of how many other partitions your drive has, with file systems that Windows can mount. The only drives for which it would mount multiple partitions were FIXED drives.

This was a MAJOR drawback of using Windows, and, with Creators Update, Microsoft decided to change it. This means that, as far as mounting partitions is concerned, Windows will now treat FIXED and REMOVABLE partitions the same way. They may also have applied additional changes with regards to mounting EFI System Partitions.

As a result, the UEFI:NTFS partition, which sits at the end of the flash drive, will be mounted automatically (along with the other partition from the drive) in Windows Creators Update, whereas this is not the case with previous versions of Windows.

This is actually this change in Windows behaviour that prompted me to log this enhancement, so that Rufus, who indirectly relied on the old Windows behaviour, will not access the mounted UEFI:NTFS partition by mistake.

[pbatard]

Oh, man, what a pain in the ass this enhancement is turning out to be!

Disk Manager and other Windows components seem to be completely thrown off at times, by the presence of the UEFI:NTFS partition, and completely fail to register the main one.

Since I suspect there's either an underlying Windows bug (either that, or Microsoft is trying hard to shoot down competing software's innovative ideas), I think the best thing I can do is detect if we are going to format the UEFI:NTFS partition and ask the user to try again...

[NSbuilder]

I think the idea to let the user display and use all the partitions in the same time regardless REMOVABLE / FIXED drive is quite awesome. However, it's a big mistake to make this change default for all users - I think this is something that should be enabled using registry editor or group policy but they made it enabled on default? I think it will just confuse people and make it harder for developers...

That's means that, on the creators update, it's useless to have Rufus check if drive is removable or fixed and cheat modes like Alt-F (Enable USB HDD detection) are useless?

[pbatard]

it's useless to have Rufus check if drive is removable or fixed

Not at all. I think you misunderstand what this change brings. It still does NOT make a REMOVABLE drive behave like a FIXED drive. For instance, you still will NOT be able to use a REMOVABLE drive for Windows To Go, and flash drives will still be detected as REMOVABLE (which means that, the part of the fixed disk detection that checks the drive type will still apply... but just so you know, Rufus does a lot more behind the scenes to determine whether a USB device is a flash drive or an HDD than check if it has the FIXED or REMOVABLE type).

All this does is bring one of the behaviours, that Microsoft had willingly restricted to FIXED drives, to also apply to REMOVABLE. But there are still plenty of REMOVABLE only behaviours that have not been changed.

Oh, and you're welcome to provide feedback to Microsoft if you think this is a mistake.

[pbatard]

Notes for myself - to replicate this (using 32 GB microSD + adapter on Win10 1703):

1. Make sure dual BIOS+UEFI is selected
2. Open en_windows_10_multiple_editions_version_1703_updated_march_2017_x64_dvd_10189288.iso
3. Create the drive for MBR/NTFS
4. Cancel during file system creation
5. Alt-Z then cancel at 0.3%
6. Create the drive again

Since it works on retry, reporting ERROR_RETRY to the user should do it.

[lock[bot]]

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.