Crash on minimizing

[softworkz 5065]

54 minutes ago, FordGT90Concept said:

WMC UI hitches but does not crash on minimize.

What does "hitches" mean?

 

55 minutes ago, FordGT90Concept said:

Where is the source code for the version of the app that is crashing? I might be able to run it with the debugger and find out exactly where/how it is dying.

It's not open source, but you can still debug it (be sure to configure Microsoft Symbol servers) - the crash is not in our code anyway. 
A stack trace might tell the story (but also possible that it doesn't).

Thanks

[FordGT90Concept 97]

Minimize wasn't instant as expected.  It took like 2-3 seconds after clicking minimize before it actually minimized.

I don't think I can get any better crash data than I got then.

Here is the stack trace:
ntdll!RtlRaiseNoncontinuableException+0xf
KERNELBASE!RaiseFailFastException+0x152
Microsoft_UI_Windowing!CFlat::Abandonment::FailWithException+0x99
Microsoft_UI_Windowing!CFlat::Abandonment::FailWithHR+0x86
Microsoft_UI_Windowing!System::Runtime::InteropServices::Marshal::ThrowExceptionForHR+0x25d
Microsoft_UI_Windowing!CFlat::WinRT::ITypedEventHandler$2<Microsoft::UI::Windowing::AppWindow * __ptr64,Microsoft::UI::Windowing::AppWindowChangedEventArgs * __ptr64>::Interface$::ImportDispatcher::Invoke+0xab
Microsoft_UI_Windowing!CFlat::WinRT::ITypedEventHandler$2<Microsoft::UI::Windowing::AppWindow * __ptr64,Microsoft::UI::Windowing::AppWindowChangedEventArgs * __ptr64>::Invoke<CFlat::InterfacePtr<CFlat::WinRT::ITypedEventHandler$2<Microsoft::UI::Windowing::AppWindow * __ptr64,Microsoft::UI::Windowing::AppWindowChangedEventArgs * __ptr64> > >+0x41
Microsoft_UI_Windowing!CFlat::WinRT::TypedEventHandlerNativeToManagedAdapter$4<Microsoft::UI::Windowing::AppWindow * __ptr64,Microsoft::UI::Windowing::AppWindowChangedEventArgs * __ptr64,CFlat::SmartPtr<Windowing::AppWindow>,CFlat::SmartPtr<Windowing::ChangedArgs> >::Invoke+0x86
Microsoft_UI_Windowing!Windowing::AppWindow::RaiseChanged+0xd4
Microsoft_UI_Windowing!Windowing::AppWindow::ProcessWindowMessage+0xfb
Microsoft_UI_Windowing!EnterContextAndProcessAppWindowMessage+0x75
Microsoft_UI_Windowing!Windowing::AppWindowFeatureProc+0x3a
Microsoft_UI_Windowing_Core!Core::YieldAndCall::FeatureProc+0x72
Microsoft_UI_Windowing_Core!Windowing::ExternalFeature::FeatureProc+0xc4
Microsoft_UI_Windowing_Core!Windowing::FeatureCallContext::CallNextHandler+0xca
Microsoft_UI_Windowing_Core!Windowing::Feature::CallNextHandler+0x70
Microsoft_UI_Windowing_Core!DefFeatureProc_Full_ContextThunk+0x6c
Microsoft_UI_Windowing!Windowing::MonitorTrackerFeatureProc+0x57
Microsoft_UI_Windowing_Core!Core::YieldAndCall::FeatureProc+0x72
Microsoft_UI_Windowing_Core!Windowing::ExternalFeature::FeatureProc+0xc4
Microsoft_UI_Windowing_Core!Windowing::FeatureCallContext::CallNextHandler+0xca
Microsoft_UI_Windowing_Core!Windowing::FeatureCallManager::CallFeatureChain+0x18d
Microsoft_UI_Windowing_Core!Windowing::Window::ProcessMessage+0x120
Microsoft_UI_Windowing_Core!EnterContextAndProcessWindowMessage+0x87
user32!UserCallWinProcCheckWow+0x50c
user32!CallWindowProcW+0x8e
comctl32!CallNextSubclassProc+0xa2
comctl32!DefSubclassProc+0x8d
WinUIEx!WinUIEx.Messaging.WindowMessageMonitor.NewWindowProc+0xf1
0x1
0x0000005e`3317a380
0x5

 

ExceptionAddress: 00007ff96015e401 (Microsoft_UI_Windowing!System::Runtime::InteropServices::Marshal::ThrowExceptionForHR+0x000000000000025d)
   ExceptionCode: e0464645
  ExceptionFlags: 00000001
NumberParameters: 2
   Parameter[0]: ffffffff80070057
   Parameter[1]: ffffffff80070057

Edited October 27, 2025 by FordGT90Concept

[FordGT90Concept 97]

Oh this dump compresses much better so I can get it under the limit.

dmp.7z

[softworkz 5065]

´Thanks, this gives a pretty good hint to where it might come from.

Can you please try the beta from today: https://emby.media/community/index.php?/topic/143756-new-windows-xbox-beta-226400-beta/

(it doesn't have any fixes in this regard, just as a baseline)

I already have a fix for the subsequent beta.

[FordGT90Concept 97]

As expected, the beta still crashes a few seconds after minimization.  The stack is a little different (caught internally instead of OS?):
 

PROCESS_NAME:  Emby.Client.WinUI.dll
ERROR_CODE: (NTSTATUS) 0xe0464645 - <Unable to get error code text>
EXCEPTION_CODE_STR:  80070057
EXCEPTION_PARAMETER1:  ffffffff80070057
EXCEPTION_PARAMETER2:  ffffffff80070057

STACK_TEXT:  
ntdll!RtlRaiseNoncontinuableException+0xf
KERNELBASE!RaiseFailFastException+0x152
Microsoft_UI_Windowing!CFlat::Abandonment::FailWithException+0x99
Microsoft_UI_Windowing!CFlat::Abandonment::FailWithHR+0x86
Microsoft_UI_Windowing!System::Runtime::InteropServices::Marshal::ThrowExceptionForHR+0x25d
Microsoft_UI_Windowing!CFlat::WinRT::ITypedEventHandler$2<Microsoft::UI::Windowing::AppWindow * __ptr64,Microsoft::UI::Windowing::AppWindowChangedEventArgs * __ptr64>::Interface$::ImportDispatcher::Invoke+0xab
Microsoft_UI_Windowing!CFlat::WinRT::ITypedEventHandler$2<Microsoft::UI::Windowing::AppWindow * __ptr64,Microsoft::UI::Windowing::AppWindowChangedEventArgs * __ptr64>::Invoke<CFlat::InterfacePtr<CFlat::WinRT::ITypedEventHandler$2<Microsoft::UI::Windowing::AppWindow * __ptr64,Microsoft::UI::Windowing::AppWindowChangedEventArgs * __ptr64> > >+0x41
Microsoft_UI_Windowing!CFlat::WinRT::TypedEventHandlerNativeToManagedAdapter$4<Microsoft::UI::Windowing::AppWindow * __ptr64,Microsoft::UI::Windowing::AppWindowChangedEventArgs * __ptr64,CFlat::SmartPtr<Windowing::AppWindow>,CFlat::SmartPtr<Windowing::ChangedArgs> >::Invoke+0x86
Microsoft_UI_Windowing!Windowing::AppWindow::RaiseChanged+0xd4
Microsoft_UI_Windowing!Windowing::AppWindow::OnSize+0x2c
Microsoft_UI_Windowing!Windowing::AppWindow::ProcessWindowMessage+0x1f7
Microsoft_UI_Windowing!EnterContextAndProcessAppWindowMessage+0x75
Microsoft_UI_Windowing!Windowing::AppWindowFeatureProc+0x3a
Microsoft_UI_Windowing_Core!Core::YieldAndCall::FeatureProc+0x72
Microsoft_UI_Windowing_Core!Windowing::ExternalFeature::FeatureProc+0xc4
Microsoft_UI_Windowing_Core!Windowing::FeatureCallManager::CallFeatureChain+0x287
Microsoft_UI_Windowing_Core!Windowing::Window::ProcessMessage+0x120
Microsoft_UI_Windowing_Core!EnterContextAndProcessWindowMessage+0x87
user32!UserCallWinProcCheckWow+0x50c
user32!CallWindowProcW+0x8e
comctl32!CallNextSubclassProc+0xa2
comctl32!DefSubclassProc+0x8d
WinUIEx!WinUIEx.Messaging.WindowMessageMonitor.NewWindowProc+0xe8
0x5
0x00000009`611ec040
0x40652
0x1
0x000049f9`7d22b9f7
coreclr!vtable_InlinedCallFrame
0x00000009`611ecfe8

SYMBOL_NAME:  Microsoft_UI_Windowing!CFlat::Abandonment::FailWithException+99
MODULE_NAME: Microsoft_UI_Windowing
IMAGE_NAME:  Microsoft.UI.Windowing.dll
STACK_COMMAND: dt ntdll!LdrpLastDllInitializer BaseDllName ; dt ntdll!LdrpFailureData ; ~0s; .ecxr ; kb

Edited October 28, 2025 by FordGT90Concept

[softworkz 5065]

Can you try the new beta?

Thanks

[FordGT90Concept 97]

I think you got it fixed.  Non-beta still crashes and beta does not.

 

Unrelated note: the intro animation on this app is way too long.

Edited November 13, 2025 by FordGT90Concept

[pwhodges 2012]

I believe the long animation is simply to cover the slow loading of the underlying libraries, and is not itself the cause of any delay.

Paul

[FordGT90Concept 97]

In which case, it would be nice if it aborted the animation when loading is complete (add a setting for it).  A lot of people are using this on SSDs where loading is instantaneous.

Edited November 13, 2025 by FordGT90Concept

[Neminem 1515]

@FordGT90Conceptstart you stopwatch and stop it.

Then start your stopwatch when clicking app icon and click the hide button and stop after app load.

What do you see ?

[softworkz 5065]

5 hours ago, FordGT90Concept said:

In which case, it would be nice if it aborted the animation when loading is complete (add a setting for it).  A lot of people are using this on SSDs where loading is instantaneous.

For background please see here:

 

 

4 hours ago, Neminem said:

Then start your stopwatch when clicking app icon and click the hide button and stop after app load.

And when you have that time, you can repeat the same again, but this time, press the "Hide" button at the bottom right. This will instantly hide the animation and show you what's going on behind. Then you can compare and see for how many seconds the animation might have been visible to "too long".

I haven't looked at whether there might have been an improvement from the MS side (since the beta is using newer versions of all the components). While you're at it, please compare this with the stable version. If there has been an improvement with the updated components in the beta, then I'll happily shorten the animation to adapt.

I do have everything running on NVMe storage and with the stable version, on my side it's like 1-1.5s longer than necessary. That's a smalll extra time to accommodate for slower user systems.

But in no way are we anywhere close to "instantatious".

[softworkz 5065]

5 hours ago, FordGT90Concept said:

I think you got it fixed.  Non-beta still crashes and beta does not.

Perfect! Thanks a lot for confirming.

[FordGT90Concept 97]

10 hours ago, Neminem said:

@FordGT90Conceptstart you stopwatch and stop it.

Then start your stopwatch when clicking app icon and click the hide button and stop after app load.

What do you see ?

I stop the timer when I see the contents of my server.

Non-beta: Doing nothing, it takes 15 seconds.  Clicking hide it either crashes because of this very thread bug () or if it doesn't crash, 9-10 seconds.  I tested doing nothing again later (because Windows likes caching stuff) and it dropped to 12 seconds and that's pretty consistent.

Beta: 12 seconds (there's no spinny loader thing on beta? it faded to the main menu). 10 seconds hiding and there I do see the spinny wheel thing just before the server contents.

 

6 hours ago, softworkz said:

I do have everything running on NVMe storage and with the stable version, on my side it's like 1-1.5s longer than necessary. That's a smalll extra time to accommodate for slower user systems.

How about an option to auto hide it? I'd rather look at a static Emby logo than the animation (the animation actually makes it feel longer than it actually is by drawing my attention to it).  The only change I'd make to the static Emby logo is putting the spinny loading wheel just below it to inform the user it's working.

I legit didn't even know the hide button existed until today.

Edited November 14, 2025 by FordGT90Concept

[softworkz 5065]

I've responded on the suject in various posts. You can find it. 

Thanks

[softworkz 5065]

But the short version is that I disagree.

Nobody else has gone through the start sequence more often than I did. With the static logo with and without spinner: some hundred times and with the animation something like 2000 to 3000 times. With the animation it definitely feels a lot faster as it gives you an orientation of where you stand and how long it's still to go. Without that orientation, the duration becomes a subjective subject - sometimes it feels longer and sometimes shortter but in either case, somewhere in between you are starting to get annoyed and angry like "damn - how much longer will it take?". This doesn't happen with the animation because you always know where you stand and how much longer it will take.

[softworkz 5065]

What's planned though:

• Fast startup mode
  at the cost of having a background process running with the WebView initialized already
• Options to
  • disabling animation
  • enable a startup sound alongside the animation
• Dynamic animation duration 

It's been a totally new app based on a new x-platform application basis - so it was required to draw a line rather than trying to do too much at once.

[FordGT90Concept 97]

1 hour ago, softworkz said:

But the short version is that I disagree.

Nobody else has gone through the start sequence more often than I did. With the static logo with and without spinner: some hundred times and with the animation something like 2000 to 3000 times. With the animation it definitely feels a lot faster as it gives you an orientation of where you stand and how long it's still to go. Without that orientation, the duration becomes a subjective subject - sometimes it feels longer and sometimes shortter but in either case, somewhere in between you are starting to get annoyed and angry like "damn - how much longer will it take?". This doesn't happen with the animation because you always know where you stand and how much longer it will take.

In my case, Emby is always on a second monitor so I don't really care how long it takes to start up but distracting me from whatever is on my primary monitor makes Emby's start up a nuisance because it's pulling my focus away from the primary monitor.

1 hour ago, softworkz said:

What's planned though:

• Fast startup mode
  at the cost of having a background process running with the WebView initialized already
• Options to
  • disabling animation
  • enable a startup sound alongside the animation
• Dynamic animation duration 

It's been a totally new app based on a new x-platform application basis - so it was required to draw a line rather than trying to do too much at once.

I know I wouldn't use "fast startup mode" because I use it so rarely there's no sense leaving it precached.

I would use "disabling animation" for the reason explained above. I definitely would not use "startup sound" because I can see with a glance that it's ready; that's pretty simple to implement though and would be a good feature for people with a single monitor.  At bare minimum, and in all contexts, it would be a good idea to use FlashWindowEx to notify users it's ready (perferrable to using a sound too).

Not sure what you mean by "dynamic animation duration" but the best solution is a progress bar if you have something to hook to know how long it will take.

[Deihmos 169]

I have the same issue. App crashes when I minimize on my second monitor. No crash when on the main monitor. I see the beta fixed it but that looks like it is closed. 

[Deihmos 169]

Is there a workaround for this? It seems to be the same issue the OP experienced, though they managed to resolve it by updating to a beta, which I can’t do. Do you need logs? 

 

Faulting application name: Emby.Client.WinUI.exe, version: 2.234.0.0, time stamp: 0x670d0000
Faulting module name: Microsoft.UI.Windowing.dll, version: 0.0.0.0, time stamp: 0xc4304fb8
Exception code: 0xe0464645
Fault offset: 0x000000000003e401
Faulting process id: 0x70E0
Faulting application start time: 0x1DC8EE1E65D17F8
Faulting application path: C:\Program Files\WindowsApps\EmbyMedia.EmbyTheater_2.234.2.0_x64__svmepx4c03f7m\Emby.Client.WinUI.exe
Faulting module path: C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.6_6000.519.329.0_x64__8wekyb3d8bbwe\Microsoft.UI.Windowing.dll
Report Id: 960bc20b-cc8d-4a11-befd-53e445cd42e9
Faulting package full name: EmbyMedia.EmbyTheater_2.234.2.0_x64__svmepx4c03f7m
Faulting package-relative application ID: App

Edited January 26 by Deihmos

[FordGT90Concept 97]

@softworkzany chance of pushing the fix to public?

[Luke 42077]

8 hours ago, FordGT90Concept said:

@softworkzany chance of pushing the fix to public?

Hi, soon. We're getting there.