That DLL is then taken by GetDefaultAppInfo to be the correct thing to pull the VersionInfo from. This is a COM thing it contains a CLSID which can then be used to look up the path to a DLL containing an in-process COM server implementation (if that fails we look for an out of process one, but here we don't get that far).
For UWP apps, that key won't exist, so we'll fall back to look for a DelegateExecute value. The first way it tries to find the right file is to look in the shell open command line key. On the code path we're interested in here, this function looks up a given ProgID string in HKEY_CLASSES_ROOT (for a UWP app, the ProgID is a string starting with 'AppX' and then some random characters) and attempts to resolve it to a human-readable description by finding the file used to launch the associated application and looking up the description from that file's VersionInfo resource. We initially get the string 'TWINUI' from the function nsOSHelperAppService::GetDefaultAppInfo. I was inspired to spend a bit of time looking into this, and I don't have a solution, but I know more about what's going on, so I though I'd leave some notes here.
