When I debug my program, which consists of looping over thousands of entries in vectors multiple times, it simply freezes the program but does not provide any error messages whatsoever. Does Visual Studio have some sort of auto-time out that I am experiencing?
Check may be your program is going into infinite loop Or doing some heavy task that makes your UI unresponsive(if you have windows form). Since you are debugging this program then why dont you set breakpoint in code and check where your program is causing issue.
And yes there is no time out for Visual Studio,But for program window.This is known as Hang Status.
When an application (or more accurately, a thread) creates a window on the desktop, it enters into an implicit contract with the Desktop Window Manager (DWM) to process window messages in a timely fashion. The DWM posts messages (keyboard/mouse input and messages from other windows, as well as itself) into the thread-specific message queue. The thread retrieves and dispatches those messages via its message queue. If the thread does not service the queue by calling GetMessage(), messages are not processed, and the window hangs: it can neither redraw nor can it accept input from the user. The operating system detects this state by attaching a timer to pending messages in the message queue. If a message has not been retrieved within 5 seconds, the DWM declares the window to be hung. You can query this particular window state via the IsHungAppWindow() API.
Detection is only the first step. At this point, the user still cannot even terminate the application - clicking the X (Close) button would result in a WM_CLOSE message, which would be stuck in the message queue just like any other message. The Desktop Window Manager assists by seamlessly hiding and then replacing the hung window with a 'ghost' copy displaying a bitmap of the original window's previous client area (and adding "Not Responding" to the title bar). As long as the original window's thread does not retrieve messages, the DWM manages both windows simultaneously, but allows the user to interact only with the ghost copy. Using this ghost window, the user can only move, minimize, and - most importantly - close the unresponsive application, but not change its internal state.
A nice article is written in this following link.
How program window works
Related
If I register a hook via SetWindowsHookEx(WH_SHELL, ShellProc, ...), what is the meaning of event HSHELL_WINDOWREPLACED? (My Google-fu fails me. I have searched high and low!)
Win32 Docs:
SetWindowsHookEx(): https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowshookexw
ShellProc (callback): https://learn.microsoft.com/en-us/windows/win32/winmsg/shellproc
The offical docs read: A top-level window is being replaced. Weirdly, they also say: Windows 2000: Not supported. Does that mean only supported before or after Win2K?
I created a test driver to watch a Microsoft Windows session, but I was never able to trigger this mysterious event.
I also found a similar event here:
RegisterShellHookWindow: https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-registershellhookwindow
... that says:
HSHELL_WINDOWREPLACING: A handle to the window replacing the top-level window.
HSHELL_WINDOWREPLACED: A handle to the window being replaced.
Related:
How can I be notified when a new window is created on Win32?
Why HSHELL_WINDOWDESTROYED, HSHELL_WINDOWCREATED?
In this instance, the term "replace" refers to the occasions when a window stops responding to messages ("hangs") and, after a certain period, Windows hides it and replaces it on-screen with a faded-out copy (called a "ghost window").
Windows does this so that, even when the app is not processing messages, the user can interact with the ghost window to move it around and try to close it.
The wParam value is the handle of the hung window (the one being replaced) and the lParam value is the handle of the ghost window (its replacement).
If the window starts responding again, the notification is sent again, with the window handles swapped around.
On Windows, what are all the possible creation entry points for user objects? I have been trying to isolate a handle leak in a .NET application for quite some time now. Here is what baffles me:
• Leak only occurs in window management objects (aka. USER objects - not kernel, not GDI).
• Leak only occurs when the application has focus. Clicking on another application "pause" the leak until we click on the application window again.
• Leak occurs even if process is suspended (through task manager or debugger).
I've been trying to intercept any and all object creation methods, but my Visual Studio debugger remains suspiciously silent. I do get the occasionnal call to some user32.dll methods (as described in https://learn.microsoft.com/en-us/windows/desktop/sysinfo/user-objects), but nothing that would account for the leak or come close to the system limit of 10 000 objects.
Any suggestion? Does anyone knows if some hidden system thread remains active even when my application is suspended? Thank you.
Ok, our team has been able to find one probable cause for the issue. Turns out that Microsoft's documentation tells only half the story. If at some point user and kernel objects were completely separate, recent versions of Windows have blurred the line.
As such, DDE transaction, monitor, keyboard layout, keyboard file, event hook, timer, input context, device info, touch data, gesture data and HID data should all be added to Microsoft's list of user objects. Some kernel methods may rely on user objects to provide services to apps.
To be specific, calls to RegisterRawInputDevices will result in the application receiving WM_INPUT messages. Those messages are backed by HID data and must be processed in a timely manner. If the process is suspended, unresponsive or otherwise fails to process incoming messages, there will be an accumulation and an exhaustion of system resources. This can quickly escalate into the problem described above and lead to an application crash.
I was attempting to verify that messages were being sent to my window using Spy++ (running Windows 7), but I mistakingly tried to spy on a console window that my program was using for debug output. Spy++ promptly notified me that "The specified window cannot be spied upon. Windows will not allow access to the message stream for this window."
While Spy++ does correctly gather other information about the window (e.x. name, style, class name), it cannot process the message queue. Why is this? And, out of morbid curiosity, is there a way to prevent Spy++ from accessing the message queue of my own custom window using the Windows API?
While Spy++ does correctly gather other information about the window (e.x. name, style, class name), it cannot process the message queue. Why is this?
The console window belongs to the CSRSS process, not the CMD.EXE process. CSRSS is a critical system service that is protected and cannot be hooked without special debug privileges.
"When a user-mode process calls a function involving console windows, process/thread creation, or side-by-side support, instead of issuing a system call, the Win32 libraries (kernel32.dll, user32.dll, gdi32.dll) send an inter-process call to the CSRSS process which does most of the actual work without compromising the kernel."
And, out of morbid curiosity, is there a way to prevent Spy++ from accessing the message queue of my own custom window using the Windows API?
Typically, no. Unless you manage to run your window in a protected system process.
So, I discovered this myself recently, I created a console .NET application which launches a process using CMD.EXE and I ran into an issue with some Win32 interop around the keyboard. So I broke out the previously trusty Spy++ utility to see what was happening to find that I was completely unable to monitor the message queue for my application from it.
So as per the op's question:
"Is there a way to prevent Spy++ from accessing the message queue of my own custom window using the Windows API?"
There is a list of restricted windows classes baked into Spy++:
SpyxxHk (presumably it's own hooking class),
#32768 (Context Menu),
#32769 (the Desktop),
ttyGrab ,
ConsoleWindowClass (Command Prompt)
So, if you in any way tie your app to these classes Spy++ will display that block message when attempting to watch their messages, of course this may not prove useful since it only restricts those classes.
Referring to MS documentation:
https://msdn.microsoft.com/en-us/library/windows/desktop/dd373640(v=vs.85).aspx
"For out-of-context events, the event is delivered on the same thread that called SetWinEventHook. In some situations, even if you request WINEVENT_INCONTEXT events, the events will still be delivered out-of-context. These scenarios include events from console windows and events from processes that have a different bit-depth (64 bit versus 32 bits)"
Suggests it is possible to get console window events.
There are seven ways in which a 'dormant' application can become the 'active' one, based upon the combinations of whether it is minimised or simply obscured, and whether it is re-activated via alt-tab, a mouse-click of its icon, re-activated by it being sent a windows message from another program, or is simply 'discovered' to be the top-most application on the desktop when the application obscuring it is closed (or minimised).
In all cases I need to know that my app is now the active (e.g. top-most on the desktop) application so that I can refresh its data from the database.
I do know that apps 'know' when they are the top-most, as I can see the border changing to the active colour as soon as they become top-most.
If I trap WM_ACTIVATE_APP messages, this works most of the time, but doesn't seem to when my app was minimised and is restored to the active state.
I need to be told that my app is now top-most and active before the user does anything.
Any suggestions? Thanks, Dave
Try the following:
After such a time has elapsed that the data from the database should be considered out of date, call InvalidateRect() on your window (or the WinForms equivalent). If your window is not obscured it will get an immediate WM_PAINT. But if the window is completely obscured, it shouldn't get the WM_PAINT until the OS actually needs to display it - i.e. when the obscuring window is moved. Refresh the data from the database in response to the WM_PAINT message.
It turns out Raymond Chen blogged about this back in 2003.
After investigating, I found the cause and solution to my problem.
I found out that the WM_ACTIVATEAPP message was being sent (and received) OK, but this happened while the app was still in it minimized state (i.e. before it was restored).
Because I had an if test to not do anything when the app is minimized ( which is pointless as the user wouldn't see the results!), no action was being taken.
The WM_ACTIVATEAPP message is sent when the app gets 'uncovered', and that is okay since the app isn't minimized.
I now also respond to the WM_WINDOWPOSCHANGED which gets fired upon restore,
and this combination seems to cover all seven ways in which my app can be re-activated.
Working in a plugin architecture (specifically, Sparx Systems Enterprise Architect), which does not forward either raw or cooked keyboard events, keyboard shortcuts for the plugin can be defined using RegisterHotKey(). These hotkeys are global, and the registration call fails if the specified key combination is already registered.
Since the application within which the plugin executes can be run in multiple instances, the hotkeys need to be repeatedly registered and unregistered based on which instance is in the foreground. An event hook for EVENT_SYSTEM_FOREGROUND can be set up for this purpose, but the question is: is there a guaranteed delivery order?
I need the instance that is losing focus to be told first so that it can unregister the hotkeys before the instance gaining focus tries to register them.
Is this possible? Or will I have to implement synchronization to be sure?
Windows DevCenter WM_ACTIVATE message says
..Sent to both the window being activated and the window being deactivated. If the windows use the same input queue, the message is sent synchronously, first to the window procedure of the top-level window being deactivated, then to the window procedure of the top-level window being activated. If the windows use different input queues, the message is sent asynchronously, so the window is activated immediately..
So if all of your windows come from the same application sharing the same input queue then it should be guaranteed. I guess that the EVENT_SYSTEM_FOREGROUND is built on top of the older code following the older logic (at least the implementation in ReactOS at http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/focus.c?view=markup (see EVENT_SYSTEM_FOREGROUND inside co_IntSetActiveWindow) does it)
Your problem might be easier if you'd monitor only keyboard events in your original hosting process (no global side effects) using the Windows DevCenter SetWindowsHookEx function, filter WH_KEYBOARD
In that case your code would exist once in one exe having one global variables, no cross-process synchronization would be needed