Rufus 4.14p not remembering Windows User Experience Settings

[zoomwaffle]

Checklist

• 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.
• I looked at https://github.com/pbatard/rufus/wiki/FAQ to see if my question has already been answered.
• 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.
• 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.
• 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.
• I also tried one or more of the following:
  • Using a different USB drive.
  • Plugging the USB into a different port.
  • 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'm using the portable version of Rufus and when I create a USB stick I clear all of the check boxes. In 4.13, this would work fine and the next time I built a USB stick my preferences would be remembered. In 4.14 the checkbox for "remove requirement for 4GB+ RAM, Secure Boot and TPM 2.0" always comes back checked even though I've cleared it.

Looking at the Rufus.ini file that's corrected, the WindowsUserExperienceOptions is set to 385810448. I've tried deleting this file and letting it be re-generated but the same thing occurs.

I believe this should be easy to re-create to confirm the issue!

Thanks!

Log

<FULL LOG>

[pbatard]

The prefs are remembered after you click OK in the WUE dialog (you still have a chance to cancel after that). They are not remembered dynamically as you alter them, and I have no plans to change that at this stage, because if you are not going to use the option set you selected, there's obviously no point in trying to persist them, even more so as then you might be wanting to know what they were the last time you actually proceeded forwards.

I am pretty sure this is your issue (I would be sure if you had provided the log, and infer that the reason you didn't provide one is because you didn't actually go through the creation process, hence your issue) so I will close this request.

[pineapple63]

There does seem to be some sort of issue with the WUE option to bypass system requirements not persisting, although it seems to only happen when no WUE options are selected

If i deselect all WUE options, click OK, and then click cancel on the warning that the drive will be erased, then click start again, it does not remember that i deselected it, and this also happens if i click OK on the warning and let it create the USB

Rufus x64 v4.14.2377
Windows version: Windows 11 Pro x64 (Build 26200.8246)
Syslinux versions: 4.07/2013-07-25, 6.04/pre1
Grub versions: 0.4.6a, 2.14
System locale ID: 0x0809 (en-GB)
Will use default UI locale 0x0809
SetLGP: Successfully set NoDriveTypeAutorun policy to 0x0000009E
Localization set to 'en-US'
Found USB 3.0 device 'SanDisk Ultra USB Device' (0781:5581)
1 device found
Disk type: Removable, Disk size: 28.6 GB, Sector size: 512 bytes
Cylinders: 3738, Tracks per cylinder: 255, Sectors per track: 63
Partition type: MBR, NB Partitions: 2
Disk ID: 0x000131D8
Drive has a Rufus Master Boot Record
Partition 1:
  Type: NTFS (0x07)
  Detected File System: NTFS
  Size: 28.6 GB (30749868032 bytes)
  Start Sector: 2048, Boot: Yes
Partition 2 (UEFI:NTFS):
  Type: EFI System Partition (0xef)
  Detected File System: FAT12
  Size: 1 MB (1064448 bytes)
  Start Sector: 60060420, Boot: No
Found 5 additional UEFI revocation filters from remote SBAT
Found 4 active Secure Boot certificate entries from remote
Found 1 revoked Secure Boot certificate entries from remote
Found USB 3.0 device 'SanDisk Ultra USB Device' (0781:5581)
1 device found
Disk type: Removable, Disk size: 28.6 GB, Sector size: 512 bytes
Cylinders: 3738, Tracks per cylinder: 255, Sectors per track: 63
Partition type: MBR, NB Partitions: 2
Disk ID: 0x000131D8
Drive has a Rufus Master Boot Record
Partition 1:
  Type: NTFS (0x07)
  Detected File System: NTFS
  Size: 28.6 GB (30749868032 bytes)
  Start Sector: 2048, Boot: Yes
Partition 2 (UEFI:NTFS):
  Type: EFI System Partition (0xef)
  Detected File System: FAT12
  Size: 1 MB (1064448 bytes)
  Start Sector: 60060420, Boot: No
Scanning image...
ISO analysis:
  Image is a UDF image
Disk image analysis:
  Image does not have a Boot Marker
UEFI bootloaders analysis:
  • /bootmgr.efi*
  Signed by 'Microsoft Windows Production PCA 2011'
  Note: This bootloader may fail Secure Boot validation on systems that
  have been updated to use the 'Windows UEFI CA 2023' certificate.
  • /efi/boot/bootx64.efi*
  Signed by 'Microsoft Windows Production PCA 2011'
  Note: This bootloader may fail Secure Boot validation on systems that
  have been updated to use the 'Windows UEFI CA 2023' certificate.
ISO label: 'CCCOMA_X64FRE_EN-GB_DV9'
  Detected: Windows 11 ISO (Build 26200.8037)
  Size: 8.0 GB (Projected)
  Has a >4GB file
  Uses: EFI
  Uses: Bootmgr (BIOS and UEFI)
  Uses: Install.wim (version 0.1.13)
Using image: Windows 11 25-H2 Release 1 [Build 26200.8037] English UK x86 64 bit Retail ISO.iso (7.9 GB)
Note: No Windows User Experience options selected

[pbatard]

Ah, now I see it. I read OP's report too fast and thought it was about when the persisted options are saved. I'll look into it.

[pbatard]

The issue was introduced in 92a8926 and is due to the fact that we factorize the code for radio button list selection (such as the Windows Edition for Windows To Go) where at least one option must always shown as selected by default, and where we force select the first one when there isn't one explicitly specified, and for checkbox list items, where an empty selection is allowed.

In the previous code, we simply passed a NULL element for selection_options for radio button list selection dialogs, as opposed to an actual selection_options struct that could contain a mask with a value of 0 for chekbox lists (and would therefore leave all checkboxes empty), but we have now introduced a more global selection_data struct where we added a new style attribute and other parameters, along with an options substruct that is never NULL by the time we decide whether we need enforce de first element to be checked or not. So we default to checking whether the mask is 0, but we forgot to also validate that the style attribute for the dialog should be set to BS_AUTORADIOBUTTON when we do that, and simply ignore it otherwise.

So, technically (but of course there's no way you can know that unless you look at the code) it's not a matter of not remembering the WUE option, but the UI enforcing the first element of the list dialog to be set if the (displayable) WUE options are empty. Oh and I should also point out that leaving the bypass options enabled has absolutely NO negative incidence or alteration with regards to the final Windows installation on systems that have a TPM. Exactly as you should expect for the RAM bypass (which of course isn't going to restrict Windows to using only 4 GB of RAM if it has more than that), the TPM bypass also in no way prevents Windows from using it (even if it somehow was disabled during installed and then turned back on).

At any rate, this should be an easy fix. Thanks for reporting. But please bear in mind that if you want me to properly look at an issue, you should always provide a log, as requested, as I do speed-read reports that ignore the check list requirements.

[github-actions]

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.