4

So this is a weird one.

I created a WPF application using MahApps for the GUI. So far my testing indicates that the app works fine on several different machines. Of course this is not the case on the client's machine.

The client makes use of Terminal Services and Windows Server 2008R2. Several users can be logged into their own version of the server at anytime. The app starts up fine once or twice, but after a day or so, it no longer opens up.

The app doesn't show up in the Application tab of Task Manager, but its process can be seen to be running in Processes Tab of Task Manager.

To be honest, I'm completely stumped. I had a look at the event manager log and couldn't find anything indicative of a problem. (Of course I might have missed something). I saw another SO question suggesting to disable hardware acceleration, but I'm not if that would help.

Any and all ideas would be greatly appreciated.

EDIT: I thought I might mention the only thing that helps is if we restart the client machine.

EDIT: I think I have isolated the issue to integration with Twain (should probably have mentioned that as another possible factor). I think the Twain library (unmanaged code) somehow stalls without sending back an error. Disabling it has "fixed" the issue.

This somehow relates to Twain and multi-session setups. I'm almost sure of it.

Richard
  • 329
  • 2
  • 13
  • Did you check whether the application shuts down correctly when the user closes it, i.e. does the above mentioned process remain there after the application is seemingly closed? Or does the process really only show up there when the application attempts to start? The reason for the application not working could be the Terminal Services. Unlike on other machines, here multiple users will run your application at the same time and might not log off for a much longer period of time than on client machines. – Damir Arh Oct 14 '16 at 06:17
  • Unable to verify the process is killed after the users closes it. But if I kill the process manually, the same thing happens over and over. To my understanding (which is limited in the case of Terminal Services), running several copies of my app shouldn't be problem? – Richard Oct 14 '16 at 06:22

1 Answers1

1

First you can analyze the wait chain in Windows Resource Monitor to check if there are any resources the process is waiting for. (You can find more information about the wait chain here or here.)

If you don't find any viable suspects there, you can create a memory dump of the hanging process and analyze the call stacks. If you don't know how to create one, you can read about it here. If you want to use Windows Task Manager and your OS is 64-bit then please be aware that you need to use the same bitness of Task Manager as the application.

That is: If your application is 64-bit then you have to use C:\Windows\System32\taskmgr.exe and if it's 32-bit you have to use C:\Windows\SysWOW64\taskmgr.exe. If you forget this important step you'll just get an unusable dump full of gibberish.

After you got the memory dump you can either load it into WinDbg (using the same bitness as the application) or Visual Studio (best to use 2015 or later) and analyze the call stacks of all running threads.

You can download WinDbg here and read about the necessary WinDbg configuration here. For the list of all threads you need to use this SOS command.

If you need help in loading memory dumps into Visual Studio you can find more information here.

After you've looked at the call stacks you most definitely find the answer what is waiting on what resources and is thus preventing the shutdown or startup of the application. It can either be a classic deadlock or an external resource like writing/reading of a file or some other waiting without a timeout like accessing a database or an URL that can't be reached at the moment. And of course it can also be just an infinite loop - if it doesn't consume much CPU then perhaps with some kind of DoEvents in between.

And last but very not least: If you are really interested what can be analyzed if an application hangs you can read about an example analysis done by the absolutely awesome great Mark Russinovich here.

Community
  • 1
  • 1
haindl
  • 3,111
  • 2
  • 25
  • 31
  • This is an incredible useful response. Thank you so much. I'll mark as accepted answer once I tracked down the error. – Richard Oct 14 '16 at 09:34
  • @Richard You are very welcome. :-) If I can help you any further (or at least I can try to help you), just leave a comment. – haindl Oct 14 '16 at 09:37
  • Just to give some feedback, the analyze process showed nothing out of the ordinary. I'm struggling to get the dump working, but suspect this will help once I get it working. – Richard Oct 14 '16 at 13:03
  • @Richard Thanks for the feedback. Inspecting the call stacks will most likely help to pinpoint the exact cause of the hang. I've just read your edit and can say that an unmanaged Twain library surely is such a candidate for the hang. If that is really the case then you will definitely see that in the call stack. Don't give up getting the dump - especially if it still occurs after disabling the Twain integration. It will pay off in the end. – haindl Oct 14 '16 at 13:21
  • The comment pointed me in at least tracking down the problem and is generally a very useful tool. I now believe the twain32.dll should be replaced by the newer twaindsm.dll Still no definitive conclusion. Also, I worked around this issue by killing the thread in which I request the twain resources if it doesn't get a response after x amount of time. That at least "solves" the no start issue and the app can now open. – Richard Oct 24 '16 at 15:01
  • @Richard Glad I could help you a little bit. Sometimes killing a thread is a viable solution. If you use `Thread.Abort()` be aware that it has some pitfalls. Look [here](http://stackoverflow.com/questions/1559255/whats-wrong-with-using-thread-abort/) for an explanation. It could also cause a memory leak. But if it's necessary only once in the whole lifetime of the process then I guess it should be kind of ok if you don't experience other side effects. (At least it's far better than an application hang.) – haindl Oct 24 '16 at 15:30