pgordemer

I can also confirm this is not fixed with 2026.3.16.0

Hi @pgordemer

I just fixed the F10 focus bug. It will be available in the next version.

Best regards

Conformed....

Hello,

Could you try the latest (2019.1.17) and verify if it makes a difference?

Regards

Screen performance is good - that seemed to be fixed in .16. The loss of focus when press F10 or F keys is still there.

@pgordemer

The changes did not make it in the 2019.1.14 version. It will be available in the .15 version, in 1 week more or less.

Regards

2019.1.15.0 64 bit has restored most of the speed, full screen refreshes are almost as fast as before. One still lingering issue is if an application with uses full screen display (Using MC in Linux), puts up a popup box to select and response (In this case F10 to Exit pops up a Yes / No box that can be tabbed) - pressing enter or tab is ignored for at least 8 seconds. Wait it out, then can tab back and force as much as you want.

We can do a remote session if you want to see it in action.

OK, I have figured out the problem with F10 / Fkeys in general the hangup and it is reproducible. Just try this, jump in to Linux SSH session, enter a command at the command line, something like top or ls -al. Then press the F10 key. At the point if you try to press enter to anything, it looks like its hung. What has happened is it has lost focus (although the session doesn't show that), Click your mouse back in the screen and push enter and you are back.

@pgordemer

The changes did not make it in the 2019.1.14 version. It will be available in the .15 version, in 1 week more or less.

Regards

2019.1.15.0 64 bit has restored most of the speed, full screen refreshes are almost as fast as before. One still lingering issue is if an application with uses full screen display (Using MC in Linux), puts up a popup box to select and response (In this case F10 to Exit pops up a Yes / No box that can be tabbed) - pressing enter or tab is ignored for at least 8 seconds. Wait it out, then can tab back and force as much as you want.

We can do a remote session if you want to see it in action.

Thanks @pgordemer for the infos. I have made improvements to the graphic rendering of the terminal. Although it was totally usable here, I still was able to measure significant speed improvement, so I hope it will fix this problem for you. Right now I am fixing other minor bugs, but all these fixes should be available in the next beta version.

Regards

Not sure if it made it into 2019.1.14.0 64bit - but I am not noticing an improvement.

Hi @pgordemer and @systemadministration

I am working on the performance problem, just to weed out some potential problems: do you use syntax highlighting? If yes, how many keywords and do you use regex?

Thanks for your time.

Added what I have tested.

1. Tried on 3 different computers all running Windows 10 64 bit, SSH very slow and mostly unusable.

2. Putty in RDM sessions work correctly.

3. Tried my existing entries and created new entry with default SSH and no setting/session changes other than adding up, login name and password.

2019.1.13.0

2019.1.12.0

Not sure at what point it started, but I have loaded every beta as it came down, some I am thinking it started around 2019.1.10? and I probably didn't notice since SSH us only used a few times a week.

I do not use syntax highlighting.

Hi @pgordemer

For the Rebex double characters, just turn off the "local echo" check box in the "terminal" tab.

For the 1 second delay on key strokes, I would like it if you could send me the logs (with verbose enabled) of the connection to the server. "Advanced" tab, check "verbose", check "enable logging", "log mode" set to "event".

I also have a few questions:

If you write a command that generates lots of output, does this output appear slowly?

What is the value of the "Max scrollback lines" field in the "terminal" tab, "general" sub-tab?

I never experienced performance problems in our test environments, so it will be hard to figure out what is going wrong. But I will do my best.

Regards

Max scroll back was 2000, have been that way as long as I can remember. Just set it to 200 and tried it again. Still no go.

In this example I am using SSH to a Centos 7 server in terminal mode. If I run something like top, it has to paint down the lines, will take almost 3 seconds to fill the screen, usually it is instant. When it refreshes in 2 seconds, it has to redraw the page again. Single letter commands like ENTER, need to be pressed 3 or 4 times in order to take.

Here is a quick log, I just logged in, did a TOP, HTOP and MC, logout

[4/8/2019 2:29:33 PM] Setting up connection

[4/8/2019 2:29:33 PM] Connecting as root

[4/8/2019 2:29:33 PM] SSH banner: SSH-2.0-OpenSSH_7.4

[4/8/2019 2:29:33 PM] Sending kex init

[4/8/2019 2:29:33 PM] Received kex init

[4/8/2019 2:29:33 PM] Selected algorithms: curve25519-sha256, ssh-ed25519, chacha20-poly1305@openssh.com, chacha20-poly1305@openssh.com, implicit by cipher, implicit by cipher, none, none

[4/8/2019 2:29:33 PM] Sending Ed25519 kex init

[4/8/2019 2:29:33 PM] Received Ed25519 kex reply

[4/8/2019 2:29:33 PM] Successfully authentified server

[4/8/2019 2:29:33 PM] Sending new keys message

[4/8/2019 2:29:33 PM] Sending userauth service request

[4/8/2019 2:29:33 PM] Received new keys message

[4/8/2019 2:29:33 PM] Received service accepted message

[4/8/2019 2:29:33 PM] Sending userauth init request

[4/8/2019 2:29:33 PM] Received userauth failure: publickey,gssapi-keyex,gssapi-with-mic,password

[4/8/2019 2:29:33 PM] Starting password authentication

[4/8/2019 2:29:33 PM] Sending userauth password request

[4/8/2019 2:29:33 PM] Received userauth success

[4/8/2019 2:29:33 PM] User authenticated successfuly by password

[4/8/2019 2:29:33 PM] Sending session channel open request: 0/-

[4/8/2019 2:29:33 PM] Received global request: hostkeys-00@openssh.com , no need to reply

[4/8/2019 2:29:33 PM] Received channel open confirmation: 0/0 WS 200000/0 MPS 32000/32768

[4/8/2019 2:29:33 PM] Sending pty request: 0/0 xterm

[4/8/2019 2:29:33 PM] Received channel success: 0/0

[4/8/2019 2:29:33 PM] Sending environment variable request: 0/0

[4/8/2019 2:29:33 PM] Received channel success: 0/0

[4/8/2019 2:29:33 PM] Sending shell request: 0/0

[4/8/2019 2:29:33 PM] Received channel success: 0/0

[4/8/2019 2:30:14 PM] Received channel exit status: 0

[4/8/2019 2:30:14 PM] Sending channel close request: 0/0

[4/8/2019 2:30:14 PM] Received channel EOF: 0/0

[4/8/2019 2:30:14 PM] Received channel close request: 0/0

[4/8/2019 2:30:14 PM] Channel is closed: 0/0

[4/8/2019 2:30:14 PM] Disconnecting

Hi,

i have many issues with all 2019.1 Beta Versions:

- SSH is very slow every Keystroke have 1 second delay ( can only use putty as SSH Session without issues).

Using 2019.1.13.0 64bit seeing same. SSH very very very slow. full screen repaints can take a long time, tabbing between boxes unusable.

Putty sessions work fine.

Rebex gives double characters.

I confirm the above workaround does allow CHROME to work Embedded. Tested in Windows 10 1809 and Windows 10 1803

Minor progress - updating to WIndows 10 1809, the Bad_module_info error does NOT display, but the session will hang.

So the issue is definitely in the 3rd party chrome module (at least at 64 bit).

Doing some research online sees to point to this issues as specific to Windows 1709 and some graphics drivers. I am going to do an in place upgrade to Windows 10 1809 right now. Let you know in a few hours if that helped.

No luck, and the strange part is if you click away the error message twice, it comes up in the embedded window.

Faulting application name: bad_module_info, version: 0.0.0.0, time stamp: 0x00000000

Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000

Exception code: 0xc0000005

Fault offset: 0x778818be

Faulting process id: 0x4d4

Faulting application start time: 0x01d45a6ab01f2c68

Faulting application path: bad_module_info

Faulting module path: unknown

Report Id: 8aba8587-9873-401e-a1b0-c083d6d71c5b

Faulting package full name:

Faulting package-relative application ID:

32 bit works perfectly.

The application logs only show when I change it from Chrome to IE embedded, no other errors. Yes, I tried my laptop and I get the same thing.

No I have almost identical applications on both the desktop and laptop, so I need to find a way to figure out what the conflict is.

Bringing this back up again, running 13.9.7.0 64 bit.

Using a clean/new data source, if I configure a simple Web Session embedded with IE or Firefox, I have no problems. If I chance the embedded session to Chrome, I get the bad_module_info twice, click past them and it opens in the embedded session.

Change nothing and open the RDP 32 bit version, no error at all with Chrome embedded.

I am out of ideas. Uninstalled, cleared registry, clear all APPDATA locations, fresh install. There is a conflict somewhere, but I don't know where to find it.

No error in the 32 bit version. I tried the EXACT same data file on another machine and there was no error on the 64 bit version on that one, so looks like it is something specific to this machine.

I just tried an uninstall/reinstall of 13.08, still broken on 64 bit. Will experiment a bit more. Since it works on another computer, I think it is safe to assume its not a problem with the data file.

That is from the 64 bit version (in the title)

Chrome

On all my entries that are using http/https embedded I am getting an "bad_module_info error". If I close the error it continues on.

So looking way down the road, the SSH shell will probably be the most stable. Is that the same for FTP vs FTP Rebex?

Being a long user of RDM since the beginning and watching it evolve..... based on Version 13.xxx what is the difference between SSH and SSH Rebex and which one will be around for the long term.

Thanks