Windows app stops responding when another app is started

Question

Windows app stops responding when another app is started

SJ1711 20

I wrote a Windows application in Fortran using the Intel Fortran compiler within Visual Studio. The application accepts user input and then launches a lengthy numerical computation. During the computation, progress is monitored using a progress bar. When I run the application, it runs fine until I open another window. At that point, the app becomes "non-responsive": it no longer updates its progress bar, displays the "(Not Responding)" message adjacent to the app name, and displays the "Windows busy signal" (the blue rotating circle). Even though it appears to be non-responsive, the application is actually running in the background, and when it finishes the lengthy computation, everything is correct and the window becomes responsive again. When I run the application from within Visual Studio, it runs fine even when I start another application - it continues to update its progress bar and is responsive. Do you know why this behavior is occurring and do you have any suggestions on how I can get the application to run correctly outside of Visual Studio?

Accepted answer

1 additional answer

Your answer

Answer 1

RLWA32 49,636

@SJ1711 There is a pretty good description of what is happening when Windows determines that an application is "Not responding" at Preventing Hangs in Windows Applications.

When your application uses SendMessage and UpdateWindow it is calling directly into the window procedure of the progress bar control and bypassing the message queue. So the long running calculation causes the application to stop pumping messages even though the progress bar may be updating.

When another application is opened Windows will send messages to your application (e.g., WM_ACTIVATEAPP, WM_ACTIVATE, etc.). Now your application has messages that are sitting in the message queue but are not being dispatched. Windows detects this and flags the application as "Not responding" and the ghost window is displayed.

Windows knows when a process is executing under a debugger and does not use the ghost window. It only appears that your application is working normally under the debugger but the same problems exist.

SJ1711 20 Reputation points

2024-05-30T14:02:45.6966667+00:00

Thanks for the explanation! So, adding a call to PeekMessage in the computation loop to service the message queue should fix the problem.
RLWA32 49,636 Reputation points

2024-05-30T14:39:05.8133333+00:00
Simply calling PeekMessage is a cosmetic solution to avoiding the "Not Responding" ghost window. If called with the PM_NOREMOVE flag then messages will accumulate in the message queue and there is a finite limit to how many messages the queue holds. If called with PM_REMOVE then the messages will be removed from the queue.

Unless messages are dispatched then your application will actually remain unresponsive to user input. For example, moving/resizing the window with the mouse will have no effect. Simplistically, you could insert a loop to pump messages that looks like this -

MSG msg; while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE)) { DispatchMessage(&msg); }

This awkward method results in a window responding jerkily since messages are only dispatched when the long-running calculation pumps messages using the loop.

In my opinion a much better solution is to move the long-running calculation completely from the UI thread into a worker thread.

Answer 2

Hello

The behavior you’re observing is likely due to how Windows handles application responsiveness. An application is considered to be not responding if it is not waiting for input, is not in startup processing, and has not called PeekMessage within the internal timeout period of 5 seconds.

When your application is performing a lengthy computation, it may not be able to process Windows messages regularly, which can cause Windows to consider it as “not responding”. However, the computation is still running in the background, which is why the application becomes responsive again once the computation is finished.

Here are some suggestions to improve the responsiveness of your application:

Multithreading: Push expensive calculations to worker threads. This allows the main thread to continue processing Windows messages, which can prevent the application from appearing unresponsive.

Regularly Poll the Event Queue: Make sure your application regularly polls the event queue, even during lengthy computations.

Optimize Your Code: Look for ways to optimize your computation code to reduce the time it takes to complete.

Check for Unusual Background Processes: Look through the Processes tab in Windows Task Manager to ensure no unrequired apps or unusual background processes are running.

SJ1711 20 Reputation points

2024-05-29T21:43:09.03+00:00

Thanks for your response! But why does the application run correctly within Visual Studio? And how do I "poll the event queue"? The lengthy computation runs in a loop and after a certain number of cycles through the loop, the program updates the progress bar with a call to SendMessage(PBM_STEPIT). This is followed by a call to UpdateWindow. My understanding was that control would not return to the loop until the UpdateWindow command was executed (updating the progress bar). At that point, control would return to the loop, which would continue its processing. Is that correct?

Share via

Windows app stops responding when another app is started

1 additional answer

Your answer