MSIX installed application on Windows 10 cannot access host machine graphics

[farmerphd]

Hello All,

I am developing a Microsoft Application that is installed with a MSIX installer. The structure of the application is a *.exe application that is identified as the primary application (all shortcuts point to the *.exe file). It installs outside the VFS file structure.

There is a runtime component that needs to install with the primary *.exe file. It installs in the VFS/ProgramFilesX64 directory. I added a registry entry (virtual registry) that points the *.exe file to the runtime installation.

The application launches and an error 'openGL is not installed'. I separated the runtime component into its own MSIX package, installed it without an executable, and modified the registry of the *.exe to point to the other application. A second MSIX package only installs the primary *.exe file and it works fine.

My thinking is that when the *.exe 'reaches' outside it's MS app container, it is granted graphics access on the host machine. If it doesn't reach outside (the first scenario where it accesses the runtime inside the same application VFS directory) it doesn't get graphics access from the System.

Does this make sense and is there a solution? Ideally, I want all the application to install with just one MSIX installer. I tried to add a virtual registry for the host machine SYSTEM to give the *.exe an identity with access to graphics but it gave an error when I tried to install it.

Thanks in advance for any guidance.

[#2]

@farmerphd 

Hi, can you please check the logs using procmon? Where exactly is the main application trying to access run time component from?

Also, when you are creating a separate package for runtime - what kind of a package is that?

[#3]

The MSIX packaging format is designed to provide a containerized and secure environment for applications, and this might affect how your application interacts with the host system, especially when it comes to graphics access. Here are some suggestions:

Graphics Capabilities in MSIX:

MSIX packages are designed to be self-contained and isolated from the system to enhance security and portability. However, this isolation might limit certain interactions, especially when it comes to low-level system components like graphics drivers.
Dependency on OpenGL:

If your application relies on OpenGL and the error suggests that it is not installed, it's worth exploring whether your MSIX package includes the necessary OpenGL components. You might need to ensure that the required libraries are included in your package.

-Separate MSIX Packages:

You've mentioned that separating the runtime component into its own MSIX package works. While this might not be your ideal solution, it could be a viable workaround. You can consider using the MSIX package dependencies feature to manage the relationship between the two packages.
-Check Graphics Driver Dependencies:

Ensure that the host machine has the necessary graphics drivers installed. Sometimes, issues with graphics access can be related to missing or outdated drivers.
Registry Entries and Permissions:

Verify that the registry entries you are using to establish connections between components are set up correctly and that the necessary permissions are granted.
-Check App Capabilities:

Ensure that your MSIX package declares the necessary capabilities in the manifest. For graphics-related capabilities, you might need to declare access to certain resources.
-Logging and Diagnostics:

Implement logging and diagnostics in your application to get more detailed information about what might be causing the OpenGL error. This can help you pinpoint the issue more precisely.
-Engage with Microsoft Support:

If you've exhausted all options and are still facing difficulties, consider engaging with Microsoft Support. They can provide more detailed assistance based on the specifics of your application and its requirements.
Community Forums:

Check Microsoft community forums or developer forums for MSIX-related discussions. Other developers might have faced similar issues and could provide solutions. Always ensure that you are using the latest version of the MSIX packaging tools and platform.

[#4]

@Eyad-thank you for your suggestions. I explored most of these options except ensuring the manifest has the required declarations. MSIX is a great, containerized solution so will keep working to have the fully functioning MSIX package. The best solution may be for me to separate the runtime needed from the myapp.exe and have the dependency install runtime. My goal is simplicity so trying all I can before resorting to separate MSIXs.

Thanks again for your response.

[#5]

Hello Sushant,

I'll look at the logs using procmon - good idea. The main application, when initiated, opens another *.exe in the runtime package. This is where my issue begins - the *.exe from the runtime package needs access to opengl and doesn't find it. @Eyad gave a good suggestion to include the opengl32.dll files in my MSIX root directory - so will try that next.

I noticed another behavior that may be interesting - myapp.exe is a X86 app and my runtime is a X64 app. If I run separate MSIX (one for myapp.exe and another for runtime), with myapp.exe as X86 architecture and runtime as X64 architecture, the myapp.exe doesn't locate the runtime. It is only when both are X64 architecture (myapp.exe and runtime) does it work correctly.

I am not that familiar with openGL and it's specific architecture dependencies. I read that openGL runs as DirectX anyway but will research this further. Any advice is appreciated....

Thank you.

[#6]

@Eyad, is there an example of best practice to include the OpenGL library in a MSIX package structure?

[#7]

@farmerphd  
Without seeing the Process Monitor trace myself, I can only give you an educated guess. Traditional applications have multiple ways to help find the dlls that they need, and this can get messed up in MSIX.

If in the procmon trace you notice the app trying to open the opengl dll(s) from different locations but ultimately failing, there are actions that you can take.

• Treat the OpenGL libraries as an external dependency.  This is probably not desirable.
• Include them inside the package but make sure they can be found. There are several different ways to do this, and all are effective:  
  • If all dlls are the same "bitness" (architecture), then placing them in the root folder of the package will solve the issue. 
  • They may also be placed in the VFS\SystemX86 and VFS\SystemX64 folders of the package and this would also solve the issue.  This is needed when the app has the same dll name in different bitnesses for different exes, but even if not, as long as you put it in the right system virtual folder it works.
  • There is an extension for the AppXManifest called uap6:LoaderSearchPathOverride that can list additional directories in your package that dlls live in.
  • The PSF has a solution (DynamicLibraryFixup) as well, but you probably don't want to go there.

[#8]

Thank you for your reply @TIMOTHY MANGAN. This is really helpful. Best case, I will add the .dlls to the root folder. First, I'll add the uap6:LoaderSearchPathOverride to the AppXManifest and check for all dlls.

Thanks again.

[#9]

Are there any examples of include opengl dlls in a MSIX package? I only added the opengl32.dll to the SystemX64 and X86 folders. It still shows 'not installed'. There are libraries to include but not sure which one is needed. My app is a X64 application.

[#10]

I finally looked at the procmon and psf support logs. I thought my problem was with opengl but it is DIrectX access. Is there an example how to include DIrectX inside the MSIX? I downloaded Microsoft.DirectXRuntime_x64 and it is a lot of dll files. Not sure how to include these inside my MSIX.

[#11]

I believe that you can add a package dependency on DirectX to ensure that the latest version is available to your package.

But to be quite honest, I'm not sure that DirectX has changed in incompatible ways in a long time. You might need more debugging of your issue to find the real cause.

[#12]

Sure I need more debugging - the observation is when I split the runtime component from the .EXE app into separate packages, all works fine. It is only when I keep both in the same MSIX that the issue happend with 'opengl not installed'. The error logs show DirectX so confused on what is really happening. The clue that separate they work and together they don't is taking me down a path of understanding in package vs across package behavior. Any help is appreciated...