MaxIDE stuck on resuming Windows

[GWRon]

(Auto-)Powered off my Notebook last week (after having it closed for some time).

Now I started the Windows 10 on it again ... and it opened up my Chrome, my Notepad++ - and two different MaxIDE instances (one running in legacy and one in NG - I assume so as both share the same icon ;-)).
Both MaxIDE instances did display open documents but did not allow any interaction (menu and documents). Also "Taskbar + right click + close" did result in no change. Had to close them via "Task Manager".

I assume that these MaxIDEs were stucking somewhere in some logic so that system events were never polled ... an infinite loop somewhere.

Dunno how to tackle that now - maybe adding some stuff to a statusbar informing about what it does, or creating a "startup.log" which gets written each time some startup / resume takes place.

[GWRon]

Am not sure but some files might have been from network-mapped-drives ("Z:") which were not available on startup (other network). Dunno if the file loading just fails then - or responds with something MaxIDE/brl.modules cannot handle.
On normal MaxIDE starts I did not have issues with such kind of missing files but maybe things differ in that situation.

[GWRon]

Has anyone experienced this issue too?

Just resumed my notebook again - at a different location so this means the network mapped drive was not there on resume (might happen too if your local wifi / lan does not link fast enough). Again MaxIDE was stuck and I needed to kill the process via the task manager.
Maybe add some kind of "timer" which kills the loop/tries to open a file after a timeout ?

[woollybah]

Yes, I've seen this, but I can't remember what was the reason for it.
I think I had moved or renamed something, which caused MaxIDE to hang on startup. But of course I can't remember what it was now... might be related to bmk/bcc/mingw dir - these are the obvious things that it checks during startup.

[GWRon]

I could add some "maxide.startup.log" thing which is written during starting/resuming MaxIDE - dunno if that was of "public interest" (aka "commit to the repo").

@ mingw/bcc/bmk
As I did not move my local folders (mingw, bcc, bmk) I prefer the mapped network drive (and loaded files from there) being the issue - as it was not available on start.
So this might be the issue then. But on the other hand it seems as if this time my MaxIDE only had local files opened... hmmm
Might as well be some MaxGUI issue ... IF I built MaxIDE as debug - could I hook into the process with GDB (on Windows!) after resume + stall to see where it hangs?

[woollybah]

I don't think MaxIDE needs any logging.

[woollybah]

CheckVersion() is called during startup. This attempts to execute bcc.
I'm not sure how well the freeprocess code handles things if bcc doesn't exist?
Maybe we should have a file check first before attempting to run anything... which would save us the trouble of potentially running something that isn't there (yet).

Optionally... you could have it "poll" for some time (eg. check, wait 1 sec, until loops = 10), to see if bcc appears later, and then either continue loading if it does, or fail if not.

[woollybah]

In general, I like the resume after shutdown feature we now have. I'm now less stressed about Windows Update running during the night when the laptop is charging :-p

[GWRon]

Yes the feature is nice. Especially as it is something which does not need active help by the user - it just adds some convenience.

@ bcc
Yes file checks would help - except for globally available commands (via %PATH%).

But: as said I do not move files. NG is installed on "C:" so this means the bcc, bmk, gcc, ... should be available right on start - exception would be some blocked access by "Windows Defender" (or your AV solution) but this should only mean it will "hang" until that blocking tool releases the handle. Why should it block gcc, bcc, ... but not "maxide.exe" ?

So in other words: cannot understand why bcc/gcc-access could be the issue.

Also important: if the application is hanging it still shows the "document tabs" (with some files) so this means the files (at least some of them) were already kind of loaded (if options.restoreopenfiles ...). This also means CheckVersion() (runs bcc) and InitMenu (checks mingw) were executed before.

Maybe it cannot do this: RegisterApplicationRestart(Null, RESTART_NO_CRASH | RESTART_NO_HANG) short after it just resumed ? But if that was ... why does it work "most of the time" ?

Are you working with network / attached-usb-device files? So files which are temporarily not available on resume?