Завершение работы программы .NET Winform без какой-либо уважительной причины на конечном субстекле

#.net #vb.net #winforms #agsxmpp

#.net #vb.net #winforms #agsxmpp

Вопрос:

Я использую agsXMPP в своем проекте .NET (WinForms) У меня есть следующий блок кода, он выполняется всякий раз, когда сообщение получено от любого клиента. Теперь всякий раз, когда принимается сообщение, этот блок выполняется, и программа завершается.. : ( Я понятия не имею, что происходит. Помогите!

Имеет ли это какое-то отношение к потокам? (Я слышал, что agsXMPP инкапсулирует поток, в котором он работает)

    Private Sub messageReceived(ByVal sender As Object, ByVal msg As protocol.client.Message)
    Dim chatMessage() As String
    Static Dim Hi_ed As Integer = 0
    chatMessage = msg.From.ToString.Split("/")
    Dim chatSender As String = chatMessage(0)

    If Not IsWorking Then
        IsWorking = True
        If Not ProcessCommands(msg.Body, chatSender) Then
            Dim sStr As String = ParseEnglish(msg.Body)

            Select Case sStr
                Case "HI"
                    If Hi_ed = False Then
                        SendGTalkMsg("Hi. How do you do?", chatSender)
                        Hi_ed = True
                    Else
                        SendGTalkMsg("हाय वाई कुछ नहीं हम तो !!!", chatSender)
                    End If
                Case "DETAILS PLEASE"
                    SendGTalkMsg(". Currently there are N no of sams running on me: :)", chatSender)
            End Select
        End If
        IsWorking = False

        Exit Sub
    Else
        SendGTalkMsg("I'm working right now. Please have patience.", chatSender)
    End If
End Sub
  

** РЕДАКТИРОВАТЬ ****
Теперь, когда я запускаю созданный EXE-файл, после завершения этого события появляется ошибка «не отвечает», что явно означает, что есть исключение, но оно избегает блока try catch. 🙁

Это ошибка, которую я получаю:

 Problem signature:
Problem Event Name: CLR20r3
Problem Signature 01:   updatecheck.exe
Problem Signature 02:   1.0.0.0
Problem Signature 03:   4e8ed73e
Problem Signature 04:   mscorlib
Problem Signature 05:   4.0.0.0
Problem Signature 06:   4dd23522
Problem Signature 07:   1526
Problem Signature 08:   4f
Problem Signature 09:   System.InvalidOperationException
OS Version:  6.1.7600.2.0.0.256.1
Locale ID:  1033
Additional Information 1:   0a9e
Additional Information 2:   0a9e372d3b4ad19135b953a78882e789
Additional Information 3:   0a9e
Additional Information 4:   0a9e372d3b4ad19135b953a78882e789

Read our privacy statement online:
http://go.microsoft.com/fwlink/?linkid=104288amp;clcid=0x0409

If the online privacy statement is not available, please read our privacy statement       
offline:
C:Windowssystem32en-USerofflps.txt
  

Ответ №1:

Ну, ну, ну. Все это было из-за глупого диалогового окна для

 My.Computer.Network.DownloadFile(SourceZipFile, DestinationZipFile, "<userid>", "<password>", True, 100000, True)
  

было установлено значение true. Поэтому всякий раз, когда появлялось окно выполнения загрузки файла, оно использовалось для путаницы с потоками. Когда я изменил параметр ShowUI DownloadFile на False, все работало нормально. 🙂

Но есть ли у нас четкое объяснение этому?

Ответ №2:

Скорее всего, это связано с комбинацией потоков и необработанным исключением. Похоже, нет способа контролировать поведение необработанных исключений для любого, кроме основного потока, поэтому крайне важно, чтобы вы обрабатывали все исключения, которые могут возникнуть вне основного потока. Сюда входят асинхронные обратные вызовы, такие как описанные выше, поскольку они часто выполняются вне основного потока. Если исключение остается необработанным в неосновном потоке, приложение просто завершит работу; никакого сообщения.

Я бы рекомендовал обернуть все обратные вызовы и другие асинхронные методы в блок try … catch, который регистрирует ошибку или записывает ее в окно трассировки отладки.

Комментарии:

1. Я попробовал это (поставив try catch на все обратные вызовы.. но все напрасно .. 🙁 )