EmbyServer.exe is killed by svchost.exe

[LAPS0082 13]

Hi,

My EmbyServer is runnning on a dedicated Windows 10 Machine. I see this error since some weeks. I did not change anything except Emby and Windows Updates.

I have the problem that my EmbyServer.exe process is being killed by svchost.exe about when the server is running 2-3 days.

When I read the minidump correct excatly after 3 days... 

I have not yet found a way to reproduce the problem.

I did use gflags to create an error log with minidump. This is the error I see in eventvwr

 

See attatched minidumps, emby log...

I am not the best at debugging minidumps. But with the help of AI i got this recommendations:
 

Analysis of the !clrstack Output:

The thread in which the breakpoint was triggered (OS Thread Id: 0x1148) was in the following .NET call chain:

• System.Threading.Monitor.ObjWait(Int32, System.Object): This indicates that the thread was waiting on a monitor (a synchronization primitive in .NET).
• System.Threading.ManualResetEventSlim.Wait(Int32, System.Threading.CancellationToken): The monitor wait was likely internally part of the implementation of ManualResetEventSlim.Wait. ManualResetEventSlim is a lightweight synchronization object used to signal the release of one or more waiting threads.
• System.Threading.Tasks.Task.SpinThenBlockingWait(Int32, System.Threading.CancellationToken): The thread waiting on the ManualResetEventSlim was apparently part of a Task operation and transitioned into a blocking wait phase after initial spinning (short, active waiting) was unsuccessful.
• System.Threading.Tasks.Task.InternalWaitCore(Int32, System.Threading.CancellationToken): This is an internal method of the Task class that implements the core logic for waiting on the result of a Task.
• System.Threading.Tasks.Task.Wait(Int32, System.Threading.CancellationToken): Here we see an explicit call to Task.Wait(), which waits for a Task to complete.
• System.Threading.Tasks.Task.WaitAny(System.Threading.Tasks.Task[]): Task.WaitAny() was called, which means that the code was waiting for one of several provided Tasks to complete.
• EmbyServer.Program.RunApplication(Emby.Server.Implementations.ServerApplicationPaths, MediaBrowser.Model.Logging.ILogManager, MediaBrowser.Model.System.IEnvironmentInfo, Emby.Server.Implementations.StartupOptions): This is a method in the EmbyServer.Program class, which likely starts and executes the main application logic of Emby Server.
• EmbyServer.Program.Main(System.String[]): The entry point of the application.

Conclusions and Next Steps:

The breakpoint in the CLR was triggered while an Emby Server thread was waiting for one of several Tasks to complete (Task.WaitAny()). The wait operation internally involved a ManualResetEventSlim and a monitor.

Possible Causes for the Breakpoint in this Scenario:

• Internal Timeout or Error in CLR Wait Logic: Although less likely, there could be a rare internal state in the CLR that leads to a breakpoint during waiting on Tasks and synchronization objects.
• Problems with the Waited-Upon Tasks: One or more of the Tasks being waited on with Task.WaitAny() might be in an unexpected state (e.g., faulted, canceled, in an infinite loop) that affects the wait operation in the CLR and possibly triggers this breakpoint.
• Incorrect Use of Tasks or Synchronization Objects in Emby Server Code: It's possible that there are errors in the RunApplication method or in code called from there in how Tasks or synchronization objects are handled, leading to this behavior.
• Deadlock-like Situation: Although not a classic deadlock (since WaitAny is used), there could be a situation where the expected completion of one of the Tasks doesn't occur or is delayed, leading to an internal timeout or a consistency violation that triggers the breakpoint in the CLR.

Recommended Next Steps:

• Focus on the Task.WaitAny() Call in EmbyServer.Program.RunApplication: Examine the source code of Emby Server (if available or through reverse engineering if necessary) around the call to Task.WaitAny(). Which Tasks are being monitored there? What are their responsibilities? Is there any logic to handle errors or timeouts of these Tasks?
• Check the Creation and State of the Involved Tasks: Investigate how the Tasks passed to Task.WaitAny() are created and managed. Are there potentially errors in error handling or in setting the state of these Tasks?
• Look for Patterns in the Occurrence of the Problem: Does the crash always happen at the same point in the program flow? Are there specific actions or system states that make it more likely to occur?
• Test Different Versions of Emby Server: If the problem has only appeared recently, try using an older version of Emby Server to see if the issue persists there. This could indicate that a recent change is the cause.
• Check the Emby Server Forums and Support Channels: Search the official Emby Server forums or support channels for similar problems or error messages that might point to an issue related to Task waiting situations.
• Consider Debugging the Emby Server Code (if possible): If you have access to the source code or are willing to reverse engineer, try setting breakpoints in your code around the Task.WaitAny() call and the creation of the involved Tasks to examine the program's state more closely before the breakpoint is triggered in the CLR.

The .NET Call Stack has given us a much clearer starting point for troubleshooting. The fact that the breakpoint occurs during a Task.WaitAny() strongly suggests that the problem is related to the management and state of Tasks in the main application of Emby Server.

 

Sorry for long post. I will provide more information if you need it.

Any help is appreciated

 

EmbyServer.exe-(PID-4420).dmp svchost.exe-(PID-1656).dmp embyserver-63879528608.txt

[Luke 42078]

Hi, that's odd. 

I don't think this will matter, but it looks like you enabled nfo file saving but did not ensure that emby server has write access to your media folders. This is causing the server to repeatedly try and fail to save nfo files. I would either fix those permissions or turn off nfo saving for each of your emby libraries.

[LAPS0082 13]

Hi @Luke

I turned this setting off

Don't know why it was enable... only for one library.

[Luke 42078]

OK please let us know if this makes a difference at all .Thanks.

[LAPS0082 13]

For everyone having a similar issue.

 

I start my emby server automatically after every reboot with a scheduled task while no user is logged in.

You have to untick this in your scheduled task so your process is not killed after x (3 in my case) days: