A C++ background program developed in Visual Studio, called monitor, watches another program, called target, and restarts it each time it exits. A somewhat simplified version of the program is shown below.
#include <windows.h>
#include <tlhelp32.h>
#include <Process.h>
void BindToProcess();
const WCHAR PATH[] = L"C:\\Windows\\System32\\notepad.exe";
const WCHAR EXE[] = L"notepad.exe";
int CALLBACK WinMain(
_In_ HINSTANCE hInstance,
_In_opt_ HINSTANCE hPrevInstance,
_In_ LPSTR lpCmdLine,
_In_ int nShowCmd)
{
do
{
BindToProcess();
_wspawnl(_P_WAIT, PATH, PATH, NULL);
} while (TRUE);
return 0;
}
void BindToProcess()
{
HANDLE hProcessSnap;
PROCESSENTRY32 pe32;
// Take a snapshot of all processes in the system.
hProcessSnap = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
if (hProcessSnap == INVALID_HANDLE_VALUE) return;
// Set the size of the structure before using it.
pe32.dwSize = sizeof(PROCESSENTRY32);
// Retrieve information about the first process,
if (!Process32First(hProcessSnap, &pe32))
{
CloseHandle(hProcessSnap);
return;
}
// Now walk the snapshot of processes, and search for target
do
{
const int len = (int) wcsnlen_s(EXE, 10);
if (CompareStringW(0, 0, pe32.szExeFile, len, EXE, len) == CSTR_EQUAL)
{
HANDLE handle[1];
handle[0] = OpenProcess(SYNCHRONIZE, FALSE, pe32.th32ProcessID);
WaitForMultipleObjects(1, handle, TRUE, INFINITE);
CloseHandle(handle[0]);
CloseHandle(hProcessSnap);
return;
}
} while (Process32Next(hProcessSnap, &pe32));
CloseHandle(hProcessSnap);
return;
}
Monitor first checks to see if target is running and, if so, binds itself to it. It stays inactive until target exists. Then it restarts target and again stays inactive until target exists, just to restart it once more.
In the mockup program, I use notepad.exe as the target. In the real system, it is an application that searches the internet and displays the results in a graphical user interface. In practice, target never exits unless deliberately killed, so monitor does not loop; it stays hanging. Nevertheless, I observe that its memory grows.
Monitor never uses new() or malloc() to allocate memory. The only allocations occur in the calls to CreateToolhelp32Snapshot() and OpenProcess(), but the corresponding memory is released through calls to CloseHandle(). Therefore, no memory leaks should ever occur, even if the program was looping, but it doesn't, it hangs.
Why does a hanging program's memory grow? I observe both memory increases and memory decreases, but in the long run, memory grows.
This happens because the information accessed by your program is variable.
CreateToolhelp32Snapshot() does not always have the same memory usage because it is a snapshot of processes at any given time. Processes vary a lot, some can close and others can start.
And the snapshotted process information varies too. For example you are checking szExeFile which does not have a fixed size.
Also, memory allocation is sometimes done in blocks. So one run can reserve a block that is bigger or smaller, depending on what is available.
As long as the memory does not grow indefinitely this behavior is normal.
Related
I have read that I need to have the HWND placed on the heap. Is that correct?
I need this to read values from user input.
Thank you in advance!
VOID MakeThread(HWND hWnd)
{
HWND* h = new HWND(hWnd);
HANDLE hThread = (HANDLE)_beginthreadex(nullptr, 0, WorkerThread, h, 0, nullptr);
if (hThread != nullptr) {
WaitForSingleObject(hThread, INFINITE);
CloseHandle(hThread);
}
delete h;
}
unsigned int __stdcall WorkerThread(VOID* h)
{
char num[71] = { 0 };
GetDlgItemTextA((*(HWND*)h), 2001, num, 70);
//Get number from edit box 2001
//Do work with the above-mentioned number
return 0;
}
I have read that I need to have the HWND placed on the heap. Is that correct?
Not really. Assuming that the HWND remains valid for the duration of the created thread (if it is the application's main window, then that is a reasonable assumption), and that the MakeThread function will not return until that thread is finished (as is the case in your code), then you can just give the address of its HWND hWnd argument as the arglist parameter in the call to _beginthreadex.
You don't have to create a copy of that window handle on the heap. Here's a simplified version of your MakeThread function:
VOID MakeThread(HWND hWnd)
{
stringstream stream;
stream << &hWnd << "\n" << hWnd;
std::string s = stream.str();
MessageBoxA(hWnd, s.c_str(), "Caller: hWnd?", 0);
HANDLE hThread = (HANDLE)_beginthreadex(nullptr, 0, WorkerThread, &hWnd, 0, nullptr);
if (hThread != nullptr) {
WaitForSingleObject(hThread, INFINITE);
CloseHandle(hThread);
}
}
However, if your MakeThread function were to return without waiting for the created thread to complete, then that passed address would become invalid (at some point). But, in that scenario, you would have to make other changes to your code, so that you could keep track of the created thread handle.
An HWND is already a pointer type (to a global system resource). You can just pass it around as-is, there is no need to wrap it with new at all:
void MakeThread(HWND hWnd)
{
HANDLE hThread = (HANDLE)_beginthreadex(nullptr, 0, WorkerThread, hWnd, 0, nullptr);
if (hThread != nullptr) {
WaitForSingleObject(hThread, INFINITE);
CloseHandle(hThread);
}
}
unsigned int __stdcall WorkerThread(void* h)
{
char num[71] = { 0 };
GetDlgItemTextA((HWND)h, 2001, num, 70);
//Get number from edit box 2001
//Do work with the above-mentioned number
return 0;
}
That being said, creating a thread just to immediately wait for its termination is a complete waste of a thread. You may as well just call the target function directly instead, the end result will be exactly the same, just without the extra overhead:
void DontMakeThread(HWND hWnd)
{
WorkerThread(hWnd);
}
As soon as you use new HWND(hWnd), your object will be allocated on the heap by default, not stack. Thus, you can share it across without a risk the object to be lost due the stack unwinding.
Another point is you start the thread and then wait for the completion. As a side-effect, you could use even a stack-allocated data to pass to the thread because the stack is here until the thread exit (exactly, WaitForSingleObject line).
And handling user input is not related to heap/stack allocation in general. Could you re-phrase your question in that part or create another question on that mean?
So I've created a basic program with a blocking message event loop (to use little to no CPU while waiting) and waits for a user to change the foreground window, then executes some code:
#include <Windows.h>
VOID ExitFunction()
{
// Do Something
}
BOOL WINAPI HandlerRoutine(DWORD dwCtrlType)
{
switch (dwCtrlType)
{
case CTRL_SHUTDOWN_EVENT:
ExitFunction();
return TRUE;
case CTRL_LOGOFF_EVENT:
ExitFunction();
return TRUE;
//default:
//We don't care about this event
//Default handler is used
}
return FALSE;
}
VOID CALLBACK WinEventProcCallback(HWINEVENTHOOK hWinEventHook, DWORD dwEvent, HWND hwnd, LONG idObject, LONG idChild, DWORD dwEventThread, DWORD dwmsEventTime)
{
if (dwEvent == EVENT_SYSTEM_FOREGROUND)
{
// Do Stuff
}
}
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
MSG msg;
HWINEVENTHOOK WindowChangeEvent;
SetConsoleCtrlHandler(HandlerRoutine, TRUE);
WindowChangeEvent = SetWinEventHook(EVENT_SYSTEM_FOREGROUND, EVENT_SYSTEM_FOREGROUND, NULL, WinEventProcCallback, 0, 0, WINEVENT_OUTOFCONTEXT | WINEVENT_SKIPOWNPROCESS);
while (GetMessage(&msg, NULL, 0, 0, PM_REMOVE) > 0)
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
ExitFunction();
return 0;
}
I also want to incorporate checking if the user has been inactive for a certain amount of time (no mouse/keyboard input) but keep resource usage low. There are a couple of ways to approach this that I can think of:
Have the blocking event loop check if there has been mouse or keyboard input which resets some kind of timer back to zero and also checks within the same loop if the mouse input resulted in a foreground window change (which may cause issues if there is a delay between the mouse click event and the foreground window change (meaning the foreground window change won't be captured). Have an event triggered when the user input timer has completed the specified time.
Run the mouse & keyboard activity event timer on a separate thread or asynchronously to the foreground window change event. When the timer has completed fire off an event (run on separate thread or asynchronously to make sure a foreground window change event isn't missed).
On a separate thread or asynchronously, check every couple seconds the GetLastInputInfo() function to see if the inactivity threshold time has elapsed.
It can be called like so:
LASTINPUTINFO li;
li.cbSize = sizeof(LASTINPUTINFO);
GetLastInputInfo(&li);
Keeping in mind lowest resource usage, what way is best to implement the mouse/keyboard inactivity checking while also checking for foreground window changes.
You can set up a timer (see SetTimer) to have a user-defined callback called when an arbitrary timeout expires. This allows you to break out of the blocking GetMessage loop.
The callback can check the timestamp of the last input, and compare it to the current timestamp. If that time interval exceeds the desired inactivity timeout, it can perform the necessary steps. Otherwise it restarts the timer with the remainder of the timeout.
The following code illustrates this:
#include <Windows.h>
#include <iostream>
static const DWORD timeout_in_ms { 5 * 1000 };
void TimeoutExpired() { std::wcout << L"Timeout elapsed" << std::endl; }
void CALLBACK TimerProc(HWND, UINT, UINT_PTR id, DWORD current_time)
{
// Timers are periodic, but we want it to fire only once.
KillTimer(nullptr, id);
LASTINPUTINFO lii { sizeof(lii) };
GetLastInputInfo(&lii);
auto const time_since_input { current_time - lii.dwTime };
if (time_since_input < timeout_in_ms)
{
// User input was recorded inside the timeout interval -> restart timer.
auto const remaining_time { timeout_in_ms - time_since_input };
SetTimer(nullptr, 0, remaining_time, &TimerProc);
}
else
{
TimeoutExpired();
}
}
void StartInactivityTimer()
{
// Start a timer that expires immediately;
// the TimerProc will do the required adjustments and
// restart the timer if necessary.
SetTimer(nullptr, 0, 0, &TimerProc);
}
int wmain()
{
StartInactivityTimer();
MSG msg {};
while (GetMessageW(&msg, nullptr, 0, 0) > 0)
{
DispatchMessageW(&msg);
}
}
The entire logic is contained within TimerProc. To trigger the inactivity timer, StartInactivityTimer starts a timer that expires immediately. When TimerProc takes control it does the required calculations, and either restarts the timer, or calls the timeout procedure, TimeoutExpired.
This implementation has two advantages: For one, the entire timer restart logic is in a single place. More importantly, the inactivity condition is evaluated on first call. If StartInactivityTimer is called without any user input in the inactivity interval, it instantly executes TimeoutExpired.
Also note that the interval calculations use unsigned integer arithmetic, specifically subtraction. With unsigned integer 'underflow' being well defined in both C and C++, this solution is immune to GetTickCount's return value wrapping around to 0 after approximately 49.7 days.
I have a simple (windows) application that launches another application using the CreateProcess function. It then gets the correct hwnd by using EnumWindows and the process id of the newly created process.
After the hwnd has been gained, the 'main loop' of my applications begins. This loop continues until the application started by CreateProcess is no longer running.
Everything works perfectly, until I try to use PeekMessage to peek at the messages being sent to the application I have launched - It seems that no messages at all are being recognized by my application, but the program that was launched (via CreateProcess) is running as normal, doing everything it should..
What I am trying to achieve, is to remove certain messages from being sent to the application, mainly various F-keys (F1, F2..F12 keys), but also, if possible, I would like to change the menu shown in the application (I dont know the technical name for the menu I mean, its the one you see what you click on the application icon in the top right corner) - I want to add a small 'about' option.
If anyone could point out what I am doing wrong within my code, or to a better alternative for stopping certain keypresses from reaching the launched application, I would be very grateful.
Many thanks in advance. :)
Here is the code I currently have:
VOID PerformLaunch(LPWSTR lpAppName, LPTSTR lpCmdLine) {
STARTUPINFO si;
PROCESS_INFORMATION pi;
DWORD dwLoopExitCode = NULL;
BOOL cpBool = FALSE;
BOOL finishedLoop = FALSE;
MSG message = { 0 };
ZeroMemory(&pi, sizeof(PROCESS_INFORMATION));
ZeroMemory(&si, sizeof(STARTUPINFO));
si.cb = sizeof(STARTUPINFO);
cpBool = CreateProcess(lpAppName, lpCmdLine, NULL, NULL, TRUE, 0, NULL, NULL, &si, &pi);
if (!cpBool) {
MessageBox(Game_HWND, L"Could not start process!", L"Error:", MB_OK | MB_ICONERROR);
}
//-- Enumerate windows until Game_HWND && Game_Hook are not NULL.
while (Game_Hook == NULL) {
EnumWindows(MainEnumGameWindProc, pi.dwProcessId);
}
while (!finishedLoop) {
DWORD dwWC = WaitForSingleObject(pi.hProcess, 0);
if ((dwWC == WAIT_FAILED) || (dwWC == WAIT_OBJECT_0)|| (dwWC == WAIT_ABANDONED)) {
DWORD dwExitCode;
GetExitCodeProcess(pi.hProcess, &dwExitCode);
CloseHandle(pi.hThread);
CloseHandle(pi.hProcess);
dwLoopExitCode = dwExitCode;
finishedLoop = TRUE;
}
else {
if (PeekMessage(&message, Game_HWND, 0, 0, PM_REMOVE)) {
TranslateMessage(&message);
DispatchMessage(&message);
if (WM_QUIT == message.message) {
finishedLoop = TRUE;
break;
}
}
}
}
}
You can't intercept another message loop like that. Remember, that process will be doing its own message pump - it's not okay for you to be dispatching its messages, and I expect things would go very weird if you do.
The correct way is to set a hook. Use the SetWindowsHookEx function to install a hook on that window.
Reference for SetWindowsHookEx
PeekMessage retrieves messages only from the message queue, associated with the its calling thread. Window, which messages you are trying to peek belongs to the different thread, so PeekMessage with its handle will never give you anything. You could either install a hook, or subclass its window procedure.
I've created a program to identify existing maximized windows and log their locations using EnumWindows and GetWindowPlacement.
Assuming I know the location of a desired EXE, I can open it just by calling the external process caller. But what is the best way to identify the newly opened window and set its location? It's safe to assume that a program with the same name may already be open (two instances of cmd, for instance).
I believe once the window is identified I can set its location with SetWindowPos.
Is this the right question to be asking? Is there a way to open a program and receive a HWND handle back instead?
In the Event Hook vein, I have this code:
HWINEVENTHOOK hook = SetWinEventHook(EVENT_OBJECT_CREATE, EVENT_OBJECT_CREATE, NULL, proc, 0, 0, WINEVENT_OUTOFCONTEXT );
BOOL result = CreateProcess(NULL, szPath, &saProcess, &saThread, FALSE, 0, NULL, NULL, &si, &piProcessC);
if (hook) {
UnhookWinEvent(hook);
}
Which creates a hook and then creates a process (I'm opening up Notepad++).
The proc function it calls is:
void CALLBACK proc(HWINEVENTHOOK hook, DWORD event, HWND hWnd, LONG obj, LONG child, DWORD thr, DWORD time) {
if (IsWindow(hWnd)){
WINDOWPLACEMENT *wp = new WINDOWPLACEMENT();
wp->length = sizeof(WINDOWPLACEMENT);
GetWindowPlacement(hWnd, wp);
wp->rcNormalPosition.top = (long) 363;
wp->rcNormalPosition.bottom = (long) 1021;
wp->rcNormalPosition.left = (long) 1444;
wp->rcNormalPosition.right = (long) 2551;
BOOL tmp = SetWindowPlacement(hWnd, wp);
cout << "FOUND IT\n";
}
}
The proc function does not appear to get called, so is the hook not catching anything?
Oh, and I'm not sure the WINEVENT_OUTOFCONTEXT is right, this is just a simple EXE doing the calling.
I think i am ruining in to a deadlock, have been searching for the solution over hours. Any suggestions?
What i am trying to do is: ater startGame button click, create thread that send request to the server and then gets the answer, after the answer the thread must send a message to Initialize game window to the main proc...
Message Proc that belongs to WinMain:
LRESULT CALLBACK WndProc(HWND myWindow, UINT messg, WPARAM wParam, LPARAM lParam)
{
switch (messg) {
case WM_STARTGAME:
DestroyWindow(hStartGameButton);
DestroyWindow(hHistoryButton);
InitGameWindow(myWindow);
break;
case WM_COMMAND:
switch(LOWORD(wParam))
{
case IDC_STARTGAME_BUTTON:
{
parametros param;
param.myWindow = myWindow;
start_game = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)ThreadStartGame, (LPVOID)&myWindow, 0, NULL);
}
}
}
And this is the thread:
DWORD WINAPI ThreadStartGame(LPVOID param){
HWND w = (HWND)param;
DWORD n;
BOOL ret;
mensagem resposta;
mensagem msg;
msg.tipo = COMECAR_JOGO;
msg.verifica = true;
if (!WriteFile(hPipe, &msg, (DWORD)sizeof(mensagem), &n, NULL)) {return 0;}
ret = ReadFile(hPipeN, &resposta, (DWORD)sizeof(mensagem), &n, NULL);
if (!ret || !n) {
return false;
}
PostMessage(w, WM_STARTGAME, NULL, NULL); // <- THIS GETS EXECUTED BUT NOTHINK HAPPENS AFTER
return 0;
}
I don't think there is any deadlock here.
start_game = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)ThreadStartGame, (LPVOID)&myWindow, 0, NULL);
This line passes the address of the HWND to the thread (&myWindow)
HWND w = (HWND)param;
This line uses the adress itself as HWND and the SendMessage sends the message to this address which is not a HWND.
Try modifying to
start_game = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)ThreadStartGame, (LPVOID)myWindow, 0, NULL);
W/o even looking at the code, I can tell you right away: do not use SendMessage between threads. I recommend reading Psychic debugging: The first step in diagnosing a deadlock is a simple matter of following the money and Preventing Hangs in Windows Applications:
Use asynchronous window message APIs in your UI thread, especially by replacing SendMessage with one of its non-blocking peers: PostMessage, SendNotifyMessage, or SendMessageCallback
...
Any blocking call that crosses thread boundaries has synchronization properties that can result in a deadlock. The calling thread performs an operation with 'acquire' semantics and cannot unblock until the target thread 'releases' that call. Quite a few User32 functions (for example SendMessage), as well as many blocking COM calls fall into this category.
For starters, you're unlikely supposed to do that in the first place. Quoting MSDN:
A thread in an executable that calls the C run-time library (CRT) should use the _beginthreadex and _endthreadex functions for thread management rather than CreateThread and ExitThread; this requires the use of the multithreaded version of the CRT. If a thread created using CreateThread calls the CRT, the CRT may terminate the process in low-memory conditions.
Second, your thread can be worker or UI thread, from the first type you must not call most of the window related functions, as it has no message pump. DestroyWindow is such. (So many times I tried to use MessageBox despite my own comment a few lines upper telling it's forbidden in that function ;).
From worker threads the usual method is to use PostThreadMessage and react on the UI thread. (If you have multiple UI threads, I don't know the rules, was never brave enough for that.)