Remote Desktop Mobile (RDP Client) disconnects after 10 minutes of inactivity

[UPDATE 10/9/2009: Source-Code and CAB are now available at]
[UPDATE 9/2/2010: v2 of the sample app is available at it takes care of the battery-life impacted by application continuing to emulate mouse-move even after user closed RDP session – see details below]

  • Error Message: “The remote session was ended because the idle timeout limit was reached. This limit is set by the server administrator or by network policy.”
  • RDP\TSC Clients and Windows Mobile OEMs
  • What’s new in Windows Mobile 6.5 about Remote Desktop Mobile

This issue should be somehow well known by the Community, but I couldn’t easily find a solution so I had to think one by myself… 🙂 After 10 minutes of inactivity of a Terminal Server session on Windows Mobile devices, the Remote Desktop Mobile application needs you to logon again stating that a timeout “set by the server administrator or by network policy” occurred. Unfortunately it’s not really a good error message, since many times the server is correctly set and the problem is just client-side… Anyway, probably it was not very frustrating since in the most of the cases one is logged via RDP only to actively work on the server. But this is not always true, so I’d guess either I wasn’t able to find someone with a possible solution, either simply people accepted to live with it…

Remote Desktop Mobile on WM6.x (and, before this, the TSC client on WM5) is a component that OEMs are not required to include to have their OSs pass the Windows Mobile Logo Test Kit, and this is basically why you may find devices with it in-ROM and others where you need to find alternative solutions. In any case, regarding the inactivity timeout issue, luckily Windows Mobile 6.5 _should_ now have an updated version of the Remote Desktop Mobile application that OEMs can include in their images, easier to use on the field as it allows, for example, to finally customize an idle timeout!! Unfortunately it’s not included in the emulators coming with the Windows Mobile 6.5 Developer Tool Kit.

Back to the problem… after some researches I understood that the timer is reset only when the Remote Desktop Mobile’s application window receives mouse or keyboard input. Refreshing the window, or sending exotic WM_xx messages wasn’t enough. So, I came to thinking what was a possible keypress or mouseevent that can be programmatically simulated (through keybd_event() or mouse_event()) that wouldn’t impact application at all?? After some tests I’ve realized that MOUSEEVENTF_MOVE, which is the event of user “moving the mouse”, has no effect on current Windows Mobile-based devices: that event is maintained as codebase with Windows CE, where an OEM may also include a non-touch screen where you really have a mouse to move… but its only effect on Windows Mobile device is for example to modify display’s brightness, in case the display entered a sort of power-safe state (well, obviously the mouse-pointer is moved on the remote server)

So, the idea was to develop a Win32 Console application that simply launches the Remote Desktop Mobile application and every X minutes (5? 9?) simulates a mouse-movement of some pixels and after a short time another one to place the mouse on the previous position.

This is NOT elegant code at all, absolutely, but it does what was meant to run a specific task… Nerd

Obviously this watch-dog application would “waste” one of the 30 process slots… is it acceptable? As you can see the application doesn’t do anything special or unsupported: it’s simply a monitor-console application with no particularly elegant code. As usual, I would strongly encourage on adding some error-checking!!

int _tmain(int argc, _TCHAR* argv[])
    int const FIVEMINUTES = 1000*60*5;
    HWND hWndRDM = NULL;
    //Firstly launch RDP Client
    sei.cbSize = sizeof(sei);
    sei.nShow = SW_SHOWNORMAL; 
    sei.lpFile = TEXT("\\Windows\\wpctsc.exe");
    sei.lpParameters = TEXT(" ");
    if (!ShellExecuteEx(&sei))
        MessageBox(NULL, TEXT("Couldn't launch RDP Client"), TEXT("Remote Desktop Launcher"), MB_OK);
        goto Exit;

    //Now every X minutes check if it's still running and if so "refresh" its window
    //if it's no longer running, exit
        //check if RDP Client is running, otherwise exit
        hWndRDM = FindWindow(_T("TSSHELLWND"), NULL);
        if (NULL != hWndRDM)
            ////Get foreground window -- this is not needed if RDM is launched Full-Screen as it was in this case
            //hWndForeground = GetForegroundWindow();

            //Give focus to the RDP Client window (even if the logon screen, in case user logged out in the meantime)

            //The timer is reset when the rdp window receives mouse or keyboard input
            //with no MOUSEEVENTF_ABSOLUTE the move is relative

            mouse_event(MOUSEEVENTF_MOVE, 100, 0, 0, 0);
            mouse_event(MOUSEEVENTF_MOVE, -100, 0, 0, 0);

            ////Give focus back to previous foreground window

            //RDP Client is not running - let's exit
            goto Exit;
    while (TRUE); //The check (NULL != hWndRDM) is already done inside the loop

    if (NULL != hWndRDM)
    return 0;

