I am developing an application windows 10 on a stationary PC. I also have a tablet windows 10 that once connected to the PC via USB not see debugging (
How to make it accessible?
Ok so I found an article that highlights how to debug a UWP application on a Surface pro using a cable:
Essentially the Visual Studio debugger wants to debug your application via a network, so you are creating a network between your desktop machine and your surface pro.
Below is the guide with the main steps highlighted
https://tomsoderling.github.io/Wired-Debugging-on-Surface/
Hardware Needed
In order to debug over a wired connection, you’ll need a few things:
2 USB to Ethernet dongles. You can find them for pretty cheap on
Amazon.
A length of cat 5 cable to connect the two dongles together.
Connect the dongles together with the ethernet cable, and plug one
dongle into your laptop and the other into the Surface.
Launch the remote debugger program on your surface and configure the following:
No Authentication
Turning this off seems to alleviate a lot of the
hassle of trying to get the debugger to connect to the remote client
app. I debug on a private or wired network and only have the remote
client running when I need to debug, so the lack of security doesn’t
concern me here.
Allow any user to debug
I use this setting because
don’t log into my Windows 10 VM via Parallels so I’ve had an issue
with that. I also use this when my coworker needs to debug on the
Surface.
And then your device should be found in the Auto discover in visual studio
Related
I am developing on an ARM Mbed board which connects to my Windows laptop over USB. I've just moved to a new Dell laptop running Win 10 [from a Dell laptop running Win 7] and I find that the laptop resets my development board every 15 minutes.
There are two things that will cause the ARM Mbed board to reset:
powering down/up the USB connection
sending "break" via the USB serial driver.
When the reset occurs there is nothing of note in the Windows event logs. I have all of the "allow Windows to power me down" boxes unticked on the USB hubs in System devices and in the Control Panel power management options.
Does anyone have any suggestions on how I (a) debug what's going on or (b) fix/workaround the problem? I've not yet tried connecting via a powered USB hub, will do that next...
I had the same issue using a FRDM-K64F running mBed and communicating over a USB COM port to a Windows 7 Dell machine. The communication would sometimes drop out. As #Rob suggested, uninstalling the Dell Support Assist Agent completely fixed the issue.
Just adding this answer as it was very difficult to find any information using google.
Another note in support of this solution for google...
I have a Dell 5480 running Windows 10, and started using from ST Nucleo boards on it. I've used the exact same boards at work, with no problems. Every 15minutes or so the board was reset.
I tried disabling the Dell Support Assist services but this did not seem to fix the problem.
Removing the programs did make the Nucleo work.
I'm manufacturing a device that connects to my computer using Bluetooth and then a desktop Java app uses the Bluetooth connection to send serial data to the device which is then displayed.
When I try to connect my device to windows 7 it successfully finds and pairs with it creating a Bluetooth link on a COM port. This link can then be used by a serial prompt (used for testing) or my Java application. It works initially however soon after windows drops the connection and the only way to reconnect is to delete the device within devices and printers and then reconnect.
This seems to be a known problem with windows bluetooth so I decieded to use a third party Bluetooth application. I downloaded and tried Toshiba's Bluetooth Stack and it was able to add a Bluetooth device and keep a stable connection which works great however this only works for Toshiba computers without getting a cracked version.
This device is commercial and can't be sold with cracked versions of software. Has anybody experienced the same problems or not in other operating systems and has any solutions of advice as that would be a tremendous help.
This is not a good idea/method to use the COM ports generated by Windows, it's not working fine and not reliable in any scenario ; you should use Bluetooth Sockets instead.
Using Toshiba or Widcomm or BleuSoleil won't help: under Win7, all dongles are now trying to use the Microsoft Stack, not their own implementation.
A few useful pieces of information: I'm running Windows 8 Professional on a custom-built rig, and I am using a 'WiFi dongle' to connect my computer to the local router. I am using a home network, not a public/work/school network.
I installed the Windows Phone SDK. Piece of strawberry cheesecake so far. Coded my first simple browser app (as detailed on the Windows Phone Dev site) and hit the Run button, expecting my app to come to life and breathe in links and breathe out websites!
But instead, I got this:
Something happened while creating a switch:
Xde couldn't find an IPv4 address for the host machine.
In this case, the emulator wouldn't run at all. And so, I did my research and found out that the solution was this:
Remove all the switches from Hyper-V Manager's "Virtual Switch Manager", and make a new Internal one called Windows Phone Emulator Internal Switch.
I did, and the error did NOT show up again but it did screw up my WiFi and Bluetooth adapters (which I had to do a system restore to solve) and now both WiFi and Bluetooth peripherals are working again.
However, I got this error instead when running the emulator again:
The Windows Phone Emulator wasn't able to connect to the Windows
Phone operating system:
The emulator couldn't determine the host IP address, which is used to
communicate with the guest virtual machine.
Some functionality may be disabled.
In this case, the emulator did run, but I couldn't find my app anywhere. I did some research again and found that the solution to this was:
Delete the Windows Phone Emulator Internal Switch from Hyper-V Manager's Virtual Switch Manager.
Now, I created the switch to solve the problem in the first place. But I did delete it, for the heck of trying everything out. And no surprise there but, it went back to the first error.
I am now stuck in this paradox and have no idea how to escape it.
Thank you in advance!
follow the following steps to solve this problem
1.go to network and sharing center
2.go to change adapter setting
3.go to v Ethernet (internal Ethernet port windows phone emulator internal switch)
4.right click it and enable it(if already enabled then disable and enable it again).
Remove any Cisco VPN's or similar connections. I have found this VPN client works as a replacement to Cisco https://www.shrew.net/
For me shrew soft version 2.1.7 was the only version that worked.
I'm trying to track down some bugs on a Windows Mobile 5.0 app. The testers can reproduce these bugs no problem, but I can't. They are using the devices across a wireless network, but I'm always running the app in an emulator, or on the actual device while it's in its cradle. In other words I always have a hard-wired connection.
I'm not sure how to approach this. Boatloads of logging? Is there some way to get Visual Studio to "Start Debugging" across the wireless connection? How does one effectively debug wireless connection issues on a mobile device?
You can get the debugger working over the wireless by manually running conmanclietn2.exe and cmaccept.exe, but the fact that the debugger is then using the connection may well affect your testing (depends on what the issues you're trying to find are). Your best bet is to use logging.
Another option to try is to enable the WLAN connection when you're device is in the cradle (I assume it now switches off the WLAN connection when you cradle it, which is the WM5 default).
If you're using Vista, go to the Windows Mobile Device Center and under Mobile Device Settings go to Connection Settings. Make sure the Allow Data Connections On Device When Connected To A PC option is ticked (I think the option is called the same in ActiveSync in case you're using XP). That way you will have an active WLAN connection when trying to debug through the cradle.
Hi!
I have some PDAs (windows mobile) to test my application. One of them is HTC Touch Dual, and it have some bugs in debugging. There is another ARMv6 device I can use, but it's far far away. So I can't use USB cable, but can use TCP/IP (internet, not intranet).
Do you know, how can I connect to remote windows mobile device to debug application on it?
We tried different ways and now we know this:
ActiveSync is bad. It disables all external connections to device and it's impossible (or just I don't know how) to remotely debug device while it's connected via ActiveSync.
We have created VPN, connected device via wi-fi to remote PC, and setup routes to device be accessible over VPN. At this step device can be connected without ActiveSync (MSDN) from Visual Studio on remote PC. But connection from Visual Studio on my PC was not available - "device not ready". I can ping device, but can't connect it from Visual Studio.
I've checked following things:
binaries versions to connect without ActiveSync to be correct as said in MSDN article above
routers/firewalls don't block anything
device is ready to debug
sniffed packets to device looks similar in case of remote PC connection and my PC connection, but somehow my PC establish only 1 connection, while remote 2
I think, VPN and PDA connection without ActiveSync was very close to get remote debug, but something goes wrong with it. Maybe I just need some sleep now :)
And the questions are:
Do you know, how to debug remote winCE application in a simplier way?
What a problem can be with "VPN method" if it's the simplest way?
Thank you.
You can achieve this via CoreCon... After Microsoft moved from EVC to Visual Studio they deprecated Platform Manager in favour of CoreCon.
Take a look under C:\Program Files\Common Files\Microsoft Shared\CoreCon\1.0\Target\wce400[targetarch].
Basically you run ConmanClient2.exe and then CMAccept.exe which opens a window of time in which you can establish a TCP/IP connection via the IDE.
You can override the need for CMAccept.exe via adding the reg key HKEY_LOCAL_MACHINE\System\CoreConOverrideSecurity=DWORD:0x01.
After CoreCon is running on your target device, you need to point the IDE to the Device via the 'Device Options'/'Properties'/'Transport'/'Configure'/'Use specific IP address'. Simply set the IP to that of the device.
I have found CoreCon much faster and reliable than the old EVC infrastructure - the debugger definitely benefits from it. It has its fair share of limitations, but it doesn't depend directly on ActiveSync which more than makes up for it! :)