none
Windows Embedded Compact 2013 remote tools do not connect. RRS feed

  • Question

  • Trying to connect to remote tools but cannot in Win CE 13.

    Build debug version of CE 13 image with KITL and profiler enabled, download it via Ethernet to target and then try to connect remote file viewer, which fails to connect.

    Removed from network and tried static IP addresses and we run into the same problem.

    Firewall is disabled. 

    Any ideas why? 

    Monday, January 11, 2016 8:55 PM

Answers

  • More than likely you have the "CoreCon3 Managed Code Compact 2013 Application Debug Tools" subproject included in your osdesign.

    Remove the subproject, rebuild and try it.

    This subproject includes components for managed application debugging. Unfortunately it does not play nicely with the native platform builder tools.

    David Vescovi


    Dave

    • Marked as answer by rob18767 Thursday, January 21, 2016 2:48 PM
    Thursday, January 21, 2016 11:35 AM

All replies

  • In the OS, does KITL start and connect?

    Note: The bootloader != the OS, so the bootloader connecting and downloading the OS is not the same as connecting in the OS.



    Bruce Eitman (eMVP)
    Senior Engineer
    Bruce.Eitman AT Eurotech DOT com
    My BLOG http://geekswithblogs.net/bruceeitman
    I work for Eurotech

    Monday, January 11, 2016 9:07 PM
    Moderator
  • Thank you for your reply. 

    The bootloader (via hyperterminal) reports that KITL is connected to desktop. 

    The bootloader then boots into the OS (touch screen calibration or windows embedded compact desktop comes up)

    Once we are in the OS we still cannot run remote tools. 

    One item to note is the bootloader reports that KITL cannot get an IRQ and therefore runs in polled mode. Could this be an issue? 

    Tuesday, January 12, 2016 1:25 PM
  • So, KITL is not connected in the OS.  You can't expect to use KITL if it isn't connected.  Again, note: The bootloader != the OS, so the bootloader connecting and downloading the OS is not the same as connecting in the OS.  I repeat this because your response was about the bootloader not the OS.

    You need to investigate why your OS is not connecting? 

    Are you sure that you included KITL?  If you are sure, then why are you sure?

    You may need to look at your BSP code to determine why it isn't connecting, does OEMInit() initialize it?  Is there an if condition?



    Bruce Eitman (eMVP)
    Senior Engineer
    Bruce.Eitman AT Eurotech DOT com
    My BLOG http://geekswithblogs.net/bruceeitman
    I work for Eurotech

    Tuesday, January 12, 2016 1:57 PM
    Moderator
  • Okay I see, Those are KITL messages from the bootloader only. 

    The bootloader also gives the messages: 

    "

    Connecting to Desktop
    +KitlEthGetDevCfg(0x84EDBFA6, 0xFFFFC478->1450)
    -KitlEthGetDevCfg(rc = 1)
     KITLConnectToDesktop: Including 12 bytes of custom transport config data.
     KITLConnectToDesktop: Encoding packet
     KITLConnectToDesktop: Sending to CFG to desktop
    KITL: Connected host  IP: 192.168.4.94  Port: 64990
     KeyIndex 0 not set on host
     KeyIndex 1 not set on host
     KeyIndex 2 not set on host
     KeyIndex 3 not set on host
     KeyIndex 4 not set on host
     KeyIndex 5 not set on host
     KeyIndex 6 not set on host
     KeyIndex 7 not set on host
    KITL connected with Desktop
    +KITLRegisterDfltClient, service:0
    +AllocClient: ServiceName: 'DBGMSG', Flags: 0x00.
     AllocClient: Allocating single-instance service.
        ServiceName:           'DBGMSG'
        ServiceId:             0
        ServiceInstanceId:     255
        Flags:                 0x00
    -AllocClient: ec: 0x00000000, ppClient: 0xFFFFC450.
    +KITLRegisterDfltClient, service:1
    +AllocClient: ServiceName: 'PPSH', Flags: 0x00.
     AllocClient: Allocating single-instance service.
        ServiceName:           'PPSH'
        ServiceId:             1
        ServiceInstanceId:     255
        Flags:                 0x00
    -AllocClient: ec: 0x00000000, ppClient: 0xFFFFC450.
    OEMKitlEnableClocks: 1"

    This appears to be confusing me. How do I ascertain that KITL is running in the OS? 

    Tuesday, January 12, 2016 2:19 PM
  • Why do you keep telling us about your bootloader?  It would be better if you would answer any of the questions that I have taken the time to ask.



    Bruce Eitman (eMVP)
    Senior Engineer
    Bruce.Eitman AT Eurotech DOT com
    My BLOG http://geekswithblogs.net/bruceeitman
    I work for Eurotech

    Tuesday, January 12, 2016 2:42 PM
    Moderator
  • I was trying to tell you why I got confused (KITL connected with Desktop) although yes I do appreciate I brushed over your questions. My bad. 

    Yes KITL is included. 

    OEMInit has the  code: 

    //----------------------------------------------------------------------
       // Initialize the KITL
        //----------------------------------------------------------------------
        g_oalKitlEnabled = KITLIoctl(IOCTL_KITL_STARTUP, NULL, 0, NULL, 0, NULL);

    I am going to dig into this (report the return value for a start). 

    That said the question I asked in the previous post was about the OS not the bootloader. 

    "How do/would I ascertain that KITL is running in the OS? "



    • Edited by rob18767 Tuesday, January 12, 2016 2:57 PM
    Tuesday, January 12, 2016 2:56 PM
  • Why would I have answered that question, when you wouldn't answer any of mine?

    So, you still haven't answered why you believe that KITL is included in your OS.  Answer that first.  I suspect that it isn't included.



    Bruce Eitman (eMVP)
    Senior Engineer
    Bruce.Eitman AT Eurotech DOT com
    My BLOG http://geekswithblogs.net/bruceeitman
    I work for Eurotech

    Tuesday, January 12, 2016 3:00 PM
    Moderator

    • Edited by rob18767 Tuesday, January 12, 2016 3:12 PM
    Tuesday, January 12, 2016 3:11 PM
  • I "believe" it's included because it is included in the build options of the project properties. 


    Tuesday, January 12, 2016 3:13 PM
  • Rob:

    Perfect! Yes you have included KITL.

    This isn't my first rodeo, so along the way I have learned that when someone isn't answering question that they don't know the answers or have mis-stated the facts of the problem.  Either way, it best to determine if either is true.

    Your plan to do some debugging is the best next step.  You should have the code for in your BSP for KITL, so don't hesitate to dig deeper than just the return value.

    Other things to check:

    1. Your bootloader may disable KITL in a boot menu, so check that.
    2. Check your CE.BIB for KITL references (this is probably overkill, your previous answer tells that you included KITL - but I have been known to overkill...)



    Bruce Eitman (eMVP)
    Senior Engineer
    Bruce.Eitman AT Eurotech DOT com
    My BLOG http://geekswithblogs.net/bruceeitman
    I work for Eurotech

    Tuesday, January 12, 2016 3:34 PM
    Moderator
  • Thank you for that. 

    We checked our bootloader and it does not disable KITL. We checked CE.BIB and it contained one reference to kitl.dll. 

     kitl.dll        C:\WINCE800\Osdesign\AM33X_BBB8\AM33X_BBB8\RelDir\AM33X_BBB_BSP_ARMV7_Debug\kitl.dll                 NK  SHZ

    When we download the image we get this device status window, 

    When we try to connect to the remote file view this window never goes away as we try to connect. 

    We cannot get passed this. 

    Thursday, January 14, 2016 4:41 PM
  • Hi Rob,

    What is showing in the Platform Builder Debug output when this negotiation is occurring?

    Sincerely,

    IoTGirl

    Thursday, January 14, 2016 5:52 PM
    Moderator
  • 9491861 PID:49a0016 TID:4640016 OSAXST1: >>> Loading Module 'coredll.dll' (0x9541E000) at address 0x40010000-0x400D5000 in Process 'Cmaccept3.exe' (0x9547B000)
    9491861 PID:49a0016 TID:4640016 OSAXST1: >>> Loading Module 'Cmaccept3.exe' (0x9547B000) at address 0x00010000-0x00022000 in Process 'Cmaccept3.exe' (0x9547B000)
    PB Debugger Loaded 'C:\WINCE800\OSDESIGN\AM33X_BBB8\AM33X_BBB8\RELDIR\AM33X_BBB_BSP_ARMV7_DEBUG\CMACCEPT3.EXE', no matching symbolic information found.
    9491906 PID:49a0016 TID:4640016 OSAXST1: >>> Loading Module 'msvcrt.dll' (0x9541FD80) at address 0x400E0000-0x40180000 in Process 'Cmaccept3.exe' (0x9547B000)
    9491911 PID:49a0016 TID:4640016 OSAXST1: >>> Loading Module 'locale.dll' (0x95420900) at address 0x40A20000-0x40A4D000 in Process 'Cmaccept3.exe' (0x9547B000)
    9491914 PID:49a0016 TID:4640016 OSAXST1: >>> Loading Module 'normalize.dll' (0x95420B50) at address 0x40A70000-0x40A7C000 in Process 'Cmaccept3.exe' (0x9547B000)
    9491917 PID:49a0016 TID:4640016 OSAXST1: >>> Loading Module 'sorting.dll' (0x95420F30) at address 0x40A50000-0x40A60000 in Process 'Cmaccept3.exe' (0x9547B000)
    9491934 PID:49a0016 TID:4640016 Dll list:
    9491937 PID:49a0016 TID:4640016 OSAXST1: <<< Unloading Module 'coredll.dll' (0x9541E000) at address 0x40010000-0x400D5000 in Process 'Cmaccept3.exe' (0x9547B000)
    9491937 PID:49a0016 TID:4640016 OSAXST1: <<< Unloading Module 'msvcrt.dll' (0x9541FD80) at address 0x400E0000-0x40180000 in Process 'Cmaccept3.exe' (0x9547B000)
    9491939 PID:49a0016 TID:4640016 OSAXST1: <<< Unloading Module 'sorting.dll' (0x95420F30) at address 0x40A50000-0x40A60000 in Process 'Cmaccept3.exe' (0x9547B000)
    9491939 PID:49a0016 TID:4640016 OSAXST1: <<< Unloading Module 'normalize.dll' (0x95420B50) at address 0x40A70000-0x40A7C000 in Process 'Cmaccept3.exe' (0x9547B000)
    9491939 PID:49a0016 TID:4640016 OSAXST1: <<< Unloading Module 'locale.dll' (0x95420900) at address 0x40A20000-0x40A4D000 in Process 'Cmaccept3.exe' (0x9547B000)
    9491939 PID:49a0016 TID:4640016 OSAXST1: <<< Unloading Module 'Cmaccept3.exe' (0x9547B000) at address 0x00010000-0x00022000 in Process 'Cmaccept3.exe' (0x9547B000)
    PB Debugger Unloaded symbols for 'C:\WINCE800\OSDESIGN\AM33X_BBB8\AM33X_BBB8\RELDIR\AM33X_BBB_BSP_ARMV7_DEBUG\CMACCEPT3.EXE'

    Above is the Debug output window. 

    Thursday, January 14, 2016 6:04 PM
  • Hi Rob,

    Hmmm, CMAccept3 is correct but I don't see anything regarding the connection being established.  You don't want this on your final device but can you try setting the registry entry "HLKM\System\CoreConOverrideSecurity = 1" on your device? That should ensure the CMAccept# module loads.

    Do any of the remote tools work? (FYI: There are two kinds; CoreCon & Remote Framework tools.) When the UI asks what transport, which are you choosing?

    PS: You can dig around MSDN & Blogs for info on CoreCon.

    Sincerely,

    IoTGirl

    Thursday, January 14, 2016 6:30 PM
    Moderator
  •  the registry entry"HLKM\System\CoreConOverrideSecurity = 1" is already set/ 

    I have tried remote file viewer and the Compact test Kit. Neither of them work. 

    The transport is ethernet. (I have KITL enabled for the project see above). 


    Thursday, January 14, 2016 6:43 PM
  • Hmm, are you selecting Kitl as the transport? The remote tools can use the same transport.
    Thursday, January 14, 2016 6:48 PM
    Moderator
  • How do I select KITL as the transport? 

    Thursday, January 14, 2016 7:00 PM
  • As far as I can tell in Windows Embedded Compact 13 there is no way of selecting this. 


    Thursday, January 14, 2016 7:37 PM
  • There should be a dialog that pops up saying "Select a Windows Embedded Compact Device". Try a simpler CoreCon tool like "Remote Zoom In" - Note you have two choices, App Builder or Platform Builder connection.

    Thursday, January 14, 2016 7:38 PM
    Moderator
  • Selected Zoom remote tool. I select bbone as that is the device is attached (image downloaded). 

    Same problem with same debug output error messages as before. 

    Thursday, January 14, 2016 7:48 PM
  • Maybe I missed it but I don't see an exact error message in the debug window above. Is it a remote timeout or something?

    You could force the correct files to be in place by following the docs here: 

    https://msdn.microsoft.com/en-us/library/dn197917.aspx

    Thursday, January 14, 2016 8:09 PM
    Moderator
  • The error messages in the debug output window were the same as before i.e.

    9491861 PID:49a0016 TID:4640016 OSAXST1: >>> Loading Module 'coredll.dll' (0x9541E000) at address 0x40010000-0x400D5000 in Process 'Cmaccept3.exe' (0x9547B000)
    9491861 PID:49a0016 TID:4640016 OSAXST1: >>> Loading Module 'Cmaccept3.exe' (0x9547B000) at address 0x00010000-0x00022000 in Process 'Cmaccept3.exe' (0x9547B000)
    PB Debugger Loaded 'C:\WINCE800\OSDESIGN\AM33X_BBB8\AM33X_BBB8\RELDIR\AM33X_BBB_BSP_ARMV7_DEBUG\CMACCEPT3.EXE', no matching symbolic information found.
    9491906 PID:49a0016 TID:4640016 OSAXST1: >>> Loading Module 'msvcrt.dll' (0x9541FD80) at address 0x400E0000-0x40180000 in Process 'Cmaccept3.exe' (0x9547B000)
    9491911 PID:49a0016 TID:4640016 OSAXST1: >>> Loading Module 'locale.dll' (0x95420900) at address 0x40A20000-0x40A4D000 in Process 'Cmaccept3.exe' (0x9547B000)
    9491914 PID:49a0016 TID:4640016 OSAXST1: >>> Loading Module 'normalize.dll' (0x95420B50) at address 0x40A70000-0x40A7C000 in Process 'Cmaccept3.exe' (0x9547B000)
    9491917 PID:49a0016 TID:4640016 OSAXST1: >>> Loading Module 'sorting.dll' (0x95420F30) at address 0x40A50000-0x40A60000 in Process 'Cmaccept3.exe' (0x9547B000)
    9491934 PID:49a0016 TID:4640016 Dll list:
    9491937 PID:49a0016 TID:4640016 OSAXST1: <<< Unloading Module 'coredll.dll' (0x9541E000) at address 0x40010000-0x400D5000 in Process 'Cmaccept3.exe' (0x9547B000)
    9491937 PID:49a0016 TID:4640016 OSAXST1: <<< Unloading Module 'msvcrt.dll' (0x9541FD80) at address 0x400E0000-0x40180000 in Process 'Cmaccept3.exe' (0x9547B000)
    9491939 PID:49a0016 TID:4640016 OSAXST1: <<< Unloading Module 'sorting.dll' (0x95420F30) at address 0x40A50000-0x40A60000 in Process 'Cmaccept3.exe' (0x9547B000)
    9491939 PID:49a0016 TID:4640016 OSAXST1: <<< Unloading Module 'normalize.dll' (0x95420B50) at address 0x40A70000-0x40A7C000 in Process 'Cmaccept3.exe' (0x9547B000)
    9491939 PID:49a0016 TID:4640016 OSAXST1: <<< Unloading Module 'locale.dll' (0x95420900) at address 0x40A20000-0x40A4D000 in Process 'Cmaccept3.exe' (0x9547B000)
    9491939 PID:49a0016 TID:4640016 OSAXST1: <<< Unloading Module 'Cmaccept3.exe' (0x9547B000) at address 0x00010000-0x00022000 in Process 'Cmaccept3.exe' (0x9547B000)
    PB Debugger Unloaded symbols for 'C:\WINCE800\OSDESIGN\AM33X_BBB8\AM33X_BBB8\RELDIR\AM33X_BBB_BSP_ARMV7_DEBUG\CMACCEPT3.EXE'

    The remote tool just keeps on trying to connect or it bombs out with an exception. 

    From the link I copied the files:

    • clientshutdown3.exe
    • CMAccept3.exe
    • ConmanClient3.exe
    • DeviceAgentTransport3.dll
    • eDbgTL3.dll
    • TcpConnectionA3.dll

    And pasted them to: 

    C:\WINCE800\Osdesign\AM33X_BBB8\AM33X_BBB8\RelDir\AM33X_BBB_BSP_ARMV7_Debug

    Where my image for the OS that I download resides. 

    Same problem. Connecting to device window pops up and doesn't connect. 


    Thursday, January 14, 2016 8:19 PM
  • Strange I don't see an error or any failure in the debug output. My only thought is a mis-matched corecon for some reason. Do you have multiple versions of CE on this one box? 

    At this point I have nothing else I can research for you except if it is not working, there is some other detail I am missing. Basically, it seems impossible to me that your KITL transport is up but you can't connect a tool. It is the same socket and since kitl is using it, it should be available for your remote tools.

    I know this link is for Compact 7 but the concept is the same, just the compilers used to create the tools are different: http://www.embedded101.com/Blogs/SamuelPhung/entryid/257/Compact-7-Getting-Started-Part-8-Debug-and-Remote-Tools

    Can you try using Auto (ether) to connect to your platform? This should make no difference but it will force PB to create the connection dynamically.

    Thursday, January 14, 2016 9:59 PM
    Moderator
  • It's a long shot but do you have cesvchost in both inbound and outbound?  https://msdn.microsoft.com/en-us/library/hh300132.aspx

    Basically the more typical issue is this: http://geekswithblogs.net/BruceEitman/archive/2010/03/30/windows-ce-chat-transcript-march-30-2010.aspx

    Q: I created a OS design with KITL and kernel debugger enabled. But I am unable to connect to the target for debugging. I am getting the following error when i try to connect with the device. PB Debugger Cannot initialize the Kernel Debugger.
    PB Debugger Debugger could not initialize connection.
    PB Debugger The Kernel Debugger is waiting to connect with target.
    PB Debugger The Kernel Debugger has been disconnected successfully.
    A: One possibility is that a rogue cesvchost.exe has co-opted the debugger. I am assuming this is CE 6.0? Can you try exiting visual studio and manually killing the cesvchost.exe process from the Task Manager?

    You could do the same, close VS, kill CESVCHost and restart to see if that fixes anything.

    • Proposed as answer by DaveVMVP Thursday, January 21, 2016 11:29 AM
    • Unproposed as answer by DaveVMVP Thursday, January 21, 2016 11:29 AM
    Thursday, January 14, 2016 10:16 PM
    Moderator
  • More than likely you have the "CoreCon3 Managed Code Compact 2013 Application Debug Tools" subproject included in your osdesign.

    Remove the subproject, rebuild and try it.

    This subproject includes components for managed application debugging. Unfortunately it does not play nicely with the native platform builder tools.

    David Vescovi


    Dave

    • Marked as answer by rob18767 Thursday, January 21, 2016 2:48 PM
    Thursday, January 21, 2016 11:35 AM
  • That was it. Problem solved. 
    Thursday, January 21, 2016 2:49 PM
  • Following up - We have a specific issue that for some target units prevents the remote tools from connecting; for other units with the same OS build and network configuration, there is no problem.  We are using WEC2013 on Arm i.MX6 target, up to date as of Dec 2016.  Our Platform Builder OS build includes KITL but it's not enabled by the bootloader. We’re running ConmanClient3 and CmConnect before each session.  I’m able to deploy to the target in both cases.  The problem is confirmed to be on the target side, not on the development system. We're using VS2013 and Windows Embedded Compact Platform Builder 8.00 (6228) current as of Nov 2016.

    We used wireshark to record what happens when attempting to open a debug session, and on units that don’t fail, wireshark sees a packet coming from the target to the pc that contains this text: “RemotePort=6511 ConnectToIp=10.84.67.225”.  That's the IP of the target. We’re guessing that’s sent by CoreCon3, asking the development PC to use the passed IP and port for debug.  This IP address is also in the registry in entry IPAddress under key HKLM/Software/Microsoft/CoreCon3. The good IP address is the first IP in a list of IPs in this setting.

    On units that fail to connect, wireshark found this: “RemotePort=6511 ConnectToIp=169.254.251.164”.  And this same bad IP address appears in the first position in the IPAddress setting in the registry.

    The registry entry contains a list of IP’s (as IPV6,IPV4 pairs).  For the units that work, the correct pair is the first pair in the list, while for units that fail, the correct IP is present but is not the first entry.

    Of course I tried to edit the registry, but my changes are overwritten with the original wrong info when I try to connect a remote tool or to start a debug session.

    I’ve been using the remote process viewer mostly for testing.  I find that if it connects, then I’m also able to start a remote debug session.

    Perhaps someone with access to the CoreCon3 source code could take a look? Question: why bother to support a list of IPs in the IPAddress registry setting when only the first is used? And what determines the order?

    Thanks

      
    Charlie Wallace – San Diego<o:p></o:p>

       charlesw@omnitracs.com <o:p></o:p>



    Wednesday, December 14, 2016 10:53 PM
  • We removed the debugger from platform builder. Problem went away. 
    Thursday, December 15, 2016 2:33 PM