4
votes

I found a bug yesterday in one of my Windows applications, which is built in a high level framework, which in the end, calls Windows APIs like CreateWindow, and ShowWindow, in order to display its user interface.

One one machine so far, and only one, which happened to be a customer machine, I observed the following behaviour:

  • For only one window in my entire application, when I first call ShowWindow(Handle,SW_SHOW ) for this window, the size which it previously had received by SetWindowPos is overridden.

Reading the MSDN Win32 API documentation, on ShowWindow(Handle,SW_SHOW) I can not see any reference it it moving the window bounds. I can work around this surprising result by having my window-show routine get the bounds before it calls the Win32 ShowWindow routine.

My question is, has anyone ever seen behaviour like this? I think it must be one of the following:

  • An obscure bug in Windows 7 Service Pack 1 that does not reproduce on all systems, and only reproduces perhaps for a particular version of a particular video card driver. (This affected system has dual AMD/ATI FireGL video cards)

  • An obscure problem caused by a side effect of some other software running on the system, which may be hooking window handles, installing trampolined code hooks somewhere (perhaps even inside my own process, thanks to some DLL or something that I am not aware of).

  • Something my 4 million line application is doing to me, through some weird code somewhere I have not yet identified.

  • I am hitting an application compatibility shim within the Win32 API layer.

If anyone who has worked in C++, C, or Delphi, or any other language, has ever seen anything like this and can think of a reason why ShowWindow would have this amazing and unexpected side effect, of moving the bounds of the window, back to a certain original position, in my case, x=175, y=175, width=320, height=240, which appears to be have been the window bounds right after the initial CreateWindow call, I'd like to know what it is.

Here is a sequence of events:

  • Application starts up, and creates a few top level windows parented to the desktop.

  • The first window created is the main application window and the second is a tool window, both have full window grabber bars and are conventional top level Win32 windows, Forms which are sizeable, draggable, and parented to the desktop.

  • The second window's position is loaded from disk, and the form is shown.

  • During the form show process, its bounds are set so that the window is at some x and y top/left position, and some height/width is given.

  • If I query the Win32 window handle immediately before I call ShowWindow, its bounds are where I expect.

  • If I query the Win32 window handle immediately after I call ShowWindow, its bounds have been reset.

According to MSDN help SW_SHOW means Activates the window and displays it in its current size and position.

This is indeed what occurs on over 100 client PCs I have observed. Only on a single customer-owned Windows 7 PC is this behaviour different.

1
Are you able to debug on the machine that fails? Or remote debugger? You might be able to programatically set a data breakpoint on the size parameters and trap where it is changed. I believe this is possible with visual studio.Pete
The other possibility is that this machine has some software on it which has installed a message hook, maybe even malware.Pete
I have thought of the malware possibility too. I am not able to run a remote debugger as it is a client PC only accessible by a LogMe Rescue console, I do not even have a VPN connection. I have spent dozens of hours trying to configure a Windows 7 machine so I can not reproduce this. What I have learned so far is by instrumenting and adding logging to my executables. I can not install any heavyweight IDEs on this system but it is possible I could debug in WinDbgWarren P
I think you need to isolate this into a reproduction.David Heffernan
What happens if you change the class name of that window? if a wide message hook is installed it might be fishing for that class name. just a thought...kobik

1 Answers

5
votes

This affected system has dual AMD/ATI FireGL video cards

I ain't sure about FireGL, but for consumers videocards, made upon the same chip lineage, video-drivers exactly have add-on to reposition windows as they think is easier for operator.

it is called HydraVision Package for Catalyst Software Suite