Booting from USB 3.0 with UASP enabled results in a BSoD

[mariobalanica]

• With rpiuxflt installed and uaspstor enabled, booting from UAS drives connected to USB 3.0 results in an INACCESSIBLE_BOOT_DEVICE BSoD.
  Connecting the drives after Windows has booted (from SD for example) works fine in this case. (I haven't done any stress testing yet, so they might as well fail under load).

• With rpiuxflt installed and uaspstor disabled, booting from UAS drives connected to USB 3.0 works fine.

• Without rpiuxflt + the 3 GB RAM limit enabled in UEFI and uaspstor enabled, users have reported that USB 3.0 boot from UAS drives works fine (though I'm personally not able to replicate the success in this case, as my drive keeps on hanging Explorer and anything trying to access it, so booting from it is out of the question).

UAS drives connected to USB 2.0 and non-UAS ones connected to any port work flawlessly in every scenario.

[alotipac]

Can you try increasing the number of bounce buffers as shown in alotipac/rpi-windows-drivers@468ff19? This commit also adds an explicit blue screen if there are no more buffers. The driver stack ignores the error previously returned in this case, leading to an arbitrary and misleading crash somewhere else. I was able to install 19042 on an 8 GB device booting off a UAS drive on a USB 3 port with this change, but more testing should be done to make sure this is an acceptable buffer count and that it doesn't cause issues with non-UAS drives.

Allocating large amounts of contiguous memory like this should probably be avoided. Making the allocations dynamically could be tricky since AllocateCommonBuffer must be called at passive level, while GetScatterGatherList can be called at dispatch level. We could also make the count a driver registry setting if necessary, but it probably wouldn't be configurable until after first boot when the driver is fully installed.

[mariobalanica]

@alotipac I've applied your patch and did a clean install. First boot is okay, it reaches the "Getting ready" phase, reboots as expected, but then it stays for a while at the boot screen and finally crashes with UNMOUNTABLE_BOOT_VOLUME.
Increasing the number of bounce buffers even more has no effect (tried up to 512).
I've asked someone else to test as well, and they got the same results.

However, having the count set to 128 does certainly help. I'm now able to run CrystalDiskMark on the UAS drive when booted from SD, which previously resulted in random disconnects.

I'm thinking there may be something wrong with the uaspstor driver, as I'm not able to use my UAS drive at all without the filter driver (the RAM is limited to 3 GB). It gets detected but shortly becomes unresponsive.
We've also seen reports that booting from UAS drives works fine on build 19041.330. Not sure why this specific build, but I'll test it myself and report back.

[mariobalanica]

No success with build 19041.330.

[mariobalanica]

Workaround merged here: 35d6c68

Will keep this issue open until the root cause is fixed.

[idigdoug]

I configured my RPi4 with no filter driver, just 3GB ram and the compatibility flags. In this configuration, UAS works or does not work, depending on device model:

• JMicron device: UAS hangs immediately.
• RTL9210 device: UAS hangs immediately.
• ASMT2235 device: UAS works great.