Windows booted by Quibble cannot recognise/format FAT/FAT32 partitions

[HueponiK]

When I boot my stock windows10 on NTFS, using normal windows bootloader, I see:

DISKPART> list vol

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0         efi          FAT    Partition     32 MB  Healthy
  Volume 1         efi          FAT    Partition     32 MB  Healthy
  Volume 2     C                NTFS   Partition    100 GB  Healthy    Boot
  Volume 3         esp          FAT    Partition     64 MB  Healthy    System

But when I use quibble to boot exact same windows, I see

DISKPART> list vol

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0                      RAW    Partition     32 MB  Healthy
  Volume 1                      RAW    Partition     32 MB  Healthy
  Volume 2     C                NTFS   Partition    100 GB  Healthy    System
  Volume 3                      RAW    Partition     64 MB  Healthy    Hidden

I've checked with trying to format a vhd to fat16 or fat32 - it fails

Seems like it's not loading some fat driver/service

Probably offtopic, but c: shows as Boot in native bootloader and System when using quibble

[HueponiK]

Please note, I am using latest release (Version 20230328), and not building the latest from mater

[maharmstone]

It looks like maybe Windows hasn't added fastfat to the Quibble hardware profile.

Does sc start fastfat make it work?

[HueponiK]

It looks like maybe Windows hasn't added fastfat to the Quibble hardware profile.

Does sc start fastfat make it work?

Yep! That did it. Curious what else is missing. Gonna try to produce running services diff

C:\Users\deck>sc start fastfat

SERVICE_NAME: fastfat
        TYPE               : 2  FILE_SYSTEM_DRIVER
        STATE              : 4  RUNNING
                                (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0
        PID                : 0
        FLAGS              :

C:\Users\deck>diskpart

Microsoft DiskPart version 10.0.19041.964

Copyright (C) Microsoft Corporation.
On computer: HOST2

DISKPART> list vol

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0         efi          FAT    Partition     32 MB  Healthy
  Volume 1         efi          FAT    Partition     32 MB  Healthy
  Volume 2     C                NTFS   Partition    100 GB  Healthy    System
  Volume 3         esp          FAT    Partition     64 MB  Healthy    Hidden

[HueponiK]

Here are the services and drivers lists and the diffs, in case anyone is interested debug.zip

Looks like the following 4 aren't started, status 1077 (ERROR_SERVICE_NEVER_STARTED)

UEFI
fastfat
intelpep
Telemetry

[SzczurekYT]

I wouldn't worry about the last one not being started 😄

[maharmstone]

As I understand it, what happens is that the bootloader creates a hash of what it thinks the hardware is, and if this ever changes Windows does a full rescan of what drivers to load on boot. If you've ever broken Windows 7 by switching between IDE and AHCI in the BIOS, you'll understand the need for this. Quibble has this hash hard-coded to 0.

So I'm not sure whether this is a Quibble bug (we should be loading fastfat even though it's not needed for boot), a Windows bug (Windows should be adding fastfat to its driver list when the hardware hash changes), or not a bug at all (Windows isn't loading a driver it doesn't need, as the EFI partitions are hidden). Maybe it just warrants a note in the README.

[HueponiK]

Thanks, this solves the fat issue

[maharmstone]

I've added something to the README about this now.