XP Telnet Window Won't Close

[Michael]

Anyone ever run across an unclosable Telnet window?

Already tried:

Clicking the upper right X. No go.
Click upper left of telnet window - select Close. No go.
Windows Task Manager, Select Telnet, click End Task over and over. No
go. (State is running.)

The laptop system can not shut down because it sees the Telnet process
still running and unkillable. But the only way to get rid of the
telnet session is to remove the battery and power plug and cold shut
the thing down. Nasty and unrecommended. But no other option.

But perhaps you know of another avenue to kill the telnet window/app?
Thanks!

 

[Malke]

Anyone ever run across an unclosable Telnet window?

Already tried:

Clicking the upper right X. No go.
Click upper left of telnet window - select Close. No go.
Windows Task Manager, Select Telnet, click End Task over and over. No
go. (State is running.)

The laptop system can not shut down because it sees the Telnet process
still running and unkillable. But the only way to get rid of the
telnet session is to remove the battery and power plug and cold shut
the thing down. Nasty and unrecommended. But no other option.

But perhaps you know of another avenue to kill the telnet window/app?
Thanks!

Are you actually using Telnet for something? If you're not and it is
running, your machine has probably been compromised. Perhaps you could
give us a bit more information about what you're trying to do. I'll be
honest with you - I haven't used Telnet in years because it is insecure
(sends passwords in the clear).

Malke

 

[Don Taylor]

Anyone ever run across an unclosable Telnet window?

no and I use that fairly often

Already tried:

Clicking the upper right X. No go.
Click upper left of telnet window - select Close. No go.
Windows Task Manager, Select Telnet, click End Task over and over. No
go. (State is running.)

The laptop system can not shut down because it sees the Telnet process
still running and unkillable. But the only way to get rid of the
telnet session is to remove the battery and power plug and cold shut
the thing down. Nasty and unrecommended. But no other option.

But perhaps you know of another avenue to kill the telnet window/app?
Thanks!

I ^D the session, the server at the far end drops the connection,
the local window announces that, and the next keystroke sent to
the window closes it.

But I just checked and either of your methods of trying to close it
also work for me.

Who's telnet are you running? Windows\system32\telnet.exe?
Or someone else's?

Usually something won't die if it is hung waiting for i/o.

 

[Michael]

Thanks for the reply. Yes it's the built in Windows telnet program
\Windows\system32\telnet.exe. I can't replicate the problem reliably.
Occurs now and again - but drives me crazy when it does. I currently
have one of the never-die telnet sessions up and ready to test a
solution if someone can think of something clever to try. I've just
been putting the laptop into suspend rather than shutting it down.

 

[Don Taylor]

Thanks for the reply. Yes it's the built in Windows telnet program
\Windows\system32\telnet.exe. I can't replicate the problem reliably.
Occurs now and again - but drives me crazy when it does. I currently
have one of the never-die telnet sessions up and ready to test a
solution if someone can think of something clever to try. I've just
been putting the laptop into suspend rather than shutting it down.

Well, I guess divide and hopefully find a clue.

Does the problem happen when you have a telnet connection open to
another host versus Does the problem happen when you don't have a
telnet connection open to another host.

When you have one of the examples that won't die, does Windows
still think it is responding or does it say "Not Responding"
when you try to kill it via the task manager?

 

[Michael]

The last output in the telnet window is "exit" and then "Connection to
host is lost." I had been connected to a router. So in this case it
appears Telnet was attempting to disengage itself from a connection and
bonked on the way out.

Task manager Applications tab show Telnet in "Running" state. If I go
to the Processes tab I don't see a telnet.exe process in there. Not
sure if I should.

I ran a netstat -nb and no established connection appears there.

 

[Don Taylor]

The last output in the telnet window is "exit" and then "Connection to
host is lost." I had been connected to a router. So in this case it
appears Telnet was attempting to disengage itself from a connection and
bonked on the way out.
ok

Task manager Applications tab show Telnet in "Running" state. If I go
to the Processes tab I don't see a telnet.exe process in there. Not
sure if I should.

I try to reproduce this by opening a telnet session, ^D to close at
the far end, and then touch <ctrl> so I can do a <ctrl><alt><del> and
look at the task manager but the instant I touch <ctrl> the telnet
window closes so I couldn't inspect the task manager. Even if I put
up the task manager in the corner of the screen, if I give it a mouse
click after the Telnet disconnect the window disappears. So I'm
having difficulty trying to check my state to see how it compares.

I ran a netstat -nb and no established connection appears there.

I certainly wouldn't expect one, based on your telnet window claiming
it was closed, but that was a good thing for you to check.

Ok, lets try to eliminate the router as a possible accomplice.
Can you reproduce this if you telnet to some outside legit domain
and then close out the session. If it does it there too then we
know something. And if it doesn't then it points the finger more
at the router connection.

There is also a timeout interval, default is 2 hours. Google for
KeepAliveTime. It is really grasping at straws but I wonder what
might happen if you followed the Microsoft directions to change the
time, maybe it would time out and die if you set the interval to
say 5 minutes.

(I've been trying to do the reverse, make the silly LinkSys BEFSR41
NOT kill telnet sessions after 5 minutes. My changing the time to
be 4 minutes doesn't seem to fool the router to think I'm still active.
I'd love to find a way to get it to keep the session open.)

 

[Michael]

Well ^D had to effect on the telnet to the router at all. I went back
to the same router in face on which the telnet session got stuck - in
fact. ctrl-alt-del showed the telnet application in the applications
tab and there was a telnet.exe process in the Processes tab. So
there-in lies what I think is a bug. The stuck telnet window shows up
in the Applications tab but there is no telnet.exe process in the
processes tab for it. Another clue is that in the Programs tab - when
actually connected to a router the top bar of the telnet window says
"Telnet (hostname)". Whereas the stuck telnet window only says Telnet
in the top bar.

True to form - when I exited from the router with this new session with
"exit" and <enter> - the telnet window simply closed like it is
supposed to. This is normally what happens. But every so often - the
never-die window crops up.

Another option I guess would be to just move to PUTTY for telnet in
addition to using for just SSH as I do currently. But I like that you
can make the scrollback window with the default windows telnet 9999
lines. To capture output in putting you have to go into logging and it
takes about 3 or 4 steps. When you use these tools all the time - it's
significant.

 

[Michael]

I found that you can tweak the scroll-back buffer easily in putty. I
think I'll just go with that.