(UPDATED on 18/09/2008)
    Added: Child Windows on Window Tooltip, Opacity setting for Tooltip Window
(UPDATED on 15/09/2008)
    Added: Window Tooltip, shows window information during 'Find Window' 
(UPDATED on 09/09/2008)
    Added: Modifications and ModifiedMsg added to the Breakpoints.
    Modification: Indicates that which sections of the message will be modified if the Action is AutoChangeParameters.
    ModifiedMsg: If a breakpoint's action is AutoChangeParameters and Modification has the Message bit,
                          then PV will change the incoming message to the given message.
                          For ex: You can change the WM_LBUTTONDOWN to WM_RBUTTONDOWN automatically for the target window.
    Multilanguage: (English, Turkish)

Process Viewer 1.0.7.0 (PV) is ready to download. Download Source Codes | Watch Sample Movie (v1.0.5.0)
Below I try to explain what is PV and how it is working. Also I put some screenshots of the PV.


I finished PV 2 days ago, but I was really very sleepy (it was about 4 AM and I had to go to work in the morning) so I postpone this writing to a later time. Anyway today I have some time to write something about PV. What it is? What it is for? How it works?
First I will explain what PV is then I will try to explain its codes a little bit more.

 What is PV?
I can say that PV is a program like Microsoft Spy++. Unlikely to Spy++ it allows you to edit some properties of the Controls and also allows you to manage its window messages. You can change Text, Visibility, Enabled, Window Styles and Window Ex Styles properties of a control by using PV during runtime. Therewithal you can ignore window messages, change incoming message to a different message or edit parameters of any window messages by putting breakpoints to the control’s window procedure with PV.



How can I use PV?
It is really very simple to use PV. Run PV.exe and you will see the active Processes, currently running in your desktop, in the Windows List at the left of the program. Expand any process which you are interested in. You will see the Windows (Controls) which are belong to that process in a hierarchical list. Whenever you select a Window from the list PV will highlight its area in the screen even the window is not visible at the moment. If a Window is a container window which contains inner windows in it you will see inner windows under the owner (parent) window node, so you can expand parent window and see inner windows of it.