I can imagine that this problem affects more the WinMo Users rather than the WinMo “Devs”, therefore I had in mind to distribute directly the CAB of the application, if anyone else doesn’t want to do it for the Community. I’m wondering if CodePlex would be a good place, I’ll see and update this post. In any case, remember that it’s up to the OEMs to decide if including RDM (\Windows\wpctsc.exe) in their OSs based on Windows Mobile platform!




EDIT 9/2/2010:

After interacting with some users of the sample application and tested a v2 build on some scenarios, I’d like to share it now – note that the CodePlex project page will continue containing both versions. The issue was that MyRDM continued to emulate mouse-move even after user closed session, and this impacted on battery-life: this was not a bug, but simply a well known limitation of the tiny sample application… so we wanted a code that acted on the following possible conditions after every sleep-interval:

  • Wpstsc is no longer running (user “minimized” and OS closed it) –> in this case, MyRDM.exe exits
  • Wpstsc is running AND:
    • The “remote session” is foreground –> then MyRDM.exe emulates mouse-move and goes back to sleep
    • The “remote session” is not foreground for one of the possible causes:
      • User “minimized” wpstsc –> then MyRDM.exe kills wpstsc and exits
      • User logged off, and the foreground window is the RDM Logon window –> then MyRDM.exe does nothing and simply goes back to sleep

So the main portion of the code is the following (the same disclaimers apply as before):


                //check if RDP Client is still running, otherwise exit
                hWndRDM = FindWindow(_T("TSSHELLWND"), NULL);
                if (NULL != hWndRDM)
                        hWndForeground = GetForegroundWindow();
                        if (hWndRDM == hWndForeground)
                                //The timer is reset when the rdp window receives mouse or keyboard input
                                //with no MOUSEEVENTF_ABSOLUTE the move is relative
                                mouse_event(MOUSEEVENTF_MOVE, 100, 0, 0, 0);
                                mouse_event(MOUSEEVENTF_MOVE, -100, 0, 0, 0);
                        else //this means that RDM main windows is no longer foreground, however it may be that the RDP logon page is active
                                pid = NULL;
                                threadId = GetWindowThreadProcessId(hWndForeground, &pid);
                                //only if the foreground window is not the RDP logon page, then kill wpctsc.exe and exit
                                if (pid != GetProcessIdByName(TEXT("wpctsc.exe")))
                                        goto Exit;
                else //hWndRDM == NULL: RDP Client is not running - let's exit
                        goto Exit;
        while (TRUE);


HTH, ciao!


