Windows shutdown problems

[petko]

I am using CEF4Delphi with a subprocess. When a user shutdowns Windows, I am responding to WM_QUERYENDSESSION and WM_ENDSESSION messages in order to do it according to MS Windows documentation:

Code: Select all

//-------------------------------------------------------------------------------------------------
void __fastcall TMain::WmQueryEndSession(TMessage& Msg)
{
    Msg.Result = 1;
}
//-------------------------------------------------------------------------------------------------
void __fastcall TMain::WmEndSession(TMessage& Msg)
{
    if(Msg.WParam == true)
    {
        RunCommand(ApplicationCommands::Exit);
    }

    Msg.Result = 0;
}

However, since my application first checks the content of the browser component for changes made by the user in a JS-based text editor, I have a problem. It seems that Windows is automatically killing Chromium sub-processes before closing the main process. So my app hangs..

Does anybody else have similar problem? Or a solution? salvadordf, how do you deal with this in BriskBard?

[salvadordf]

The third page in this thread has a lot of information about that issue :
https://www.briskbard.com/forum/viewtopic.php?f=9&t=1760

I didn't find a perfect solution for BriskBard and sometimes Windows sends WM_QUERYENDSESSION to the subprocesses before the main browser process.

What I do is to start closing the whole app when the main process receives WM_QUERYENDSESSION and set the message result to false (0).

This is NOT what Microsoft recommends but TApplication calls HALT after receiving WM_ENDSESSION.

Perhaps we could intercept WM_QUERYENDSESSION and WM_ENDSESSION if we call GetWindowLong/SetWindowLong with GWL_WNDPROC to replace TApplication.WndProc

[salvadordf]

This code could be used to intercept those messages :
https://gist.github.com/xingfuqiu/3354852

[salvadordf]

The accepted answer to this question might be what we're looking for ;
https://stackoverflow.com/questions/25536216/delphi-prevent-application-shutdown

[petko]

Another piece of the puzzle might be the SetProcessShutdownParameters WINAPI function. My initial tests show that adding call to this function in my main exe makes the main process receive the shutdown messages before the sub-processes, so I am able to properly store any pending changes from the Chromium components. I am not sure in what percentage of the cases it works, but it certainly increases the like-hood of a proper shutdown.

Code: Select all

SetProcessShutdownParameters(0x3FF, SHUTDOWN_NORETRY);

Reference: https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-setprocessshutdownparameters

[salvadordf]

Another piece of the puzzle might be the SetProcessShutdownParameters WINAPI function. My initial tests show that adding call to this function in my main exe makes the main process receive the shutdown messages before the sub-processes, so I am able to properly store any pending changes from the Chromium components. I am not sure in what percentage of the cases it works, but it certainly increases the like-hood of a proper shutdown.

Code: Select all

SetProcessShutdownParameters(0x3FF, SHUTDOWN_NORETRY);

Reference: https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-setprocessshutdownparameters

I didn't know that function. Thanks!

I just released a new version of BriskBard with most of the suggestions given in the previous links I posted, including calls to ShutdownBlockReasonCreate and ShutdownBlockReasonDestroy, resturning false to WM_QUERYENDSESSION, replacing TApplication.WndProc to intercept WM_ENDSESSION, etc.

It's not perfect but I'll keep trying other things.

I'll try to add a "hidden window" to handle WM_QUERYENDSESSION in the subprocesses as the CEF project maintainer suggested and I'll test SetProcessShutdownParameters too.

Chromium uses that function in several places too :
https://source.chromium.org/search?q=SetProcessShutdownParameters&sq=&ss=chromium

[salvadordf]

Please, download the latest CEF4Delphi version from GitHub. It includes the fix for this issue.
Thanks petko!