locked
Strange windows displayed in desktop while running WPF app RRS feed

  • Question

  • I'm not sure for which forum this is best suited.  I have a WPF app (.NET 4) installed on about 60 machines, some Windows 7, some XP SP3.  In the past two weeks, a strange desktop/window behavior has started to occur for various users on both types of machines.  Windows and controls from other applications/processes are starting to show up at random...some in the taskbar only, some on the desktop.  I'm going to list a few specific occurrences below because it is hard to generalize this. 

    • A drop down list control from an opened VB6 app gets stuck somewhere on the screen, although the VB6 app itself is minimized
    • A Delphi app has one of its invisible windows being displayed to the user
    • A "SapiServerReceiver" window is displayed in the taskbar but doesn't do anything; the user didn't launch this intentionally
    • A "CSTA32WinSock" window is displayed in the taskbar but doesn't do anything; the user didn't launch this intentionally although the user is running a telephony integrated application which does use the CSTA32.dll file.

    I list these here because the only users that have received this are the ones who have this WPF app.  Not all have seen the issue, but the number seems to be growing.  However, they have been running fine for months until this started happening in the past two weeks.  When I look at my change log for this app, one change I made around the same time was that I introduced a call to ShowWindowsAsync to bring to the foreground a VB6 app.  My code is below.  Could something like this cause the strange behavior I describe above?  I don't have any other idea why this just started happening.  Are there any tools that might help me understand what is happening?  Thanks.

    Tim

                  try
                  {
                    Process p = Process.GetProcessById(vb6AppId);
    
                    if (ShowWindowAsync(p.Handle, WindowShowStyle.ShowNormal) == false)
                    {
                      LogEvent("ShowWindowAsync returned false", EventLogEntryType.Information);
                    }
                  }
                  catch (Exception ex)
                  {
                    LogEvent(ex);
                  }

     

    Friday, January 21, 2011 1:21 PM

Answers

All replies

  • Hi Tim SF,

    Regarding to this strange behaviour, it is hard to analyze, but I think I can share you some suggestions and they may help you to find the cause:

    • Try to check if the "p.Handle" is the handle of the main window of the "vb6AppId" process, please check it by Spy++. And recommend you to get the handle of the Window by FindWindow API.
    • Please check the Window Styles and the Extended Styles of the target window, and also check the Class Styles (in the Class tab from the properteis dialog of the Spy++)
    • If you can know above code cause this behaviour, please try to comment it and test again. For the code, I think we could hold the current thread some time Thread.Sleep(). Such as:
    try
    {
     Process p = Process.GetProcessById(vb6AppId);
     bool result = ShowWindowAsync(p.Handle, WindowShowStyle.ShowNormal);
     Thread.Sleep(50);
     if (result == false)
     {
      LogEvent("ShowWindowAsync returned false", EventLogEntryType.Information);
     }
    }
    catch (Exception ex)
    {
     LogEvent(ex);
    }
    

     

    • Others, we could use a tool named "UISpy" from Windows SDK, it can help us to check and test the UI controls in the OS including WPF UI.
    • A tool named "Accessible Event Watcher" from SDK too can help us to view rthe events from applications.

    Hope this helps.

    Sincerely,


    Bob Bao [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, January 24, 2011 3:18 AM
  • Anyupdate?
    Bob Bao [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Thursday, January 27, 2011 3:53 AM
  • Bob - thanks for the information you supplied.  I had not yet used Spy++, because we had taken out the call to ShowWindowAsync to see if that would resolve the issue.  However, I just found out today that the problem is still occuring even without the API call.

    The difficult thing is that I have not been able to reproduce this in our test environment.  So I'm not sure how I would go about using Spy++ in a production environment.  I think the reason we probably haven't seen the issue in our test lab is because we don't use all the applications that interface with our WPF app to the degree that a normal user does in production all day long.

    What would I look for when checking the Windows Styles and Extended Styles?  Is there something of concern there?

    Also - the app is not currenlty using FindWindow() to get the handle of the VB6 app because I already had the handle...the VB6 app contains a .NET Interop control, which communicates with my WPF app using WCF (netNamedPipe binding).  When the VB6 app first "regsiters" itself with the WPF app via WCF, the WPF app stores the handle.  I'm assuming I'd be getting the right handle...but maybe that is a wrong assumption???  Anyway, I doubt that is the issue because I've already commented out the code with no success.

    One other thing:  I've looked for other code that I included in the latest release for this WPF app.  The only other thing that seems of any consequence a call to DragMove() in the LeftMouseButtonDown event handler for a TextBlock control so that the user can drag this WPF app around the screen as needed (the app is borderless).  I'm going to try taking that out as well but I would doubt that could cause this issue.  Thoughts?

    Thursday, January 27, 2011 9:43 PM
  • Hi Tim,

    Do you install the .Net framework 3.0 or 3.5 (SP1) in yout test environment? What is the system version and the hardware information of the environment? I guess that you have tried the steps described in the Guidelines for troubleshooting graphic issues in WPF applications article... And you could try to set the settings for the graphics rendering: http://msdn.microsoft.com/en-us/library/aa970912.aspx try to switch the software rendering and harware rendering.

    Regarding to the Windows Styles and Extended Styles, we could refer to the following two tables, and check the meaning of the values: http://msdn.microsoft.com/en-us/library/ff700542(VS.85).aspx

    Sincerely,


    Bob Bao [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Marked as answer by Tim SF Wednesday, February 2, 2011 1:53 AM
    Friday, January 28, 2011 5:56 AM
  • Hi,

    Additional:

    • Is installing the WPF application the only change that was made to the system during last two weeks?
    • Is this only happening when the WPF application is running?
    • What if just uninstall the WPF application? Will the same thing continue to happen?

    Sincerely,


    Bob Bao [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, January 28, 2011 10:32 AM
  • Bob - it appears so far that setting the RenderMode to SoftwareOnly in the code has stopped the strange behavior from happening.  The change was only in for half of today, so I'll need to verify that it continues tomorrow.

    However, my question now is:  Does that mean I'm doing something wrong in my code that forced me to use SoftwareOnly rendering?  Or does that just point to a lack of adequate display drivers/hardware?

    The other unusual thing is that this application has been running since October of last year.  Only three weeks ago did it start to have this problem.  And at that time the only update I did was to use a Win32 API call as well as add the ability to move the borderless window (via DragMove()).  I'm not sure what would have triggered this behavior to just start happening.

    Anyway - I appreciate you pointing me to the WPF Guidelines document.

    Wednesday, February 2, 2011 1:53 AM