Comments (27)

  1. Reinier says:

    Hello Raffaele,

    This is exactly what I was looking for but I do not know if it is working or not. I have an intermec CK3 running Windows Mobile 6.1 Classic/CE 5.2. I get connected using the provided RDC and it still has to reconnect every 10 minutes. Now, when it is reconnecting it seems more an issue with the wireless connection trying to reconnect than an issue of having lost the RDC. Of course, if you lose your wireless you will loose your RDC but I cannot find any settings about keeping the wifi alive. I will appreciate any response regarding this matter. Thanks.

  2. Raffael says:

    Hi Reinier, if the message you get is the one described in the post and you get exactly after 10 minutes of inactivity, then chances are that the app can help.. 🙂 Regarding the wifi connection dropping after inactivity, it may also be a settings made available by the OEM, who actually developed the WLAN driver. Or, if the WiFi connection is handled by the Connection Manager (and is not an exclusive connection), then you may want to modify the CacheTime value under HKEY_LOCAL_MACHINECommConnMgrPlannerSettings (the default is 600 seconds = 10 minutes).



  3. Fabrizio says:

    Ciao Raffaele, thanks a lot for what you did.

    I used the cab file and using the "My Remote Desktop Mobile", it works just for 10-15 mins and when I check again I still find the timeout error. Maybe I do something wrong and it open the normal version?

    Tnx for the help.


  4. Raffael says:

    Ciao Fabrizio, thanks for your comment. Pls contact me offline by using the "Email blog author" link above (…/contact.aspx) and I'll try to help as much as I can. For example, I've lately worked on a second version of the tool and was planning to finalize testing before publishing it on

    A presto, ciao!

  5. bernat (NaN) says:

    Hi Raffaele,

    I will use on a WM5 and works perfectly!

    Thanks for it.

  6. Luis says:


    Thank you very much for the program, installed it on a PDA with Windows Mobile 6.5, and solved the problem.

    I have only to first open the remote desktop program, and later DRMkeepbusy (if I open only DRMkeepbusy, often fails, I suppose it's because the code is executed before the start remote desktop, and the program is closed)



  7. Raffael says:

    Thanks for your comment Luis. Yes, you're right: the sample code is very limited. In fact, I've worked with some other members of the CodePlex community on a second version, which takes in consideration other scenarios and will probably post it on the project-page after some further testing. Thanks again!

  8. Mikael says:

    Hi. I had the problem that the rdp dropped atfer 10 minutes. When I installed your program everything worked fine (i saw when dthe mouse moved and the screen light up. But randomly the Intermec c3k freezes and the only thing to do then is to take out the battery. It happens when the screen ilghts up and I see the mouse moves. The problem is that it can happen aftrer 5 minutes and it can happen after 30 minutes. Do you think you can help me with this problem?

    Regards / Mikael

  9. Raffaele Limosani says:

    > randomly the Intermec c3k freezes and the only thing to do then is to take out the battery

    Hi Mikael, unfortunately based on my experience this kind of problems are OEM-specific related to some customization of the platform: I would start by checking if the OEM provided a new firmware update for the device model. In any case, does this problem happens only when the program emulates the mouseevent? If you think at any specific way you could avoid the freezing, you may also modify the sample code. Pls contact me offline (…/contact.aspx) in case I can be of any help.


  10. Mikael says:

    Hi. Yes. It happens only when the mouse moves. As you maybe have seen i´m not a coder. If you have any idea for a solution i would be happy to test

    / Mikael

  11. FileReflex says:

    Visit allows you to access remotely your desktop or laptop computer from Windows Mobile 6.5. You can send and receive emails, surf web, edit documents in word processor, copy, cut, paste files or folders and do hundreds other things that you typically do sitting in front of your home or office computer.

  12. Raffaele Limosani says:

    Thanks FireReflex for your comment, I'm glad to redirect some traffic 🙂 this is exactly how a Community should work. In the meantime, Mikael and I are working on the issue offline.



  13. eDo says:

    Hi Raffaele, I have the same problem that has Mikael. I also have a CK3 and randomly the Intermec c3k freezes.

    Otherwise, I download the VS2008 project(the second version) and I have linking problems:

    Error 1 error LNK2019: símbolo externo CloseToolhelp32Snapshot sin resolver al que se hace referencia en la función "unsigned long __cdecl GetProcessIdByName(wchar_t *)" (?GetProcessIdByName@@YAKPA_W@Z) MyRDM.obj MyRDM

    Error 2 error LNK2019: símbolo externo Process32Next sin resolver al que se hace referencia en la función "unsigned long __cdecl GetProcessIdByName(wchar_t *)" (?GetProcessIdByName@@YAKPA_W@Z) MyRDM.obj MyRDM

    Error 3 error LNK2019: símbolo externo Process32First sin resolver al que se hace referencia en la función "unsigned long __cdecl GetProcessIdByName(wchar_t *)" (?GetProcessIdByName@@YAKPA_W@Z) MyRDM.obj MyRDM

    Error 4 error LNK2019: símbolo externo CreateToolhelp32Snapshot sin resolver al que se hace referencia en la función "unsigned long __cdecl GetProcessIdByName(wchar_t *)" (?GetProcessIdByName@@YAKPA_W@Z) MyRDM.obj MyRDM

    Error 5 fatal error LNK1120: 4 externos sin resolver Pocket PC 2003 MyRDM


  14. kaifa says:

    Hi, what about putting a simple label blicking in the server application? This will force the application to do some traffic?

  15. Raffaele Limosani says:

    @eDo: "4 externos sin resolver Pocket PC 2003" maybe you're trying to compile against Pocket PC 2003 SDK? Accordingly to doc (…/aa914612.aspx) these APIs are available on WM5 onwards.

    @kaifa: if I recall correctly only a "mouse" or "keyboard" event client-side makes the timer reset – yes in fact at the time of the post I wrote "the timer is reset only when the Remote Desktop Mobile’s application window receives mouse or keyboard input".



  16. hjgode says:


    thanks for sharing this information. I am using parts of your code in rdp_keepbusy for my autologin tool:…/automated-login-for-remote-desktop-mobile-ii

    Unfortuntely on WinMo 6 devices the seesion still timeout after 10 minutes. I am currently investigating this.



  17. Suneesh says:

    Thabnk you Mr. Raffaele for the code. it is working perfectly with my windows mobile 6.1. Thanks alot.

  18. josef says:

    Hello again

    in windows mobile 6.5.3 (or what you call now Windows Embedded Handheld 6.5.3) the mouse_event will have no effect and the session still times out!

    The workaround to this is to use SendMessage with the right "input window" and WM_MOUSEMOVE. Even keybd_event does not work, only SendMessage(…WM_KEYDOWN…) to the right window handle.

    I will post a solution for Int*rm*c devices shortly on my web at

    Thanks for your findings and support


  19. josef says:

    Hello again

    I have updated the app to work with WEH 6.5 (great name changing from Windows Mobile 6.1 to Windows Embedded Handheld 6.5):…/wm-6-5-remote-desktop-client-disconnects-after-10-minutes

    The mouse_event call will NOT make RDM busy and you will be kicked of your session after 10 minutes of idle time.

    You have to use SendMessage(…WM_MOUSEMOVE…) with the Remote Desktop Mobile Input Window handle.

    I dont know what is the difference between mouse_event and SendMessage(…WM_MOUSE…) but it does not work for RDM.

    Thanks for your support so far, looks like you are going the mainstream way to Windows Phone 7. I have to go the industrial way and stay with WEH.



  20. Raffaele Limosani says:

    Hi Josef, I'm glad you found this post useful. I don't know at this what's exactly changed with WEH6.5 respect to WM6 about the RDP, and I'm wondering if you're experiencing a OEM-specific issue. In any case, my understanding is that you addressed the problem, is that correct? Otherwise, consider opening a Service Request at Technical Support: we'll try to help as much as possible!…/get-help-now-a-vademecum-about-requesting-technical-support-from-microsoft.aspx



  21. Hi All

    Have been having this exact problem in our corporate environment. Unfortunately when testing the software found here, in some cases it crashes at the exact second the mouse move event happens. The device (Intermec CK3) screen goes completely white and a hard reboot is needed.

    I'm sure this program works for some of you but if not and you share the same issue, I have found an alternative I thought I would share.…/eLazy-87236.shtml

    This is just a task scheduler that can run a prerecorded set of actions on a schedule. I recorded touching the screen to simulate a mouse move but when replayed this also crashed the device. On the second occasion I recorded a keyboard event and set it on a schedule of 3 minutes.

    In summary this program runs in the background, then every 3 minutes it presses the right key and the counter in terminal services manager is reset devices can now be kept connected to RDP until the battery runs out.

    No coding needed, an alternative for the less techy ones of us out there. Surprisingly works very cleanly and does not interfere with user experience.

  22. El'dar (from Rus) says:

    Raffaele, thanx

  23. ad2sound says:

    Hello. I tried to run myRDP to HP iPAQ HX2790b. Does it works with Windows Mobile 5 ?


  24. Dennis says:

    The solution works great. However, if the user not properly log off and Disconnects, after logging back to a server right the way, RDP client disconnects after 10 minutes of inactivity.  How to fix it?

  25. Adrian says:

    Does windows embedded 7 have the same 10 minute RDP idle session timeout problem?

  26. Just Inn says:

    I found a solution on the Intermec CK3X's by going to Profile Settings –> Power –> change to 'Always On'

    Seemed to work for me running a test 'idle' device and it ran for a good 20 minutes without disconnecting.

    The big test will be tonight when the factory workers use them for a 12 hour shift – I will report back tomorrow.

  27. Just Inn says:

    hmmm, the above didn't work – some scanners are fine whereas othe ones disconnect after 10 minutes – have swapped the login and proved it's the scanner at fault, not the logins so it's not an AD issue.