Why isn't FindWindowEx finding the label in my window?

Question

I'm trying to debug a little test driver application written in C#. It opens up several instances of a test app we have. The test app connects to a server and when successfully connected, displays "REMOTE_CONNECTED" in a label. So the test driver is looking for that before attempting to feed in data to the test app.

Here's what the code looks like:

  Console.Out.WriteLine("MAIN HANDLE IN GETCONN: " + Hwnd);
  //Attempt to find if we have have connected to the remote server
  IntPtr connHwnd = FindWindowEx(Hwnd, IntPtr.Zero, null, "REMOTE_CONNECTED");

That connHwnd always comes back a IntPtr.Zero and the Hwnd printed to the console is the handle I expect of the test app. The test driver sits in a loop for a while, repeatedly calling the above code until it finds that label. I can see on the screen that the label is displaying "REMOTE_CONNECTED" yet the function isn't finding it.

Furthermore, other folks have gotten this to work on XP (whereas I'm on Windows 7).

Finally, if I run this in Visual Studio and set some breakpoints, then it seems to work. So it doesn't seem like a logic flaw, but some sort of timing or contention issue.

Remember that FindWindowEx searches the `GetWindowText` string, not the `WM_GETTEXT` value. — Raymond Chen, May 03 '12 at 17:58
Spy++ can be really helpful in tracking stuff like this down. — Rob P., May 03 '12 at 18:00
check this post http://stackoverflow.com/questions/5241984/findwindowex-from-user32-dll-is-returning-a-handle-of-zero-and-error-code-of-127 — volody, May 03 '12 at 18:00
Yeah, I read that other post, but what really confuses me is that it works when there are breakpoints set. I'll also investigate Mr. Chen's suggestion. — Mutmansky, May 03 '12 at 18:14
Are the breakpoints *hit* in the cases where it works? (That is, could it be a *timing* issue?) — , May 03 '12 at 18:21
Yes, the breakpoints are hit, so yes it definitely could be a timing issue. But why would that matter? The main loop is sitting there, sleeping for a second and then trying to call FindWindowEx ever second or so for 30 seconds. Visually, I can see the label has the text I'm looking for, so why can't FindWindowEx find it? — Mutmansky, May 03 '12 at 18:42
So looking in Spy++, it appears the Window Handle of the parent is not the same as the Handle I'm printing out in my code. Interesting... At least that gives me something to go on. — Mutmansky, May 03 '12 at 18:48
Actually, this post seems to hold more promise: http://stackoverflow.com/questions/4727023/why-cant-get-the-main-window-handle-for-a-started-process — Mutmansky, May 03 '12 at 19:53
Also consider security - is the test driver running as a low-privileged user? In a different user context? — Ben, May 03 '12 at 20:54

score 1 · Accepted Answer · edited May 23 '17 at 11:49

My issue turned out to be similar to that in this question:

Why can't get the main window handle for a started process?

My MainWindowHandle was not set to the window I expected it to be (which I figured out using Spy++, thanks Rob P.!). So I wrote some code using EnumWindows to find the Window I was looking for (see Joshua's answer in the linked post) and then used that Window Handle to pass into the FindWindowEx and everything worked as expected.

Why isn't FindWindowEx finding the label in my window?

1 Answers1