Been out of the office, sorry for the delays with this.
I have been running the debug version for the last week and guess what - not crashes at all. The only thing that has been changed on my computer is that the latest patches from Microsoft have been installed. The FortiGate client is the same etc, etc...
I will continue to run this debug version a couple of days and then we'll see. Could it be something that is enough different in this version that prevents these crashes from happening?
It's not unusual for errors such as this to be hard to track down. It wouldn't be the first time I saw something fail in release and not in Debug. However, it could be that the issue is resolved in 3.85, but was still a problem in the version you were running (3.80). To verify that, run the release version of 3.85 here:
Yes, I know it's the same link. I've replaced the file.
Brian
Being a programmer myself, I know the pain with bugs like this - add some debugging code (slowing down the program, mitigating timing issues etc.) and everything is running just fine...
I have installed this release and will see what happens.
Will keep you posted,
/msa
Hmmm... been running the Beta-release (non-debug) over the weekend and there have been several crashes while closing the connection... The debug-builds must have some serious magic in them... 😉
Back to square #1...
/msa
Mattias, I went ahead and finalized the new 3.85 version. I was wondering if you could verify that your problem still exists there. Nobody else has reported this.
My first priority, now, is to track this issue down for you. I'm going to have to create a special build that has enough debug to be useful but not so much that the problem goes away. This is my challenge. I'll let you know when I have something ready to look at. Probably tonight. Brian
Mattias, I have something for you to try:
This is basically a release build that contains all of the debug output so I can begin to pinpoint where the crash is occuring. The version number should show 3.86 when it is running. The logfile will be built in c:\\logfilew.doc Create a crash, then mail the logfile to me. Brian
Sad but true...
Installed 3.86 a couple of days ago, but still no crash... The debug-stuff is clearly doing its magic...
Still no crashes with the 3.86 beta. The logfile is growing but the application is behaving as expected.... grr...
/msa
I'm not ignoring you. I'm just not sure where to go from here. I'll probably try another version with less debug in it.
However, because the debug versions WORK and the release DOESN'T, it's very difficult to determine the error. The trick is to get enough debug to be useful without making the problem go away completely. These kinds of shifty bugs are always a pain in the (neck) to find.
Brian
One other question... Can you tell me exactly how you close the app and how the crash occurs?
Do you use the disconnect button on the toolbar?
Does the app crash the instant you hit the button?
Is the AbsoluteTelnet window still visible when the crash occurs or has it gone away already?
Brian
Not to worry, I don't think you ignore me. I understand that this error is hard to find and that it only affects one single user. I know you are working hard on AT and you give great support and listen to your users when it comes to feature reqs etc. AT is configured to: Close application on disconnect = NO Clear screen on disconnect = NO Allow close while connected = YES Connect on Open = YES Save On Exit = NO ... default ... = PROMPT Autodetect ANSI = NO Autodetect UTF-8 = PROMPT Open Log in 'cooked' mode = NO Overwrite file... = PROMPT I normally just hit CTRL-D to close the connection and then close the application window. When things go bad, the crash occurs right after CTRL-D was pressed and the screen is cleared (Linux sends a clear-screen when logging out). Just now I have noticed that there are some issues with this, please see the great motion picture 🙂 on
<broken link removed>
where the top lines of the terminal window is still there. Could it be some race-condition in the code tearing down the SSH-connection and other parts of AT? Just my thoughts - I can live with some crashes (it has never, never crashed while connected!!). Cheers, /msa
Ok, that give me some good info and direction.
Originally, I was thinking that the application might be closing and causing an error on the way down. It certainly appears that it might be related to the 'tearing down' of the SSH connection in a way that your system doesn't like. A couple of questions...
First, regarding the reproducability of the error. Originally, you said it seems to happen more with connections that have been open for a long time and then closed. I'm curious if it might be possible that the real distinction is related to the amount of data pumped through and longer running connections have simply been more active. In other words, if you leave a copy running but doing no work, is it less likely to fail? Also, if you have a short-run that is very active, is it more likely to fail? It's also possible that it might be a combination of both a long-running app with lots of activity that makes it more likely to fail. Your observations?
Second, I see you're using SSH2. Can you try SSH1 for awhile? Make sure you go back to the non-debug version 3.85 to try this.
Third, Can you try version 3.85 on a machine that does not have the FortiGate client. If the bug doesn't happen on non-fortigate machines, I'll stop trying to reproduce it and attack it another way.
Fourth, Can you try version 2.13 for awhile on the FortiGate PC. It would help to know if this is something that crept into Absolute during some prior revision or something that crept into FortiGate or Windows.
Thanks for sticking with me. We'll get this figured out eventually. I hope the crashes are not affecting you too badly.
Brian
Oh,
And as for the 'clear screen' issue. I watched the video. A few of the lines had actually scrolled off the top of the screen before you disconnected. The 'clear screen' function only affects what is on the visible screen. That's why you had to scroll up to see them.
I liked the video, though. That's a great way to communicate the problem across the internet. From the video, I can tell exactly which version and RC you are using. I can see what size screen and what type connection and exactly what happens on the screen. Not everyone is great and describing their problem in words! 😉
I've been considering some other technologies for stuff like this, including 'webex' for remote desktop sharing to help diagnose problems. Have you ever tried that?
Brian
Some of our external suppliers are using webex to help troubleshoot problems we run into and we have evaluated it ourself for internal use and communication with our customers. Webex is working great over Internet and the compatibility is fantastic, you only need a web-browser. The drawback we saw was the costs of a subscription for webex. You can buy it on a one-by-one basis but then there are some hassels for you and your remote party to set up the connection. Having a subscription allows you to have a link celestial.webex.com and direct all customers there and handle support. Webex allows you to grab control over the client's desktop and fix problems.
In-house we are using Remote Administrator from famatech.com. It works great and enables us (I am working at IT-Support) to see what the use is doing. Remote Administrator is not firewall-friendly and is thus not possible to use with remote clients.
If you see the need of troubleshooting remote clients and do it often, I would try to see if it is possible to get a webex account to an affordable price.
I will install 3.85 and see what happens.
Sincerely,
/msa
I managed to catch the crash (I was doing an instruction video for my staff). It is available on
<broken link removed>
