Windows 11 App Refusing to Load

[Natelanxon 30]

Hi. I just installed Emby from the Windows 11 Store and it refuses to open. I checked Task Manager and after clicking the app, I briefly get one instance of Emby.Client.WinUI appearing but then disappearing after about 2 seconds and then nothing happens. I checked Windows Event Viewer logs for instances of a crash and can find nothing. What can I check to find something helpful in diagnosing this problem?

This is my system:
Edition    Windows 11 Pro
Version    25H2
Installed on    ‎04/‎10/‎2025
OS build    26200.8655
Experience    Windows Feature Experience Pack 1000.26100.315.0
 

Emby installed version is 2.315.2.0

Thanks

[Mahinepua 118]

can you see your server on the web app from the same machine?

[Natelanxon 30]

I can yes. I used the web app when the native app wouldn’t load. I’d prefer to be able to use the native one though if there’s a way. 

[Mahinepua 118]

hmm, try updating to the latest windows version, it should be under the optional update section.

plan B, uninstall and reinstall.

[Natelanxon 30]

Tried these. I also tried updating to the preview update as well. Nothing seems to do anything. 

[Neminem 1781]

Are there any logs in this dir?

C:\Users\%username%\AppData\Local\Packages\EmbyMedia.EmbyTheater_svmepx4c03f7m\LocalCache\logs

That might show what's going on.

[sa2000 790]

On 10/07/2026 at 11:58, Natelanxon said:

I checked Windows Event Viewer logs for instances of a crash and can find nothing.

Was that checking the "Application" log in "Windows Logs" for Source: "Application Error" relating to the Emby app ?

A suggested the logs may have some clues

 

[softworkz 5289]

On 7/10/2026 at 11:58 AM, Natelanxon said:

Hi. I just installed Emby from the Windows 11 Store and it refuses to open. I checked Task Manager and after clicking the app, I briefly get one instance of Emby.Client.WinUI appearing but then disappearing after about 2 seconds and then nothing happens. I checked Windows Event Viewer logs for instances of a crash and can find nothing. What can I check to find something helpful in diagnosing this problem?

@Natelanxon

 

• Is this a cloud VM?
• Did you perhaps enable and use the original Windows administrator account where you don't need/have any elevation requirements and you don't get any UAC (user account control) prompts?
• Can you run other Windows Store apps without problems?
• Is your machine member of a Windows domain?
• Do you have any group-policies configured which might prevent the launch?
  => run gpresult.exe /v

And please look for logs like @Neminemsuggested.

Thanks

[Natelanxon 30]

On 11/07/2026 at 13:07, Neminem said:

Are there any logs in this dir?

C:\Users\%username%\AppData\Local\Packages\EmbyMedia.EmbyTheater_svmepx4c03f7m\LocalCache\logs

That might show what's going on.

No, that folder doesn't exist. Everything up to /LocalCache is there, but there is no log dir.

21 hours ago, softworkz said:

@Natelanxon

 

• Is this a cloud VM?
• Did you perhaps enable and use the original Windows administrator account where you don't need/have any elevation requirements and you don't get any UAC (user account control) prompts?
• Can you run other Windows Store apps without problems?
• Is your machine member of a Windows domain?
• Do you have any group-policies configured which might prevent the launch?
  => run gpresult.exe /v

And please look for logs like @Neminemsuggested.

Thanks

It's not a cloud VM but it is a VM. My other apps, including those from the Windows Store, all work fine. It's only Emby that doesn't launch.

I also tried launching the app as an admin but that didn't make a difference other than to give me the elevation prompt by Windows.

It's not part of a domain and there shouldn't be any group policies as it's a pretty standard Parallels VM that runs a handful of apps.

I'm guessing the nature of it being a VM is part of the issue but it seems strange my other apps work fine. I wonder if there's anything I can try?

[Natelanxon 30]

Incidentally, the old Windows Theater app worked fine. I've just pulled that from Github to test and it works. I guess if nothing else works I can still use the old version.

[sa2000 790]

We could see if SysInternals Process Monitor gives some clues. You can download from the microsoft page here

Unzip and accept the EULA and you can set up a filter of Process Name containing the word Emby

and at the end when the app exits, save all filtered events as a PML and zip and upload using a link I will send you

You could also if you do not mind, launch event viewer and open each of the Application and System Windows Logs and save each as an evtx and zip and add to the upload

When you do the test, check task manager and make sure there is no emby client app process running - if you find any, end the process 

Then launch process monitor, start capture 

Then launch the new Emby Windows app

When it fails to launch, stop the capture and save as PML file, zip and athen save the two evtx files

Thanks

 

[Natelanxon 30]

4 hours ago, sa2000 said:

We could see if SysInternals Process Monitor gives some clues. You can download from the microsoft page here

Unzip and accept the EULA and you can set up a filter of Process Name containing the word Emby

and at the end when the app exits, save all filtered events as a PML and zip and upload using a link I will send you

You could also if you do not mind, launch event viewer and open each of the Application and System Windows Logs and save each as an evtx and zip and add to the upload

When you do the test, check task manager and make sure there is no emby client app process running - if you find any, end the process 

Then launch process monitor, start capture 

Then launch the new Emby Windows app

When it fails to launch, stop the capture and save as PML file, zip and athen save the two evtx files

