Forum Discussion
PackageDependencies and RtlDosApplyFileIsolationRedirection
For security purposes, we would prefer to keep all of the VCRuntime dlls out of MSIX packages and instead replace them with Microsoft.VCLibs.xxx package dependencies.
For most applications (being repackaged), we can simply remove the files from the package and add the dependency in the AppXManifest file. LoadLibrary happily finds the files in the dependency package without need of the PSF.
There are applications, however, that have folders containing numerous managed dlls along with the VCRuntimes in a folder, and use an internal manifest in the exe that includes a
Dependency / dependentassembly / Assemblyidentity that lists the folder,
and then an external manifest in that folder that lists all of the dependent dlls to be loaded.
When the application process is launched, the internal manifest is processed and we see the dlls listed in the external manifest being located using the API RtlDosApplyFileIsolationRedirection rather than load library.
It appears that this API does not look at the location containing AppXManifest PackageDependencies thus the dlls are not found and the launch of the exe fails. The PackageDependencies should always be respected or they are useless.
I have an example package (Blender) that has this condition if you'd like to look at it.
2 Replies
When "the launch of the EXE fails" what is the nature of the failure? I'm investigating an unpackaged app that fails to launch due to an access violation at RtlDosApplyFileIsolationRedirection.
The error message is application vendor specific, but some form of file not found or outright crash.
But the request here is in this post is specific to the packaged app case, as that is where the dependent dlls not found would be in a separate framework package.
For now, we are forced to either keep the vcruntimes inside the package, or remove them but use a native install of the old vcruntime libraries natively rather than the more easily managed framework package.
