Terminal illness



  • Imagine a terminal server, called TERMIE.

    This server is a little busy … someone is using up all the available CPU.

    Task Manager reveals that all the CPU is going to two mstsc.exe processes. Both of these belong to the same user, Fred.

    Fred has two terminal sessions, both of which are active. Each session contains one of the offending mstsc.exe processes. Both sessions are coming from a computer called ............ TERMIE.

    Somehow this guy has managed to rig the terminal server so that his only sessions are from the server back into itself. I logged off one of those sessions, and the other session switched to Disconnected. I don't even know if this guy was in work that day, and he didn't reconnect, so who knows ....


  • Trolleybus Mechanic

    @Daniel Beardsmore said:

    Imagine a terminal server, called THERMITE.
     

    I like my story better.



  • Brain, containing termites …



  • How does a remote desktop program use up 100% of the CPU on a server?



  • If I had any idea what this guy had done, I'd tell you.



  • I have a good guess. He managed to connect two sessions in a loop.



  • To add more detail to the guess- He had a session open with data in it, and the session was disconnected. For whatever reason, the next time he connected he got a new session.

    Trying to get the old one back, he started playing with TSCON.... and all of the tools are in play that can lead to this.



  • One has to wonder. I am not aware that the bloke in question is technical, but I cannot rule out some ill-advised web searches and some strange and unfortunate incantations.

    Pulling this off is just so enormously far from the beaten track, and I am not aware of any problems with that server creating redundant sessions for anyone. The idea that a you'd get a redundant session, and realise that your existing session is still alive somewhere (with very little actually in it, I must add), and succeed—as a non-technical person—in finding tscon via a web search and use that to regain access to the other session, without at any point calling the helpdesk (which we know he's willing to do), makes my mind boggle. It boggles me beyond eliciting this site's eponymous ejaculation to discover that you can actually wire sessions into a loop and crash mstsc, and that anyone would ever get that far (especially after they'd already tunnelled back into the session they wanted already). (I didn't actually dig deep into it to figure out truly what had happened and where both mstsc processes were looking.)

    What I should do over the Christmas break, when nobody's looking, is figure out why it's only getting one CPU core when it's been given four. That's the main reason why this problem became visible — massive performance degradation.



  • @Daniel Beardsmore said:

    What I should do over the Christmas break, when nobody's looking, is figure out why it's only getting one CPU core when it's been given four. That's the main reason why this problem became visible — massive performance degradation.
    Raymond Chen knows!



  • Oops, this tab was sat open from when I went off to read what Mr Chen had to say.

    It's a Hyper-V virtual server configured for four CPU cores. Hyper-V says it's getting four, but Task Manager only sees one.



  • @Ben L. said:

    How does a remote desktop program use up 100% of the CPU on a server?

    Quite easy, if you enable transparent clipboard forwarding and somehow manage to create a loop between the clipboards you forward between.

    "Usually" it happens if you connect to machine A with RDP, then connect from machine A to machine B with for example VNC (because you don't want to kick the other user who is using it at the moment) and later forget your still open RDP session to machine A and take over the session on machine B via RDP. Voila, clipboard loop, and the next time you (try to) copy something, everything comes to a halt until you close either of the two RDP connections (if you still can)...

    I'm not sure how you can create a clipboard loop by connecting RDP sessions in a loop on one server (on two servers it should be easy if you configure RDP to take over active sessions automatically and forget on which server you are), and how you manage it in a way that something gets copied to the clipboard afterwards (ok, except perhaps starting a VBScript that sleeps a few seconds and then overwrites the clipboard).



  • @Daniel Beardsmore said:

    Hyper-V says it's getting four, but Task Manager only sees one.
    Was it configured for four cores when Windows was installed on the VM? It might be running a uniprocessor HAL.



  • @flabdablet said:

    @Daniel Beardsmore said:
    Hyper-V says it's getting four, but Task Manager only sees one.
    Was it configured for four cores when Windows was installed on the VM? It might be running a uniprocessor HAL.

    Correct, thanks!

    I've sorted that; now I just need to arrange for it to be rebooted.


Log in to reply