The problem is that we need a way to reproduce these crashes. So the magic would be identifying steps that would crash the server. Whilst I am being swamped with logs here - still the more examples the better in identifying patterns
And since these crashes are not generating crash reports, for each crash would need to see export of the windows application event log for event id 1000 and event id 1001 together with logs
I havenāt run the SFC command; will try to remember that in future (also, to include the Locale Metadata folder in the Event Viewer uploads.)
Iām not sure taking BearcubII out of the equation is the best idea, but I understand your thinking here. It does make me wonder, though, where that leaves users with big setups ā there are some Plex installations out there that make mine look thoroughly anemic (the various Plex subs on Reddit verge on the terrifying) and have me mulling the idea of throwing together a proper server rack. Mind you, I think many of these big rigs are intended mainly for film/TV, and multi-user ā aside from me, I have one external user, and I donāt think he ever accesses much.
Looks like Plex crashed on Brainbuntu very soon after Scheduled Tasks started running. BearcubII on the other hand stayed up, not that the Android app would talk to it (No Internet, it said. Iāll take that to the Mobile App mob.)
Iāll see about setting up the User Mode Dump later. Iām about to go take the day off, considering that the massive physical efforts yesterday have left me feeling horrendous today.
Thanks, so exactly the track I thought was the likely problem. Iāll reprocess the album (and it may be reripped when I get to it, this time in FLAC) and see if that does anything to fix the issue.
For users that are getting many Database Busy errors/warnings in the log prior to crashing with exception code 0xc0000409 STATUS_STACK_BUFFER_OVERRUN, I have a diagnostic build to send out - build 1.15.1.725. If you donāt hear from me and you do see these warnings in the log before crashing, let me know, example
Feb 27, 2019 17:00:27.221 [4924] WARN - Waited one whole second for a busy database.
Feb 27, 2019 17:00:27.785 [15544] WARN - Waited one whole second for a busy database.
Feb 27, 2019 17:00:28.263 [14616] WARN - Waited one whole second for a busy database.
Feb 27, 2019 17:00:28.601 [8876] WARN - Waited one whole second for a busy database.
Feb 27, 2019 17:00:28.949 [6348] WARN - Waited one whole second for a busy database.
When I move Plex to the new machine (with an SSD, very likely) I might consider just moving some libraries onto Brain. Or, indeed, onto the Mouse Orchestra (the studio computer.) Having the audiobooks libraries there would probably help, although the wireless connection on Mouse is sluggish ā not a problem with fairly low-res audiobooks, though, especially as Iād most often run them in situ.
i am also having crashes happen during the night about 1-3 minutes after starting scheduled tasks with the same 409 exception related to ucrtbase.dll. as seen above. happy to test out a new build.
Dont have logs handy right ow but i was having āslow queries: waited XXX ms to retrieve XX items before crashā
I still need to get to hacking the registry, but it may wait for a bit ā to my amazement, neither server crashed overnight.
Iāve popped a few more pimples on BearcubII, as well ā the current intensive response to issues is revealing more bad media (fortunately correctable) and improving the state of the libraries there. That will be helpful when the new box is in place and I rebuild from scratch (Iām not bothering porting Plex over, just starting clean.)
Thanks. I will send the link in PM.
Iām on the latest beta channel Plex version, Windows update updated the ucrtbase.dll too.
The situation is the same, if I add this specific album to library the Plex server crashes. I tested now with a completly new library.
After I restart the Plex I deleted immediately the album to aviod further crashes.
It has nothing to do with the file itself, same happens if I try with flac or mp3.
Brainbuntu Plex Crash at 2:04am AZ time, four minutes after scheduled tasks are set to start. Did the usual pre-breakfast (for me, not the cats) and herewith, the logs.
We have dumps from @Wang.Chung.Plex that were manually taken after the 0xc0000409 crashes
I would like to know from other users if after crashing with the 0xc0000409 stack overrun exception, if the Plex Media Server.exe process remains to show up in windows task manager
If it does remain, then please go through the process of forcing a process dump of what would be a hung crashed process and provide that dmp with zip of the logs and export of the application event log for event IDs 1000 and 1001
Thanks - although your crashes have different exception codes (0x40000015) - would also like to know if the crashing process does actually disappear from Windows Task Manager - if it hangs as well - then the manual dump of the process would be useful
In almost all instances the PMS process vanishes from Task Manager, as does Plex Media Scanner. Usually Iām left with only a litter of Plex Script hosts that need to be killed manually.
No crashes overnight in either server, although BearcubII was definitely processing scheduled tasks after being restarted following a full crash (same exception code as noted above.) Brainbuntu (computer) had been rebooted just before 2am, which meant Plex didnāt come back online until after the scheduled tasks start time.
Iām amused about those dmp files ā accidentally got it right. I still canāt parse Microsoftās instructions!
The crashes were during scheduled tasks generation of video preview thumbnails. Could you disable this to see if there are any other causes for the crashes
So in Server Settings / Library settings. Set Generate Video Preview Thumbnails to Never
And as before, for any new crashes, look for the dmp files in %LocalAppData$\CrashDumps and let me have them with server logs and export of the 1000,1001 events from the Application Event Log
Last night BearcubII went down; Brainbuntu stayed up. Very confusing.
Iām in the process of moving Audiobook and Radio libraries to the Mouse Orchestra, and the plan there is to leave that iteration of PMS shut down until whenever needed.
