vb.net application freezes with TeamViewer

Question

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.

1. All loops in the application do end but are called very often. Each timer has a 1.5 - 5 second repeat and there are times that the process within the timer takes more than the tick time. The timers all call to a Background Worker and check for .isBusy before starting the process to avoid overlap.

The timers are intended to run endlessly but this is different than an infinite loop.

2. 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.

3. 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.

4. 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.

5. 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.

Answer 1

Hans Passant - As we sometimes say in America "Dude, you're awsome!" it's too bad people weren't appreciating what you provided, but that link, although complex for the average VB.NET programmer (I'm in that category), is a life-saver.
My solution turned out to be a little different from what solved the OP's problem. I was having the exact same problem described by the OP, however switching my invokes to begininvoke wasn't all I needed to do. Based on your link it became clear I needed to make sure I started the form I had put onto another thread using ApartmentSateSTA. I was not explicitly setting that and was putting the form directly on the threadpool using

System.Threading.ThreadPool.QueueUserWorkItem(AddressOf RunProgressForm)

This appears to just use an MTA thread from the threadpool. Switching to creating an explicit threading.thread and then using

ProgBoxTHD = New Threading.Thread(AddressOf RunForm)
ProgBoxTHD.IsBackground = True
ProgBoxTHD.SetApartmentState(Threading.ApartmentState.STA)
ProgBoxTHD.Priority = Threading.ThreadPriority.Normal
ProgBoxTHD.Start()

This allowed the continued pumping of windows messages after TeamViewer changes the desktop settings (which is when my applicaiton would lock up). It also turned out to be necessary to set .IsBackground to True, otherwise the form would hang on exit waiting for something. I know I should investigate that, but setting IsBackgrounds allowed the thread to exit without waiting for anything else to stop - and at the point I'm exiting I really don't care.

FYI - the folks at TeamViewer were of absolutely no help. After having me uninstall/reinstall, turning off DirectX - they were unable to provide any further assistance. Sadly I use several screen sharing solutions and only TeamViewer was locking up my program. While the solution was indeed to fix MY program I do think TeamViewer should take a look at how they are changing the desktop settings when they connect. I spent nearly two weeks on this one bug alone! I use TeamViewer to provide support for my customers and the problem occured when TeamViewer connected or disconnected. Whenever I provided support I wound up leaving the customer with a locked-up program! That just made me look bad!

Answer 2

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.

I found this post to help with the issue