Window messages

  • Thread starter Thread starter Berndt Johansson
  • Start date Start date
B

Berndt Johansson

Hi



I just stumbled into a strange problem that I don't understand. My launcher
application starts an executable after the load event. Actually I have the
Load event handler set a timer for 200ms and the timer's Tick handler will
do some work and then eventually start the application using Process.Start.
In the execution of the Timer event I use a Process.WaitForExit function to
halt the execution until the started application exits. This usually works
fine, but not always. Our fault reporting system stopped working when people
started using the launcher application and the reason for this seems to be
that the timer's event handler will not finish until the launched
application is closed.



For some reason it seems to me that the Remedy system stopped to receive
window messages when my launcher application was running the timer event.
When that timer event was finished executing (the launched application was
closed) the Remedy application would just continue to work as nothing had
happened.



Why is this not happening for all applications?



My workaround was to use a separate thread that would launch the executable.
I was still able to use the WaitForExit and when the tread was finished, the
launcher would also exit.



But the behaviour really puzzles me!

Can anyone please shed some light on this?



/Berndt
 
Hi Berndt,

Just as doc described, WaitForExit is used to make the current thread wait
until the associated process terminates. It made the main thread blocked to
wait for the process exit, the blocking of main thread also freezed the
message loop, so that any communications to this application based on win32
message will be blocked. Are you using SendMessage in your fault reporting
System and remedy system?


Best regards,

Ying-Shen Yu [MSFT]
Microsoft Community Support
Get Secure! - www.microsoft.com/security

This posting is provided "AS IS" with no warranties and confers no rights.
This mail should not be replied directly, please remove the word "online"
before sending mail.
 
Hi

Sorry for not being up to speed on the messaging implementation in Win32.
So, what you are saying is that freezing an eventhandler in a .net
application will freeze the global message loop that other win32
applications use? Is this only happening on pure win32 application?
The fault reporting system is not developed by ourselves, so I don't know
how it has been implemented.

/Berndt
 
Hi Berndt,
So, what you are saying is that freezing an eventhandler in a .net
application will freeze the global message loop that other win32
applications use? Is this only happening on pure win32 application?
Click to expand...

Ying-Shen didn't say such thing, I believe.
First of all there is no such a thing as global message loop. There are
message loops which are per thread. Even thought there is a system thread
that dispatches keyboard and mouse messages from global message queue to
threads' queues even if this thread block it will affect only the keyboard
and the mouse but the applications will keep comunicating messages.
So it doesn't happen neither on pure win32 application nor .NET.

However if the launcher palys some role in the process of sending fault
messages it might be the problem. The main UI thread of the launcher is
blocked so it won't receive niether posted nor sent messages.

--
HTH
Stoitcho Goutsev (100) [C# MVP]


Berndt Johansson said:
Hi

Sorry for not being up to speed on the messaging implementation in Win32.
So, what you are saying is that freezing an eventhandler in a .net
application will freeze the global message loop that other win32
applications use? Is this only happening on pure win32 application?
The fault reporting system is not developed by ourselves, so I don't know
how it has been implemented.

/Berndt


"Ying-Shen Yu[MSFT]" said:
Hi Berndt,

Just as doc described, WaitForExit is used to make the current thread wait
until the associated process terminates. It made the main thread blocked to
wait for the process exit, the blocking of main thread also freezed the
message loop, so that any communications to this application based on win32
message will be blocked. Are you using SendMessage in your fault reporting
System and remedy system?


Best regards,

Ying-Shen Yu [MSFT]
Microsoft Community Support
Get Secure! - www.microsoft.com/security

This posting is provided "AS IS" with no warranties and confers no rights.
This mail should not be replied directly, please remove the word "online"
before sending mail.
Click to expand...
Click to expand...
 
Thanks for clearing this up, Stoitcho.

Berndt, my guess is these two application at least needs interacting with
your launcher application, they need a reply from the launcher application
to go on running, and they seems not have timeout options. It may be based
on Win32 messages or some other IPC mechanisms, but I think this
interaction needs the main thread of your launcher application, so if you
blocked up the main thread, no reply will be sent.
Creating a new thread to wait for process exiting should be fine.

Best regards,

Ying-Shen Yu [MSFT]
Microsoft Community Support
Get Secure! - www.microsoft.com/security

This posting is provided "AS IS" with no warranties and confers no rights.
This mail should not be replied directly, please remove the word "online"
before sending mail.
 
I am not sure that we understand each other now.

The fault reporting system is a separate application that our testers use to
report faults on our software and is usually running on the computer that
the tester is using. This is not the application that the launcher is trying
to launch, it just happens to be one application that hangs whenever the
launcher is used. Which to me is odd, since Stoitcho said that the message
queues are per thread. I mean, if the launchers only task is to launch an
application (our own client application in this case) then when the
application is launched I don't see why blocking the launcher's main thread
(using WaitForExit) could do any harm. Actually that is what I want to do,
since I need to perform some cleanup after the client application has
terminated (remove extracted files etc.). Our own launched client app works
just fine during the time when the launcher is blocked waiting for the
client app exiting. But the fault reporting application just hangs until the
launcher exits. When the launcher exits, the fault-reporting app just
continues as if nothing had happened.

The launcher application is coded to only work with our own client
application (strong named assemblies and policies), so it shouldn't at all
be concerned with the fault-reporting app. And if there is no such thing as
a global message queue, then I certainly don't understand how our launcher
application could cause any other application (the fault reporting
application in this case) to stop responding....



Sorry if I was unclear about the setup in my previous postings.


/Berndt
 
Hi Berndt,

Will the fault reporting system work if you move the clean up code into the
Exited event handler and comment out the WaitForExit method?
If it works, this issue I think is still related to the message loop of the
launcher application.

To do further investigation on this issue, I suggest you try attaching a
debugger to the fault report system when it hangs, and check the call stack
on its threads, probably we can see which call made the application hang.
Note, to get the correct call stack information, you may need to load
symbol files for both the fault report system and the windows system.


Feel free to reply this thread if you have any problems on this issue.

Best regards,

Ying-Shen Yu [MSFT]
Microsoft Community Support
Get Secure! - www.microsoft.com/security

This posting is provided "AS IS" with no warranties and confers no rights.
This mail should not be replied directly, please remove the word "online"
before sending mail.
 
Well in this case it doesn't make any sense. Accept if the reporting
application do something weird like enumearting all windows and trying to
send some messages e.g. WM_GETTEXT in which case it will block.
 
Back
Top