Open-shell-menu: Full screen video causes CS to crash

[daveBW10]

I've always used a custom start button with Classic Shell & never had this issue, but now see Classic Start crashing & closing when playing full screen videos in either the Movies & TV App OR my regular usage of JRiver Media Center + see the custom Start Button attempting to show on top of the video before the program crashes & stops. No real big deal to me, since it launches just fine with a manual start afterwards, but thought it notable to report, since this is a new occurrence with the new Classic Start.
TY very much for continuing this project BTW!

[ge0rdi]

What is the version of Windows and ClassicShell you are using?

I've tried to play full screen video using Movies & TV app on Win10 17134 (ClassicShell 4.3.1) and haven't experienced any crashes.

[Ibuprophen]

I've never, personally, had any issues with the Start Menu software for anything not related to the menu specifically.

I'm not stating that you aren't experiencing any issues but, that's a really odd/unique issue.

I'd like to know the same thing that @ge0rdi had inquired about and also the specific software/app that this is happening on.

Also...
When exactly did this start happening?

Is it specific to media from your PC and/or streaming?

This is not to be nosy but, to help with pinpointing if this is a conflict with and also if it's indeed specific to the Start Menu software as well.

~Ibuprophen

[daveBW10]

JRiver Media Center OR Movies & TV App playing full screen videos would just stop Classic Start v4.4.102 & I'd hafta restart it, BUT it would stop again shortly after going back to full screen video. I'll report more specifics as I gather them. Currently in W10 Ent LTSB but can test in W10 ProWS on this machine. It was happening all day yesterday, BUT I'm unable to replicate it today. As stated, I'll report back IF I have more.

[XenHat]

Due to how the recent file and apps functionality works, if your activity history ("Recent Files") contains entries that are located on an external Hard Drive (such as D:\Documents\Books\Dune\Hunters of Dune.epub), the Start Menu (or whatever happens to be refreshing the recent list) will freeze while it waits for D:\ to spin up if the file isn't present in Windows' cache.

This usually happens when the thread or function responsible for loading said history isn't a coroutine, and solely relies on the Windows API to serve the file data from the filesystem. That particular piece of the API cannot, is not or tends to not be used, in a co-routine design, and will "Wait" until the drive has woken up before providing the data back to the calling program/function.

In code terms, this would be similar to this:

// ignore my terrible code, it is simply an example to explain the behaviour
std::string fileNameFromInode = Win32API::GetFileName(SomeFileFromRecentHistory);
/* --- The function will hang at the call above until GetFileName returns a value, which will
         only happen once the hard drive has woken up.

-- Your menu will freeze before the next call, and can even crash if timeout is exceeded --*/
StartMenuInstance()->AppendToContainer(USER_HISTORY, fileNameFromInode);

This can possibly be fixed by using said co-routines and inserting the files into the recent history as the asynchronous data arrives.

Sorry for the long explanation, I got carried away.

[ge0rdi]

@daveBW10
If you are still experiencing crashes, please do following:

• Install latest nightly build
• Create crash dump using instructions described in https://github.com/passionate-coder/Classic-Start/issues/47#issuecomment-406724013

[XenHat]

Closing for inactivity