Unable to debug smart device applications that have been deployed to the target device RRS feed

  • Question

  • My problem is the following, I'm developing applications for an ARMv7 Development Kit, running Windows Embedded Compact 7, with Visual Studio 2008 Professional using Windows 7 Enterprise and am unable to debug either managed or native applications that have been deployed to the Development Kit.


    The OSDesign for the target device is an unaltered Vendor design (from the company Variscite), with the exception of selecting the “.NET String Resources” in the catalogue. *Note* I’m unable to deploy applications without this being selected. 

    I selected WinCE Device as the device to be connected to and selected TCP Connect Transport as the transport method. 


    For testing purposes I'm using only a blank Windows Forms application and set the break point at Initializecomponent().

    I am able to connect VS to the target device. When I press Ctrl + F5, VS builds the application and then Deploys it, i.e. the blank Form is displayed. When I use F5,  it also builds and deploys the application, but the debugger doesn't start, instead the following error message is displayed:

    “The remote connection to the device has been lost. Please verify the device connection and restart debugging.” 

    I tried this out on a colleagues computer and VS was able to connect, the application was deployed and then received the error "Unable to start debugger".

    I also received one other error message, the only one that was halfway useful.


    The 8007 indicates it's a WIN32 error.
    Convert the 0x2745 to decimal will give you 10053.
    You can then lookup that error in the winerror.h Win32 SDK file




    // MessageText:


    // An established connection was aborted by the software in your host

    // machine.


    #define WSAECONNABORTED                  10053L


    I analyzed the network traffic and did indeed confirm that the connection is being aborted on the host side,  the host sent a RST, ACK packet. 

    However this doesn't help to pinpoint what's causing the connection to be aborted.

    I also tried this out with 2 of the emulators that came with VS2008, namely the "USA Windows Mobile 5.0 Smartphone R2 QVGA" and the "Pocket PC 2003 SE" and to my surprise it functioned properly, VS connects, deploys and starts debugging the application. I also used the TCP transport method with the emulators.

    So it works with the Emulators but not with my Development kit. I've spent two weeks on this problem and went through multiple blog entries, for example: but all to no avail.


    Best Regards,


    Anthony Franks

    • Edited by Anthony Franks Wednesday, November 2, 2011 11:17 AM Typo
    • Moved by Jesse Jiang Friday, November 4, 2011 7:28 AM (From:Visual Studio Smart Device Development – Visual Basic and C# Projects)
    • Moved by Sean LimingMVP Sunday, February 14, 2016 6:16 AM Windows CE question
    Wednesday, November 2, 2011 11:15 AM

All replies

  • Hi Anthony,


    I think your issue should be raised in the  Windows Embedded Standard 7:Tool Forums . I believe they will know more information of this issue than us, and I will move this one to that forum.


    Thanks for your understanding,


    Best regards,


    Jesse Jiang [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, November 4, 2011 7:28 AM
  • Still the wrong forum. Please try one of the Windows CE forums:


   / /, Book Author - Pro Guide to WES 7, XP Embedded Advanced, Pro Guide to POS for .NET
    Friday, November 4, 2011 6:06 PM
  • I'm pretty certain that this has something to do with a Vendor Specific BSP that we're using or perhaps a hardware problem with the Development Kit we're using, either way I'm taking this up with the Vendor to see if a fix can be found. Perhaps if I do get a fix for this and I'm allowed to, then I'll write a blog entry about the solution.

     Whoever is in charge of Moderating the threads can delete this one if they so see fit, as I've found a workaround for this issue for the time being.

    Thank you for the help.


    Anthony Franks

    Monday, November 7, 2011 10:18 AM