There is also Find Window button at the top of the PV which will help you to find Controls and select them easily. Just click to the Find Window button and Drag it over the Controls while you are pushing the Left mouse button. PV will highlight the Control region which mouse currently on it. To select a window, release mouse button when the mouse cursor is on that control. Window will be selected automatically in the Windows List. If window is not in the list (this might be, because PV generates Windows List while it is opening so if the window you try to select was created after you opened PV then this window won't be in the list), PV will shows an alert to you that the window is not in the windows list at the moment, if you chose “Yes” button it will automatically refreshes the Windows List and finds your control.

When you select a window from the windows list you will see its properties in the PropertyGrid at the right. You can change Visible, Enabled, Text, WindowStyles and WindowExStyles properties of that window by using PropertyGrid. Also you can change the window’s Bounds, Size and Location by the same way. If you wish to see the Messages of that control, click to the Listen Messages button at the top toolbar. A panel which contains a TextBox will appear at the bottom of the PV which will shows you the messages of that control. If you want to put breakpoints to the current window’s message procedure click to the Edit Breakpoints button. Breakpoint Management window will be shown and you can add breakpoints to that window by using this window. Select a window message from the list (you can filter messages by writing your message name to the filter textbox) to see breakpoint properties for that message. Select your action (None, Ignore, Manuel Edit, Auto Change) by using PropertyGrid for the selected message(s). You can do same things for the other messages which you are interested in. To remove a message breakpoint just set its action to “None”. After you finished you can close the Breakpoints window by clicking “Okey” button. From now on your breakpoints will be activated and whenever a message, which you define an action for that, arrives to that window PV will do the action which you select for that message.

For example; If you chose WM_LBUTTONDOWN, which system sends to the control when mouse left button is down on that control, from the message list and select ‘Ignore’ action then WM_LBUTTONDOWN message will never send to the control. Or if you choose ManuelEditParameters action for the WM_LBUTTONDOWN then PV will shows you Edit Parameters Window to choose your action against this message when this message arrives to the control. Either you can ignore this message or you can change the wParam and lParam parameters of the message. WPARAM (4 bytes) and LPARAM (4 bytes) of a message contain message specific parameters and they have different meanings according to the Message. If we speak about the WM_LBUTTONDOWN message, the parameters will be;
wParam: Indicates whether various Virtual Keys (MK_LBUTTON, MK_RBUTTON, MK_CONTROL, MK_MBUTTON, MK_XBUTTON1, MK_XBUTTON2) are down. WParam can be one or more of these values.
lParam: Lo-Order of the lParam specifies the X-Coordinate of the cursor and Hi-Order of the lParam indicates the Y-Coordinate of the cursor. Here Lo-Order means first 2 bytes of the lParam and Hi-Order means the last 2 bytes of the lParam.
If you choose Manuel Edit Parameters action for the WM_LBUTTONDOWN then you can change the parameters of It whenever system sends this message to the target window. If you choose AutoChangeParameters action then PV will change wParam and lParam of that message automatically as you defined.

Examples with Breakpoints; Example 1:  1 – Open Visual Studio .NET  2 – Select Main Menu of the VS.NET by using Find Window button of the PV.  3 – Click “Listen Messages” button to start message hook for the main menu  4 – Click “Edit Breakpoints” button to set breakpoints  5 – Select WM_LBUTTONDOWN from the message list and select AutoChangeParameters action for this message.        Set Modifications to the WParam and LParam (Indicates PV will modify only WParam and LParam of a message before it send to the hooked window)        Set XParam to the 1 (LoWord:1, HiWord:0) and LParam to the 851998 (LoWord:30, HiWord:13). Click Okey button.  6 – Click anywhere in the Main Menu, you will see that always File menu is shown. This is because PV change the LParam to the HiWord:13 and LoWord:30 which means (X=30, Y=13) the cursor position is over the File menu. So main menu opens File menu always because it thinks that File menu has been clicked. Example 2: 1 – Open Visual Studio .NET  2 – Select Main Menu of the VS.NET by using Find Window button of the PV.  3 – Click “Listen Messages” button to start message hook for the main menu  4 – Click “Edit Breakpoints” button to set breakpoints  5 – Select WM_LBUTTONDOWN from the message list and select AutoChangeParameters action for this message.        Set Modifications to the Message and set ModifiedMsg to the WM_RBUTTONDOWN. Click Okey button to set the breakpoints.  6 – Click anywhere in the Main Menu, you will see that even you click to the Left button of the mouse the main menu always opens its Context Menu. This is because PV change the WM_LBUTTONDOWN message to he WM_RBUTTONDOWN.

I think this is enough for “How We Use PV?” Let us speak about the “How PV do this?”
We can split this question in to two sections. One is “How PV finds Windows?” and second is “How PV Listens and Edit Messages of a Control?”
For the first question PV uses EnumChildWindows method to enumerate child windows of a Window. It first tries to find the Desktop Window’s child windows and then it finds the inner windows. After it finds the windows, it uses GetClassName, GetWindowThreadProcessId and GetParent methods to find the ClassName, ProcessId, ThreadId and Parent Window Handle of these windows. 



For the second question “How PV Listen and Edit Messages of a Control?”; it is a little bit harder than the first section. To make this, first I wrote a C++ (Native) dll which sets hook on WH_CALLWNDPROC for the given window’s thread. Why I wrote this dll with C++? Actually listening a control’s Windows Messages, is simple. Every control has a Window Procedure method which system sends messages to that method. We can learn the address of this method by using GetWindowLong method with the GWL_WNDPROC option. To change the window procedure method of a control is also very simple;
SetWindowLong(windowHandle, GWL_WNDPROC, [our procedure Method]). By using this method we can replace the message procedure method of a control to our method. So whenever system sends a message to this control it will comes to our method and we can do anything we want in this method. To redirect this message to the original window procedure, we can use CallWindowProc function. But the problem with this is; SetWindowLong method works only for the windows which are belongs to same process. It means that we can use this method for the controls which are in the same process with us. So if we want to change windows procedure of a control we have to be in the same process. How we can handle this problem? To handle this problem I wrote a native dll which will be injected to the target process and we will run the SetWindowLong function from that dll within the target process. Injecting a dll to another application is also a pain for us. There are some solutions for this problem;
1 – We can use SetWindowsHookEx method to set a WH_CALLWNDPROC hook. By setting a hook Windows will automatically Loads our hook dll to all processes. But the problem with this method is, we don’t know the target process is .NET or not. So we have to write a native dll for this hook operation. Because if the target process is not .NET this means there is no CLR attached to that process and our .NET dll won’t be worked within this process. When we call SetWindowsHookEx function systems attach the dll, which contains the hook method, to all processes. At this point; you have to know that for each process, system creates a new instance of our dll and attach it to every process.
2 – LoadLibrary method which is in kernel32.dll loads a library to the caller application. So if we make a call to that function within the target process we can load our library to the target application. How we can call LoadLibrary function within another application? To solve this problem we can use CreateRemoteThread function which is in the kernel32.dll. CreateRemoteThread function creates a remote thread within a given process and runs the given method. To use CreateRemoteThread function we have to also know the address of the target method which we want to run in the target processes memory block. Actually this is hard to find the address of a function in a remote application. GetProcAddress function returns the address of a method, but when we call this method this will be the address of that method within our application because again GetProcAddress will return the address of the function according to the caller process memory. But here is a good trick with the LoadLibrary. LoadLibrary method is in the kernel32.dll and kernel32.dll will always load to the same address for all the windows applications according to nature of windows. So if we take the address of the LoadLibrary function within our application’s memory, this address also will be same for other applications too. So we can take the address of the LoadLibrary and call this method by using CreateRemoteThread method within target process. This will load our dll to the target procedure.

Anyway there are too many details about dll injection so I pass it simply for now. May be we can talk about this later more detailed. In PV I have been used the first way to make dll injection. I wrote a C++ (Native) dll which starts WH_CALLWNDPROC hook on the target process. WH_CALLWNDPROC installs a hook procedure which monitors the messages before the system sends them to the destination window. When the first time that system sends a message to our target window we changed the target window’s message procedure method by using SetWindowLong function. Actually we are using hook operation for two cases; one is injecting our native dll to the target process and second triggering procedure changing method (calling SetWindowLong) from that dll. Therefore SetWindowLong function will be called by the target process. As I said above we can do this in some different ways but I chose this way. Because this way needs less native codes than the others and I want to write less native codes in this example.

// In the PV [DllImport("ProcessViewer.Hooks.dll")] public static extern int StartHook(IntPtr hWnd, IntPtr notifyWindow);   [DllImport("ProcessViewer.Hooks.dll")] public static extern void EndHook(); // In the native dll PROCESSVIEWERHOOKS_API int WINAPI StartHook(HWND hWnd, HWND notifyParent) {        originalWindowProcedure = 0;          // Load our libary and get its handle        HINSTANCE phookDll = LoadLibrary((LPCTSTR)_T("ProcessViewer.Hooks.dll"));          EndHook();          hookWindow = hWnd;        notifyWindow = notifyParent;          // get Thread Id of the Window, which we will hook        DWORD threadId = GetWindowThreadProcessId(hWnd, NULL);        // get address of our Hook method in this dll        HOOKPROC proc = (HOOKPROC)GetProcAddress(phookDll, "MessageHookProcedure");        // set Hook (This will injects our dll in to all process        // which are created by the given thread)        hhk = SetWindowsHookEx(WH_CALLWNDPROC,                                                proc,                                                phookDll,                                                threadId);          return (DWORD)hhk; } // this is our WH_CALLWNDPROC hook method LRESULT CALLBACK MessageHookProcedure(int nCode, WPARAM wParam, LPARAM lParam) {        if (originalWindowProcedure == 0)        {              // the first time this method is called              // for the our hooked window, replace its window procedure              // to our procedure method              // do this just for the control which we wnat to listen its messages              CWPSTRUCT* str = (CWPSTRUCT*)lParam;              if (str->hwnd == hookWindow)              {                     // take original windows procedure of this control                     originalWindowProcedure = GetWindowLong(hookWindow, GWL_WNDPROC);                     // set new windows procedure                     SetWindowLong(hookWindow, GWL_WNDPROC, (LONG)OnMessage);              }        }        return CallNextHookEx(hhk, nCode, wParam, lParam); } // ends hook operation PROCESSVIEWERHOOKS_API void WINAPI EndHook() {        // if we have been taken procedure of the window,        // set its procedure to the its original        if (originalWindowProcedure)              SetWindowLong(hookWindow, GWL_WNDPROC, originalWindowProcedure);        if (hhk != NULL)              UnhookWindowsHookEx(hhk);        originalWindowProcedure = 0;        hhk = NULL; }

From now on any message that system sends to the target window will come to our method because system thinks that window procedure method for that control is our method. Now we need to send this message to the PV to process it. At this point I used VM_COPYDATA message to transfer message to the PV. But to whom I will send this message? I wrote a Listener Control in the PV and I pass its handle to the hook dll while PV starts the hook operation. Hook dll sets this passed handle to a shared variable in it. This way every instance of the native dll has the same value for that variable. So native dll in the target process also has the same variable which holds our listener controls handle. From the native dll which handles the target window’s messages I redirect messages to the Listener Control which is in the PV. Whenever a new WM_COPYDATA messages send to the Listener Control it resolves the original message from the LParam of that message and process it according to our Breakpoints. LParam of the WM_COPYDATA message contains a COPYDATASTRUCT which has original message in it is lpData field.

private class ListenerControl : Control {        static int HM_MESSAGE_RESULT;          public ListenerControl()        {              HM_MESSAGE_RESULT = NativeMethods.RegisterWindowMessage(                                                         "ProcessViewer_MessageResult");              Parent = MainForm;        }          protected override void WndProc(ref Message m)        {              if (m.Msg == (int)NativeMethods.Msgs.WM_COPYDATA)              {                     // message was sended by ProcessViewer.Hooks.dll from the Hooked application when                     // a new message comes to that window                       // LPARAM of this message contains a COPYDATASTRUCT which has HOOK_MSG struct in it                     NativeMethods.COPYDATASTRUCT cdata =                             (NativeMethods.COPYDATASTRUCT)m.GetLParam(                                              typeof(NativeMethods.COPYDATASTRUCT));                     // This is the information of the message which is sended to the hooked window                     NativeMethods.HOOK_MSG msg = (NativeMethods.HOOK_MSG)                                              Marshal.PtrToStructure(cdata.lpData,                                                   typeof(NativeMethods.HOOK_MSG));                       // process message and set its result (0 ignore, 1 do nothing,                     // other values replace parameters)                     m.Result = MainForm._SubClass.ProcessMessage(m.WParam, ref msg);                     Marshal.DestroyStructure(m.LParam, typeof(NativeMethods.COPYDATASTRUCT));              }              else if (m.Msg == HM_MESSAGE_RESULT                      && Properties.Settings.Default.HandleMessageResults)              {                     // this message sended by hooked window to give                     // information about the result of a message                     MainForm._SubClass.ProcessMessageResult(m.WParam.ToInt32(), m.LParam);              }              else              {                     base.WndProc(ref m);              }        } }

While PV processing message native dll is waiting for the result and does its action according to this result which comes from the PV. If we don’t have a breakpoint for that message PV returns 1 which means “send message to the original window procedure”.  If we have a breakpoint for this message which the action is “Ignore message”, then PV returns 0 to the native dll and it ignores that message. The hard section of breakpoints is what if we have the “Edit Parameters Manually“ or “Auto Change Parameters” actions for that message. It is hard because we need to transfer changed parameters to the native dll which is running in the target application. We solve this problem by allocating a memory block in the target applications memory by using VirtualAllocEx function. Then we write our changed values to that block by using WriteProcessMemory function. These functions allow us to allocate a memory block in the target application memory block and write to this block. Now we have the address of that memory so we can pass this address to the native dll as the address of new wParam and lParam values. If native dll takes a return value differs from 1 and 0 it knows that this is a memory address which contains new wParam and lParam values. So it reads new values of the parameters from this address and redirects message to the original window procedure by using these parameters. This way we changed the parameters of the message. We can also use this WriteProcessMemory and VirtualAllocEx methods to transfer message from native dll to PV instead of using VM_COPYDATA. But I transfer data by using VM_COPYDATA because VM_COPYDATA message is for transferring data between two processes. Why I don’t use WM_COPYDATA message for transferring result of the message from PV to the native dll instead of using WriteProcessMemory function? The answer is simple. Because I send the incoming message to the PV, by using SendMessage function from window procedure method in the native dll. Thread which calls the SendMessage function will block until it takes a result. So if I try to send return value by using SendMessage to the target window this will be a deadlock.

IntPtr WriteToTargetProcessMemory(IntPtr wParam, IntPtr lParam, NativeMethods.Msgs modifiedMsg) {        // Open hooked window's process        IntPtr hProcess = NativeMethods.OpenProcess(                                                   NativeMethods.PROCESS_VM_OPERATION                                                   | NativeMethods.PROCESS_VM_READ                                                   | NativeMethods.PROCESS_VM_WRITE,                                                  false, _Window.ProcessId);        // allocate memory from target proces's memory block        // 12 bytes : 4 modified msg + 4 wParam + 4 lParam        IntPtr memAddress = NativeMethods.VirtualAllocEx(hProcess, IntPtr.Zero,               12, NativeMethods.MEM_COMMIT,               NativeMethods.PAGE_READWRITE);        if (memAddress == IntPtr.Zero)              return IntPtr.Zero;          int written = 0;        // write our new parameter values to the tarhet process memory        bool hr = NativeMethods.WriteProcessMemory(hProcess, memAddress,                                                    new int[] {(int)modifiedMsg, wParam.ToInt32(),                                                                lParam.ToInt32()},                                                        12, out written);        // close handle        NativeMethods.CloseHandle(hProcess);          if (!hr)              return IntPtr.Zero;        return memAddress; } // In the native dll // new window procedure for the selected window LRESULT CALLBACK OnMessage(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam) {        // prepare message information, for sending it to our ProcessViewer program        HOOK_MSG message;        message.msg = msg;        message.wParam = wParam;        message.lParam = lParam;          // this is for the WM_COPYDATA message,        // WM_COPYDATA transfers data between 2 process by using this structure        COPYDATASTRUCT cdata;        cdata.dwData = 0;        cdata.cbData = sizeof(message);        cdata.lpData = &message;            // send a WM_COPYDATA to our ProcessViewer which will give information about the message        // to our program        LRESULT result = SendMessage(notifyWindow, WM_COPYDATA, (WPARAM)hWnd, (LPARAM)&cdata);        // return values, 1: ignore message, 0 do nothing,        // different from 0 and 1 : memory address of data which contains the changed wParam and lParam        if (result == 1)              return 0;        if (result != 0)        {              // if result is not 0 or 1              // this means we are going to change the wParam and lParam              // which we write new values of these variables to the              // address (result indicates this address) in the hooked program's memory              HOOK_RESULT* hr = (HOOK_RESULT*)result;              msg = hr->msg;              wParam = hr->wParam;              lParam = hr->lParam;        }        // send message to original window procedure        LRESULT ret = CallWindowProc((WNDPROC)originalWindowProcedure, hWnd, msg, wParam, lParam);        // send message to the ProcessViewer application which         // give information about the result of the message        SendMessage(notifyWindow, HM_MESSAGE_RESULT, msg, ret);        return ret; }

This is simply how PV works. Of course we can write this procedure in different ways but as I said above I’m trying to write this example by using .NET.

Anyway it is just a two night’s code and I think it is a good start for Spying windows. Have fun!!!