locked
.NET applications hangs on remote desktop RRS feed

  • Question

  • I have a problem with a large application that consists of windows forms mainly, but some WPF windows and controls (we also use DevExpress controls v9.1). The problem is that the application sometimes hangs when it runs in a remote desktop session, and that session gets locked due to inactivity, and the user comes back and unlocks the session. The hang seems very similar to the hangs you get when accessing GUI controls from a none GUI thread, but I'm pretty sure that's not what causes the problem. (We had a lot of those problems earlier, and have fixed all multithreading problems we were able to find. And the hangs now never occures when the application runs outside the remote desktop environment.)

    I've done a lot of research on the problem but I've still not found a clear point to what causes the problem. However, I think there might be a problem related to some combination of remote desktop and .NET framework. The reason for this is posts like this: http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/2003_Server/Q_23247725.html. (I've not read the solution to this post, since I don't have an Experts Exchange account.)

    The problem occures on both Windows Server 2003 R2 and Windows Server 2008. But I've not been able to reproduce it all times I've tried to, so it seems to happen occationally. On the same server, I was able to reproduce the problem several times in a two day period, but some days later, I was not able to reproduce it at all. So it seems that when it happens, it happens constantly, but overall the problem happens occationally.

    The application has a WPF splashscreen that runs several startup tasks in a background thread, and the hang can occure right after the program has started. The hangs are logged in the Windows Event Log, and here is a copy of the details of such an error:
    Description
    A problem caused this program to stop interacting with Windows.

    Problem signature
    Problem Event Name:    AppHangB1
    Application Name:    Clinic.exe
    Application Version:    4.1.10012.0
    Application Timestamp:    4a238f0b
    Hang Signature:    78f2
    Hang Type:    6400
    OS Version:    6.0.6002.2.2.0.16.7
    Locale ID:    1044
    Additional Hang Signature 1:    f69886975b54af017702dbaf656d3568
    Additional Hang Signature 2:    8440
    Additional Hang Signature 3:    0c64b3c48813eca03a4752de631654dc
    Additional Hang Signature 4:    78f2
    Additional Hang Signature 5:    f69886975b54af017702dbaf656d3568
    Additional Hang Signature 6:    8440
    Additional Hang Signature 7:    0c64b3c48813eca03a4752de631654d


    I'm hoping for some experts on the topic to read this and point me in the right direction to find what causes the problem.
    eloekset
    Thursday, August 13, 2009 11:14 AM

