I have been working on an application and found that when connecting remotely via TeamViewer and Radmin, the application freezes.
When it freezes, there are no exceptions, the ui is unresponsive and the process DOES NOT hang in resource monitor or process explorer.
Some basic specs for the application: Connects to 2 COM ports. One for input, one for output. The output COM also requires a keep alive signal every 5 seconds. There are 4 background worker threads running various tasks from UI updates to speech output as well as handling the data input. The UI displays data in real time from 3 separate data sources. Two are the COM ports, one is MS SQL.
RDP does not hang the application at all.
Any ideas on what may be causing this?
It is running on .NET 4.5.1 built in VS Ultimate 2013 with SQL 2012 backend.
I have tried changing between 64-bit and 32-bit without any progress as well.
EDIT Responses to fsintegral.
The timers are intended to run endlessly but this is different than an infinite loop.
Is there a way to check for invisible dialog boxes? I don't believe any exist but I would like to know how to make sure.
I have spent a good chunk of time optimizing data load times per background worker and gotten each process down to less than a second for data load. There are two things that cause one of the processes to run longer. One of them is speaking an alert using SpeachSynth and can take up to 60 seconds per block of code. The other is e-mail, which I have put into an async process to keep it from hanging the application if there is a timeout. But, the application hangs even when these two items are not being processed.
Cascading events. Would this be events triggered by other events? IF so, the application does not utilize this type of action. The application does however call to about 15 separate modules from at least one of the Background Workers. I don't believe this is too high of a number but let me know if it is. I can post some pseudo code if it this is a concern.
Application.Sleep() is not used but Application.DoEvents() is when waiting for a certain amount of time to pass.
IE
Dim startTime As Date = Now
Dim timePassed As TimeSpan = Now - startTime
Do Until timePassed.TotalSeconds > 5
timePassed = Now - startTime
Application.DoEvents()
Loop
The main reason for the vagueness is that I was hoping this issue was known with TeamViewer or Radmin based on the types of items in the application. IE SQL version, COM ports and BW.
Thank you ahead of time.
Ok. I figured it out.
Basically, the cause of the issue is how these remote viewing applications affect the UI of the .NET application.
Within my application there are two textboxes that are updated from various threads within the app. I was using the following code to update the text. The .Invoke method was the issue.
Delegate Sub SetTextCallback(ByVal [text] As String, ByRef txtHomeActiveDataStream As TextBox, ByVal type As String)
Public Sub ReceivedText(ByVal [text] As String, ByRef txtHomeActiveDataStream As TextBox, ByVal type As String) 'input from ReadExisting
Dim receivedString As String = text
Dim currentText As String
If txtHomeActiveDataStream.InvokeRequired Then
Dim x As New SetTextCallback(AddressOf ReceivedText)
txtHomeActiveDataStream.Invoke(x, New Object() {(text), txtHomeActiveDataStream, type})
Else
txtHomeActiveDataStream.Text &= receivedString
End If
End Sub
By changing the method from .Invoke to .BeginInvoke I was able to keep the application from hanging. This is apparently due to the fact that .Invoke requires postback to the UI before releasing and TeamViewer was grabbing the UI in such a way that the postback was never sent back to the UI. With BeginInvoke the postback is ignored and therefore no longer hangs indefinitely with TeamViewer.
Thank you for the information on the windbg. But I was not able to get it to run per the article you sent over. I did end up using ProcessExplorer and created a dump file to find out what line the code was hanging on. I tried using VS 2013 in debug mode but the application would never hang while running in debug. Go figure.
Thanks for your input guys. I hope this helps someone else in the future. I spent more time than I'm willing to admit on this issue and am glad to be done with it.
If you have any additional comments please let me know.