SSHClient causes a crash when connecting to an invalid server

My company just upgraded the UltimateTerminal component from version 6.3.60124 to 6.8.4155 and I have discovered a major issue. When using the SSHClient, if you try to connect to a server that either does not exist or does not support SSH, my program now crashes and shuts down. In the old version, an exception was raised that indicated either a timeout or that the target machine actively refused it, which I could simply catch and handle. But the new version just bombs out with no warning. I have seen the same problem with your pre-compiled samples (specifically the SshClient.exe sample), so it's not just my code. I am running Windows 10 with version 4.7.1 of the .NET Framework installed (but my program targets version 4.0). I have tried the samples on a Windows 8 machine and have the same issue. As I mentioned, I have seen this in your sample programs, but as a very simple test, here is a piece of sample code I was using to create the problem. Public Class Form1 Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click Try Using m_Client = New SshClient m_Client.Connect("") If (m_Client.IsConnected) Then MsgBox("Connected") Else MsgBox("Not Connected") End If End Using Catch ex As Exception MsgBox(ex.Message) End Try End Sub End Class For the IP Address to connect to, enter an invalid address or an address that does not support SSH. When using the old version, an exception is raised on the Connect call and is shown to the user. But with the current version, the program just shuts down without catching any exceptions. The ConnectAsync method also exhibits the same behavior. You do get a standard Windows "Program has stopped working" message, but that's it. And an error is written to the Windows event log, like so: Faulting application name: SshClient.exe, version:, time stamp: 0x592123ad Faulting module name: unknown, version:, time stamp: 0x00000000 Exception code: 0xc00000fd Fault offset: 0x00007ffd84cbb601 Faulting process id: 0x384 Faulting application start time: 0x01d412dc2a4a183b Faulting application path: D:\Users\dla\Desktop\CompiledSamples\SshClient.exe Faulting module path: unknown Report Id: 4152b46f-498d-4f64-8395-433a381b07d7 Faulting package full name: Faulting package-relative application ID:
asked 7/3/2018 4:58:58 PM
add a comment

1 Answers

We were aware of that issue and have been working on a new version 7.0 that addresses this issue. Regards,
answered 7/5/2018 1:58:28 PM
  s there an expected timeframe for the release of version 7.0? We had to upgrade because we needed the fix for the Diffie-Hellman group exchange issue. But this bug makes the new version we purchased virtually unusable. We will not be able to ship a version of our product that has such a great potential for random crashes. So I'm somewhat stuck at the moment because I can't use either version. David Angell 7/5/2018 2:34:36 PM
  It takes nearly a month. In the meantime, you can test the host+port if it's not valid by using the Socket class as described in this link: We will definitely solve this issue in v7.0. sysadmin 7/7/2018 4:34:40 AM
  Do you know what version the bug was first introduced in? My old version (6.3.60124) did not have the bug. According to your website, it appears the fix for the Diffie-Hellman issue was included in version 6.8.1. If the bug was introduced sometime after this but before my current version of 6.8.4155, then it would be great if I could get a copy of 6.8.1 to hold me over until version 7.0 is ready. But if the bug already existed in 6.8.1, this would be of no benefit. Also, testing the host/port prior to connecting is not really feasible as my program connects to potentially hundreds of server/devices. Having to perform an extra test on each one will likely add unnecessary delays that that would not be acceptable. David Angell 7/16/2018 2:13:58 PM
add a comment

Your Answer

Not the answer you're looking for? Browse other questions tagged ultimate terminal emulation or ask your own question.