10

I'm using a proxy DLL to intercept calls to CreateWindowExA/CreateWindowExW. This works quit nicely, except that some applications (most notably some Visual Basic 6 applications) seem to be able to create windows without going through either of the two functions. Tools like Spy++ are able to show the Window, but my hooked functions didn't notice them.

My first suspicion was that maybe these (old) applications use CreateWindowA/CreateWindowW for creating windows, but at least with my compilers (MSVC6 up to MSVC10), CreateWindow is just a #define; the remarks section of the documentation confirms this.

My second idea was that I could maybe install a CBT hook using SetWindowsHookEx to detect creations of windows. However, the result is the same: this hook notices the same windows as my hooked API functions, but it doesn't notice all the windows which are visible in Spy++.

So my question is: was there maybe a time when CreateWindowA/CreateWindowW was not a #define, but a real function? Is this function still exported by user32.dll, maybe for compatibility reasons? How can I get a handle on this function to hook it?

Or is there maybe some other, possibly undocumented, function which can be used to create functions, much like e.g. NtCreateProcess can be used instead of CreateProcess?

Frerich Raabe
  • 90,689
  • 19
  • 115
  • 207
  • 2
    NtUserCreateWindowEx is called from CreateWindow/CreateWindowEx, but that is, like NtCreateProcess, a kernel function. – Marius Bancila May 19 '11 at 06:17
  • @Marius: Ah, thanks for pointing that out. That might become useful in the future. – Frerich Raabe May 19 '11 at 08:14
  • One thing to explore: what is the timing of you putting your hook in place vs when you think VB6 is creating the window. VB6 will (all on its own) in some cases create a instance of a window to act as a shared global instance within a VB project. Any chance that the window is created already but just not visible when your hook goes in? – dkackman May 19 '11 at 11:59

2 Answers2

7

Three simple guesses:

1) Is it possible that VB apps are really calling a "DialogBox" API (e.g. DialogBoxParam, CreateDialogIndirect, etc...) underneath the hood?

2) You are running a 64-bit OS and are hooking the 64-bit user32.dll. 32-bit apps aren't getting hooked as a result. There's a 32-bit copy of user32.dll in c:\windows\syswow64

3) You aren't hooking the user32.dll that the apps are using. Many older apps may be getting some DLL redirection. From a command prompt, do "dir /s user32.dll" from the c:\windows\winsxs directory. You'll see at least one other copy of user32.dll here. Forget when this happens, but you can Bing for "winsxs" and get some pages discussion how the side by side directory solves compat issues on newer windows OS releases.

I suspect #3 is the reason for your issue.

selbie
  • 100,020
  • 15
  • 103
  • 173
  • 1) It's possible, but I thought it was unlikely since the problematic windows don't have their own frame (they are not dialogs or toplevels). 2) I am running on a 64bit OS indeed, but it seems my user32.dll proxy is used anyway since I do detect other windows in the same process. 3) see 2). – Frerich Raabe May 19 '11 at 08:13
  • Which copy of user32.dll are you hooking? c:\windows\system32\user32.dll , c:\windows\syswow64\user32.dll, or the user32.dll in c:\windows\winsxs ? I suspect one of the other two need to get hooked as well. – selbie May 19 '11 at 08:19
  • I don't hook a particular copy. My own `user32.dll` is in the same directory as the application executable, according to http://msdn.microsoft.com/en-us/library/ms682586(v=vs.85).aspx it should be loaded if available (and it seems to work for most, but not all, cases). – Frerich Raabe May 19 '11 at 10:44
  • Ugh, it turned out that my problem was actually something totally different, but still: your guesses make a lot of sense. I'll accept this answer. – Frerich Raabe May 19 '11 at 15:50
1

I think your issue might be that the VB app is using GetProcAddress() to call the CreateWindow**() function. If you hook GetProcAddress you should be able to confirm this.

paulm
  • 5,629
  • 7
  • 47
  • 70