UEFI driver for NTFS filesystem hangs UEFI Shell on Workstation Pro 15.5.6?

[aturnbul]

There is an excellent collection of open-source code for read-only UEFI drivers on GitHub called EfiFS. The NTFS driver used to compile with Visual Studio or EDK2 and the result worked well in the UEFI Shell included with Workstation and Player, I'm told). I've recently (2020-08-10) tried the latest version of EfsFS and compiled it with VS2019 Enterprise 16.7.1 and EDK2 (2020-08-10 branch). The resulting driver, ntfs_x63.efi, works with other hardware emulators and loads successfully on Workstation Pro's UEFI Shell (2.31), but the shell hangs when you try to connect the driver to a device. I haven't tried the other drivers yet - ntfs was the first attempt.

Has anyone else experienced this or, perhaps, even solved it? Any ideas how I might chase down the issue? Thank you for any ideas or comments.

[wila]

Hi,

For UEFI questions at the forum dariusd​ is "da man".

Hopefully he has some time to answer your questions (also for the other thread you posted).

Maybe this earlier reply from Darius can help to get you started.

EFI Debugging

--

Wil

[dariusd · Accepted solution]

Thanks for the mention, Wil!

The EFI firmware in Workstation 15.x is based upon the UDK2017 release of EDK2, and is built with a somewhat-ancient GCC 4.5.  We're also using the very ancient "Shell 1" from the GccShellPkg which was removed from EDK2 years ago.  In theory, none of that should matter, but ... sometimes it does.

My first suggestion would be to try using a newer UEFI Shell instead of ours, juuuust in case the Shell is getting in the way somehow.  Just grab a recent Shell binary and put it into a disk's EFI\BOOT\BOOTX64.EFI and you should be able to launch it directly from the EFI Boot Manager – for various reasons, this approach should be much preferred versus launching the new Shell from our old Shell.  Note that there have also been wrinkles reported with running the new Shell on our firmware, so ... you might end up bouncing off a variety of hangs/crashes along the way.  But it still might yield an interesting data point if you can get the driver to successfully connect under the new Shell but not the old.

--

Darius

[aturnbul]

Thank you for the responses and the details on the origin of the current firmware. I tried a shell built from the 2020-08-10 branch of EDK2 compiled with VS2019 Enterprise 16.7.1. The shell seems to work well in a vanilla VM, but I didn't exercise it extensively. It turns out that the driver does hang in the new shell as well as the old (it hangs during the reconnect phase, the load is fine). I also tried the driver in a bare-bones QEMU machine with the OVMF firmware and it hangs there, too (but in a different place).

I'm currently working my way through the source code and using a debugger to see what's happening. So far it seems that, while probing partitions on the next reconnect, the driver gets confused when it encounters an unformatted Reserved partition on a GPT disk before it encounters anything else. In any case, I don't think this is a problem for Workstation unless you've implemented a native boot-from-NTFS protocol (have you?).

Thanks again for your help.

[abqedu]

Hello @dariusd , for some unknown reason your document Using EFI/UEFI firmware in a VMware Virtual Machine is no available anymore. Can you please verify it and share it again ?

Kind regards,

[wila]

Wow, nice article.
I'll put a request in to see if vmware is willing to put it back, meanwhile... you can find it here:
http://web.archive.org/web/20200731035024/https://communities.vmware.com/docs/DOC-28494

--
Wil