Thanks

 

I've done this and will share with you via the link you DM'd me.

[sa2000 790]

@NatelanxonIs your VM setup as ARM64 ? There is a lot of log lines in the PML relating to XtaJIT64

 

 

[sa2000 790]

I can answer my own question - i can see this in the Environment Variables in the PML file process starrt

 

;	PROCESSOR_ARCHITECTURE=ARM64

You are probably the first person to run the new app version on ARM64 on Windows

Edited 17 hours ago by sa2000

[Natelanxon 30]

Yes it’s the ARM64 version of Windows 11

[Natelanxon 30]

2 hours ago, sa2000 said:

I can answer my own question - i can see this in the Environment Variables in the PML file process starrt

 

;	PROCESSOR_ARCHITECTURE=ARM64

You are probably the first person to run the new app version on ARM64 on Windows

Always the early adopter! I didn’t think it would be an issue since the previous version worked fine and other apps also seem stable. If it is an ARM issue then I guess there’s nothing I can do about that. 

[softworkz 5289]

@Natelanxon

Thanks for the details - so what you are trying to do is 

• Run an x64 application with heavy use of GPU features (by both, WebView2 and MPV player) - on Windows ARM64 OS
• With the Windows ARM64 OS running in a virtual VM on Apple Silicon hardware

Even though translation layers exist for running x64 code on ARM64 (Windows Prism) and Windows GPU drivers for the virtual GPU provided by Parallels which translates to Apple GPU - this is not a path which makes much sense.

To be honest, I'm surprised that our x64 app package is even offered to ARM64 systems, but they appear to be somewhat over-confident about the x64 emulation layer.
The fact that you don't ´see any log at all, means that it drops out very early during load, but it still can be due to both, WebView2 or MPV player.

We'll probably need to publish an ARM64 package with an ARM64 web view and without MPV player, to have a working version at least.

Thanks

[Natelanxon 30]

10 hours ago, softworkz said:

@Natelanxon

Thanks for the details - so what you are trying to do is 

• Run an x64 application with heavy use of GPU features (by both, WebView2 and MPV player) - on Windows ARM64 OS
• With the Windows ARM64 OS running in a virtual VM on Apple Silicon hardware

Even though translation layers exist for running x64 code on ARM64 (Windows Prism) and Windows GPU drivers for the virtual GPU provided by Parallels which translates to Apple GPU - this is not a path which makes much sense.

To be honest, I'm surprised that our x64 app package is even offered to ARM64 systems, but they appear to be somewhat over-confident about the x64 emulation layer.
The fact that you don't ´see any log at all, means that it drops out very early during load, but it still can be due to both, WebView2 or MPV player.

We'll probably need to publish an ARM64 package with an ARM64 web view and without MPV player, to have a working version at least.

Thanks

When you put it like that I'm surprised too, but what intrigues me is that the older Emby Theater works fine. I guess the more modern architecture of the rebuilt version is harder for multiple layers of emulation to cope with. It doesn't sound like there are lots of people trying to do what I'm doing though anyway so I don't mind using that. It's such an incredibly specific reason anyway: I want a news channel to keep playing even when I take out one of my Apple AirPods. MacOS pauses media by default when you take them out of your ears, but it's not clever/flexible enough to let you exclude certain apps. Since I have a VM running all day anyway, I installed Emby in it so it can't be touched by the Mac's AirPod automation.  Pretty sure it'd be overkill for me to push for an ARM64 build just for this reason! On the Mac itself I use either the native app or the web app.

 

[softworkz 5289]

> When you put it like that I'm surprised too, but what intrigues me is that the older Emby Theater works fine.

It has been outdated for long time, even before the new app came. The included Chromium engine is > 6 years old and a honeypot of security vulnerabilities. I wouldn't run it anymore. It's just still available because a few users had insisted.
The new app is totally different in many ways, you can't really compare these.
 

> I guess the more modern architecture of the rebuilt version is harder for multiple layers of emulation to cope with.

It could also just be that the WebView2 runtime has some interactions with the OS with a hard requirement of having the same architecture. 

BTW, that's really a weird use case.
 

> Pretty sure it'd be overkill for me to push for an ARM64 build just for this reason!

You may call this your lucky day, because this situation kind-of forces us to publish an ARM64 version, because the MS Store doesn't have any switch to tell like "don't install our x64 package on arm64 systems!". As we don't have evidence from a single user confirming that the app is working on arm64 (non-mac-vm), we must assume that it doesn't run there (well, this has always been the assimption, we just didn't think that it would get installed).

So, we have a new version on the way (as beta), if you like to test, I'll invite you to the beta. 

[Natelanxon 30]

More than happy to help beta test for you. I've been administrating and using Emby for many years on Windows, Mac, Ubuntu, Apple Watch (I have a lot of thoughts on this one!), iPad, iPhone, Xbox, Smart TVs and Web, so I'm pretty familiar with the expectations and limitations across a lot of the ecosystem.

Edited 57 minutes ago by Natelanxon

[softworkz 5289]

I've invited you to the beta.

To set expectations straight, though: This variant does not have MPV player included, it uses the html video player for video. For audio, it's going to get interesting whether the Windows Media based playback is going to work. It has never been tried before..(nothing has ever been tried to run on Windows ARM64, actually)