I have an app which uses a keyboard hook procedure in a library. The wParam in the hook for one message is 255 which we think is "(reserved / OEMClear)". I'd like to work out the source of this message as it causes my application to crash in the library, and given it shouldn't be happening it would be good to identify it. The message comes in repeatedly on only one PC we have - other computers don't see the message at all.
So, is there a way to trace the source of a message sent to a window please, or all those on the system?
There is no built-in way to find out who sent the window message, not even win32k keeps track of this; you might be able to find it out with a kernel debugger and a conditional breakpoint.
However, I would argue that you don't really need this information; you need to make your app properly handle any message sent to it.
I came up with a technique for determining who is sending a win32 window message across threads/processes during one-off debugging/troubleshooting sessions. It requires making a couple of assumptions so it's not 100% reliable, but so far I haven't found a case where it didn't work.
The basic idea is to exploit the fact that, when the message arrives, the recipient window thread is typically blocked waiting in its message loop (specifically, GetMessage()). When the message is delivered, the sending thread readies the receiving thread, pulling it out of its wait state.
It turns out that Windows provides ways to precisely trace which threads are readying which other threads, using Event Tracing for Windows. Using this feature, it is often possible to determine which thread sent the message - it's the thread that readied the receiving thread. It's even possible to see what the call stack of the sending thread was at the time it sent the message, and even the kernel side (win32k) part of the stack!
The basic procedure goes like this:
Use the Windows Performance Recorder to start a trace. Make sure to include the "CPU usage" profile.
Trigger the sending of the message you are interested in.
Stop the trace.
Open the trace in the Windows performance Analyzer.
In the "CPU Usage (Precise)" graph, "Stacks" graph preset, zoom in on the time the message was received.
One way is to locate the receiving thread and determine when it woke up.
If correlation is difficult, it might be worth instrumenting the receiving thread using e.g. TraceLogging to produce a clear reference time point.
You should be able to find a context switch event where the receiving thread is readied in GetMessage.
The "Readying Process", "Readying Thread Id" and "Readying Thread Stack" columns will then show the details of the readying thread, which is likely to be the sender of the message.
For example, in the below screenshot, TID 7640 receives a shell hook message originating from WindowsTerminal.exe, TID 1104:
(I originally suggested using Spy++ or winspector, but they do not hook into the sending of messages. That doesn't even make sense! A window receives messages but they don't send them, a thread does that. I'll leave my suggestion about using a debugger.)
Sometimes debugging can help. Try downloading the windows PDB files and setting a breakpoint that hits only when one of these messages occur. Looking at the call stack at that point can often shed some light on why things are happening. Posted messages and messages send from other processes will foil this approach.
Im not sure if this does what you want it to but have a look at Process Monitor by sysinternals.
http:// technet.microsoft.com/en-us/sysinternals/bb896645.aspx
It shows everything that happens to a process so i assume it catches messages as well. The site was down at time of writing so i couldnt check.
Related
If a system is trying to shut down, an app can block this shutdown by overriding OnQueryEndSession() and returning FALSE. Surely that means WM_ENDSESSION is the only definitive message to respond to regarding shutdown.
On the other hand, the top answer to this question quotes no less than Raymond Chen as saying that responding to WM_ENDSESSION is essentially pointless. So this is confusing.
Is there some kind of "best practice" principles to apply in deciding which of these messages (if any) one should respond to for doing what kinds of application shutdown work?
In particular, if neither message is handled, will a shutdown process cause an application to be closed as if the user had closed the application manually (e.g. click on red X close button)?
This article from Microsoft gives a very comprehensive discussion of end-of-session best practice both pre- and post-Vista. The article makes it quite clear that one should assume that if one receives a WM_QUERYENDSESSION then shutdown will occur at some point.
As soon as all applications have responded to the WM_ENDSESSION message, or been forced to terminate within 5 seconds of receiving the WM_ENDSESSION message, Windows may shut down at any time. This may limit what can be done in response to WM_ENDSESSION.
If an application requires more time to clean itself up:
If your application may need more than 5 seconds to complete its shutdown processing in response to WM_ENDSESSION, it should call ShutdownBlockReasonCreate() in its WM_QUERYENDSESSION handler, and promptly respond TRUE to WM_QUERYENDSESSION so as not to block shutdown. It should then perform all shutdown processing in its WM_ENDSESSION handler.
Windows will apparently not send any additional messages to your application to allow it to exit "gracefully" (e.g. WM_CLOSE). Rather, it will simply call TerminateProcess. If you want a graceful close, you have to build it yourself within the above constraints.
You do need to close down your application in WM_ENDSESSION, at least if you want to support the Restart Manager API. I think both MSDN and Raymond are wrong here. (Maybe it changed recently, or they overlooked the Restart Manager?)
The Restart Manager API is used by installers to close and restart exes which have files locked that they need to replace. To support being restarted by it, you call RegisterApplicationRestart and then need to have a window which handles WM_QUERYENDSESSION and WM_ENDSESSION.
If you don't shut down your app in the WM_ENDSESSION handler than it will simply keep running and block the Restart Manager, and in turn the installers trying to use it.
I found this out the hard way. MSDN explicitly says you don't need to call PostQuitMessage, but if I don't do that then my process keep running.
I suspect the documentation didn't realise the Restart Manager is different, and less forceful, compared to what happens when the entire OS shuts down.
(Edit: I should add, this was with a simple ATL COM EXE server, but as far as I can tell there was nothing about that complicating things, and Windows simply wasn't triggering a WM_QUIT to the message loop unless I did it myself.)
When do I need a message loop in a Windows application?
For example, for a Windows service do I need a message loop for every thread that I created or just for the main service process?
while(true)
{
GetMessage(&messageHandle, 0, 0, 0);
DispatchMessage(&messageHandle);
}
Every native Windows programs contains at least one message loop (often called a "message pump") like the one you give an example of.
This is to enable the handling of Windows events initiated by the program itself, other applications or the operating system.
Example of Windows events can be for timers, socket communication, GUI actions, clipboard, etc.
Many APIs and frameworks implement a message loop for you. This will depend on what you are using in your particular case.
(Check the answers in this Stack Overflow question for more information on message loops/message pump.)
Now to the gist of your question: many or most programs will work fine with one message-loop. The cases where you would want more than one is typically if processing a Windows event can take a long time (i.e. it locks the current thread) and there are requirements that require you too keep processing new window events. I can think of two concrete examples:
One is in a GUI application where you're showing a modal dialog (which usually freezes the main message pump and spins up a new one for the dialog)
A service of some kind where processing of I/O events can take a long time because of external dependencies and timeliness of processing of new I/O events is critical
In (1) this is very often a consequence of the GUI framework you are using and not something you have to do explicitly. In (2) a better way of handling it would be to asynchronously "do the work" of each event rather than blocking the message pump.
In conclusion: it depends. :-) In most cases you shouldn't need to use more than one message loop, but if you have to, do it!
Apps:
Essentially, when the thread is going to create and manage windows. This includes 'hidden' windows that support COM STA and the like.
No windows, no windows messages, no message loop required.
Services:
Service manager needs to handle the service messages, and so requires a service message loop for Start/Stop/whatever.
For other threads started in a service, no message loop is required.
We have a system where there are typically two processes running on the same system. One process handles the GUI and the other runs like a service (although for historical reasons, it's not a service, just an exe with no visible window).
The two processes undertake IPC mainly via registered messages asynchronously - i.e. we use RegisterWindowMessage() in both processes to define a large'ish set of messages that effectively form the API to the server process.
I have written a "hands-free" monitoring application that uses SetWindowsHookEx() to monitor and display the message queues of both processes and provide some level of decoding of the way the API is being utilised and how notifications are being propagated to the GUI process (each individual window can subscribe to notifications from the server directly).
So, there are a large number of messages in both directions so I have filtering and summary counts etc. so I can focus on particular activity. All this can be done without affecting the live code, which is good.
This all works well, but it now would be very useful to be able to "tag" a message originating in the GUI so I can trace the same message when it's processed by the server. This would be enormously useful for debugging and diagnosing system issues, but I can't find a clean way (actually I can't find any way!) of doing this without adding such support to our registered message API, which would be a lot of work and involves more risk than I'm comfortable with at the moment. It gets further complicated by the fact that the server pre-processes some messages and then does a PostMessage() back to itself to perform the action, so the originating message can get "lost".
Has anyone here tackled this type of problem? If so, can you give me some pointers? If not, then are there any documented or undocumented ways of adding a small block of data to a Windows message and retrieving it later? I've looked at SetMessageExtraInfo() but that seems to be per-queue rather than per-message.
FindWindow or FindWindowEx will give you the details of the GUI Window. Compare the details with message intercepted
I would like to create an application that will monitor apps running on my machine, and respond to situations where an application has beachballed. Is it possible (using any of the various OSX programming tools -- I'll teach myself Objective-C for this) to detect whether this has happened? If so, can someone give me a short code sample that does so?
I'm afraid I don't the actual classes or functions involved, but I can give you an outline of the process.
First, understand that every Application (perhaps every Window) has an event queue backing it. Each is serviced by a thread that just pops an event* off the queue, does some processing, and then returns to waiting for the next event. A "beachball" comes up (when forced by the system) when the event queue isn't getting serviced quickly enough. A "frozen" event queue implies that an application locked up when responding to some event in the past.
Now - outside of debugging contexts - you shouldn't be able to reach into another application and fiddle with a thread's event queue to see if its getting serviced. But what you could do instead is periodically post an event that would illicit a response, and if ever that response doesn't come you know the application is "locked up".
This constitutes polling, so be wary of the performance implications.
*Events are things like key down, key up, mouse moved, repaint, and so on.
Besides the WindowServer itself, the other system components that I know of that can detect unresponsiveness are the force quit dialog, spindump (which collects sampling profiles of applications while they are unresponsive), and Activity Monitor (presumably via its pmTool privileged subprocess). Perhaps running strings on pmTool might provide hints about what system calls to use?
Note that none of these evidently does its job by polling, because no application is ever detected as unresponsive until it fails to respond to an event — if an application hangs/does a lot of computation without checking its event queue, but it receives no events during that time, then it is not reported as unresponsive.
Our code library needs to be notified when the application is exiting. So we have subscribed to the System.Window.Forms.Application.ApplicationExit event. This works nicely for Winforms apps, but does it also work for other types of applications such as console apps, services, and web apps (such as ASP.NET)? The namespace would suggest that it doesn't, and it presumably gets raised when Application.Exit() is called (explicitly or implictly), which may not be correct to call for these other cases.
Is there some other event which would be better in these other cases or which would be more universal (great if it works for Winforms, too)? For example, is there an event for when Environment.Exit() is called (console app)?
I found a mention of an Exited event in System.Diagnostic.Process, but this appears to be for monitoring the exit of another process, and it does not appear to be received by a process about itself (for example, Process.GetCurrentProcess().Exited += Process_Exited; Process.GetCurrentProcess().EnableRaisingEvents = true;). I would think it might only be raised after the process has actually exited, so that wouldn't work.
This is particularly for .NET 2.0 and C#.
We finally found more about this (but by then my machine had been rebuilt and lost the cookies to my unregistered profile here; hopefully, it will let met post this answer).
Further investigation eventually found a few more events which we have found helpful:
System.Windows.Forms.Application.ThreadExit - Fires when a message loop exits
System.Windows.Forms.Application.ApplicationExit - Fires when all message loops exit
System.AppDomain.CurrentDomain.DomainUnload - Fires when a domain other than the default exits
System.AppDomain.CurrentDomain.ProcessExit - Fires when the default app domain exits
System.AppDomain.CurrentDomain.UnhandledException - Fires when an uncaught exception occurs, ending the app.
Only one of the DomainUnload or ProcessExit events are possible for a given app domain, depending on whether it is the default (top-level) domain for the process or was created as a subdomain (eg. on a web server). If an application doesn't know which it might be (as in our case), it needs to subscribe to both if it wants to catch the actual unload for itself. Also, it appears that UnhandledException (which as of .NET2.0 is always fatal) may prevent the other two events, so that may be a third case to handle. These three events should work for any .NET application.
There is a caveat that the execution time for ProcessExit is bounded (about 4 seconds?), so it may not be possible to do extensive "final" work in that event handler. It needs to be something which can be done quickly.
The Application events only apply to WinForms applications (we suspect they may not apply in pure WPF applications, however). The naming can be misleading because they are named for their most basic normal usage which has certain assumptions. ThreadExit does not relate to the actual System.Threading.Thread but rather to the message loop (Application.Run())) of a UI thread, and ApplicationExit similarly relates to the collection of application Forms on one or more UI threads. Normally, once the call to Application.Run() returns, called from the entry method of a thread, the entry method quickly concludes and the thread itself then ends. And once all UI threads have exited, a WinForms app is usually all done and exits.
Another event of note is the System.Windows.Forms.Application.ThreadException event. A Windows message loop can be configured to catch exceptions which occur in handling a message and send this event rather than let them be uncaught (and thus fatal) exceptions. Catching these exceptions allows the message loop (and that UI thread) to continue running (after aborting the current message handler). There can be only one subscriber to this event at any time for a given thread (subscriptions overwrite any previous subscriber), and it must be configured before any Form is created and subscribed before entering the message loop. See the MSDN help for this event and System.Windows.Forms.Applicaton.SetUnhandledExceptionMode() for more info.