Answers

  • I've checked the Windows Update log, and they seem to have installed the latest updates.

    As far as I know by now, I think the problem is solved. We have been able to fool ourselves with code that happens to run on a server where many users log in on a shared desktop. It has nothing to do with remote desktop, but the problem is very unlikely to occure in a single user environment.

    The application stores currently logged-in users in a database table, based on computer name. When the application starts, it checks for currently logged-in users based on computer name, and eventually logs out any logged-in user. That startup task involved a windows form (it instantiated UserLogOutForm without ever calling it's Show() method), and that happened in a background thread. This means that an action which happens very rarely - and almost never in environments where remote desktop isn't involved - might cause application hang if the remote desktop session times out (or the user choose lock screen, or screen saver shows up, or user changes desktop background etc).

    So one lesson was relearned from this: If you have a bug, check your own code, even if you are 100% sure there isn't a bug in it. :)

    So I'm sorry to have bothered you with this, and thanks for your help. I'll mark your first answer as the answer.
    eloekset
    Tuesday, August 18, 2009 1:55 PM
  • Just for testing,
    would you remove your splash screen and rely on the loading event of your start up form for initialization step you do on the splash screen?

    This might narrow the problem in either Splash screen disposal or Start up initialization of your form

    Waiting for your test.

    Have a lovely day.

    Waleed El-Badry Teaching Assistant Faculty of Engineering Misr University for Science & Technology
    Thursday, August 13, 2009 11:45 AM

All replies

  • Just for testing,
    would you remove your splash screen and rely on the loading event of your start up form for initialization step you do on the splash screen?

    This might narrow the problem in either Splash screen disposal or Start up initialization of your form

    Waiting for your test.

    Have a lovely day.

    Waleed El-Badry Teaching Assistant Faculty of Engineering Misr University for Science & Technology
    Thursday, August 13, 2009 11:45 AM
  • Regarding the expert exchange thread you posted, the solution was this:

    "We called microsoft the last day and told us that we may want to revisit the threading implementation and we did. Couple of changes in InterOp services fixed the problem. Particularly to SafeWaitHandle."
    Thursday, August 13, 2009 12:07 PM
  • Just for testing,
    would you remove your splash screen and rely on the loading event of your start up form for initialization step you do on the splash screen?

    This might narrow the problem in either Splash screen disposal or Start up initialization of your form


    Thanks for your answer!

    That's what I tried to do serveral times. But I've not yet been able to reproduce the hang on any other machine than the customer's machine. So on friday I decided to try multiple versions of the program on the customer's machine, where each version is stripped more and more to narrow down the problem.

    On friday I manged to reproduce the hang, but I didn't get time to upload a version without the splash screen that day. Today, I have prepared a version without the splash screen, but now I'm not able to reproduce the hang on either version.

    So I'm wondering. How come this hang is so difficult to reproduce. Earlier when we had several crossthread issues on GUI components, we were able to reproduce the hang on (at least almost) all computers and (at least almost) all times we tried. This hang problem however, seems to be different, since we are not able to reproduce it at all, without using remote desktop, and even then we have serious difficulties in reproducing it. I've tried more than 10 times today on the customer's machine, running the exact same program that hangs pretty often. On friday I tried a few times, and were able to reproduce the hang every singe time I tried.

    I think it's a bit strange that the hang is happening so very occationally, compared to the hangs we struggled earlier. Are there some other potential reasons for GUI hang problem other than crossthread access to GUI controls?

    BTW, I've created a shortcut on the desktop to be able to lock the screen when using remote desktop. The shortcut executes the following "rundll32 user32.dll,LockWorkStation". This is a great tip I found from this article: http://www.bridgetonova.com/2007/10/how-to-lock-computer-in-remote-desktop.html

    eloekset
    Monday, August 17, 2009 8:15 AM
  • Regarding the expert exchange thread you posted, the solution was this:

    "We called microsoft the last day and told us that we may want to revisit the threading implementation and we did. Couple of changes in InterOp services fixed the problem. Particularly to SafeWaitHandle."

    Thanks for this! Actually I've been suspecting some InterOp calls to be causing the hang. We have implemented a login/logout routine for smart cards, that uses InterOp calls to some ActiveX library that we got from the smart card adapter provider. Without knowing what happens inside the ActiveX control, I think there must be some threading involved, because the program starts to listen for a smart card to be inserted as soon as the main form gets initialized.

    But then again, how come the hangs happen only when using remote desktop? And the only two machines, on which I've been able to reproduce the hang, are running Windows Server 2003 R2 or Windows Server 2008. I think there must be some complex combination of software (and maybe even hardware) to be able to get these hangs, although I might be wrong.

    eloekset
    Monday, August 17, 2009 8:28 AM
  • Just for testing,
    would you remove your splash screen and rely on the loading event of your start up form for initialization step you do on the splash screen?

    This might narrow the problem in either Splash screen disposal or Start up initialization of your form

    Just an update of what is achieved so far. I've been able to reproduce the hang in 4 of 225 tests. I did 75 tests of three versions of the program. Two versions with splash screen did hang 2 of 75 times, and one version without the splash screen did never hang. So I guess there is a relatively high probability that the splash screen is at least one reason for the hangs.

    I'll now go through the splash screen code once more and look for access of GUI controls in the tasks running in a background thread. I'm surprised to see how few of the tests that lead to hang, compared to the tests done earlier when we first got aware of the "main GUI thread nightmare". Now there is only 2,7% chance for hang, compared to about 100% chance that time.

    eloekset
    Monday, August 17, 2009 2:51 PM
  • I hope ivind  that it is not a problem caused by lack of maintenance to Windows OS by your client. It is so strange that your code can run on many different clients without problem except this one. Please check his service pack updates for instance.

    Waleed El-Badry,Teaching Assistant, Faculty of Engineering , Misr University for Science & Technology
    Monday, August 17, 2009 5:40 PM
  • I've checked the Windows Update log, and they seem to have installed the latest updates.

    As far as I know by now, I think the problem is solved. We have been able to fool ourselves with code that happens to run on a server where many users log in on a shared desktop. It has nothing to do with remote desktop, but the problem is very unlikely to occure in a single user environment.

    The application stores currently logged-in users in a database table, based on computer name. When the application starts, it checks for currently logged-in users based on computer name, and eventually logs out any logged-in user. That startup task involved a windows form (it instantiated UserLogOutForm without ever calling it's Show() method), and that happened in a background thread. This means that an action which happens very rarely - and almost never in environments where remote desktop isn't involved - might cause application hang if the remote desktop session times out (or the user choose lock screen, or screen saver shows up, or user changes desktop background etc).

    So one lesson was relearned from this: If you have a bug, check your own code, even if you are 100% sure there isn't a bug in it. :)

    So I'm sorry to have bothered you with this, and thanks for your help. I'll mark your first answer as the answer.
    eloekset
    Tuesday, August 18, 2009 1:55 PM
  • you are always welcome to post your questions. I should be the one to thank you for sharing your experience in debugging your problem.

     please accept my respect and best regards.

    Waleed El-Badry ,Teaching Assistant, Faculty of Engineering , Misr University for Science & Technology
    Tuesday, August 18, 2009 8:55 PM
  • Thank you Waleed for your friendly help and support.

    Hi Eivind,

    I’m glad to hear that you figured it out. Cheers!
    Thank you for sharing your experience in debugging your problem.
    It will be very beneficial
    for other community members having the similar questions.



    Best regards,
    Martin Xie


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback on our support, please contact msdnmg@microsoft.com
    Thursday, August 20, 2009 2:01 AM