You don't say what OS you're trying it on, but on macOS it reads like it should work. I am not in a position to test it at the moment.

Are you installing the signal handler on the main thread like in the example?

From man sigaction:

After a fork(2) or vfork(2) all signals, the signal mask, the signal stack, and the restart/interrupt flags are inherited by the child.

Further reading - Signal Handlers for Multithreaded C++:

Signals are delivered to any one thread that has not blocked the signal, including (and as a most likely candidate) the main thread.

So I'm not sure what that means for us if we are trying to display a QMessageBox (in the example) since it sounds like it could happen from any thread. I think that should be fine...

Hi,
Sorry for not mentioning, I am using it on windows.
when I connected the start() of Qthread to one slot which will cause the crash. In this case it didn't work.
But when I run the class and connected start() into non crash function and then crash it after some time. That time it works so it is little confusing.

I'm having a hard time picturing what you're doing. Could you please show simple code snippets for the two cases?

I'm not very familiar with Windows stuff, but it's using SetUnhandledExceptionFilter which according to the docs:

Issuing SetUnhandledExceptionFilter replaces the existing top-level exception filter for all existing and all future threads in the calling process.

However it also says:

The exception handler specified by lpTopLevelExceptionFilter is executed in the context of the thread that caused the fault. This can affect the exception handler's ability to recover from certain exceptions, such as an invalid stack.

So maybe in one of your cases it's not in a state where it can do anything?