I have an app that I have to debug. It is C++ on Windows Mobile 5.0, and it uses a network connection via WiFi. (Visual Studio 2008.)
Disconnected from USB and active sync the app connects to the network just fine, but as soon as I plug it into the cradle, (and consequently connect via ActiveSync) it automatically disables the WiFi network, and I can't seem to find anyway to turn it back on.
I need ActiveSync to control the program in the debugger, and I need WiFi to have the application run, but I seem to only be able to have one or the other.
Does anyone have any ideas? Please save me from having to resort to debugging via printf statements :-)
Don't use ActiveSync - debug directly through the WiFi connection.
I've recently been having reliable fortune debugging over WiFi. The magic seems to be configuring the device's transport IP address and using ActiveSync to jump-start the process.
(I'm using Visual Studio 2008 on a Windows 7 (x64) system; and a Windows Mobile 6.5 device, in case it matters.)
Start up copying the five files listed below unto the mobile device.
Make sure your WiFi is connected and your WM device had a valid IP.
Inside Visual Studio, select Tools .. Options .. Device Tools; then select Devices
Select the "Device" you want to debug; I used "Windows Mobile 6.5.3 Professional Device"
Properties
The Transport should be "TCP Connect Transport", click Configure.
Select "Use a specific IP address" and enter the address.
Exit the dialogs
Connect the WM device via ActiveSync; connect the project to the device within Visual Studio and run it (inside the VS debugger).
Exit the application, waiting to make sure the debugger completes normally.
Disconnect the device from the USB ActiveSync connection.
Run CMAccept (see below) on the mobile device
Run the debugger. (Don't wait to long, because there might a time-window.)
With any luck, the app will start just as if it were still connected to ActiveSync. You can even compile and deploy updated files without needing to reconnect ActiveSync.
First time this worked, I think my jaw hit the ground; I stumbled upon it by chance and simply couldn't believe it was working.
[Debugging on CE5.0 device without ActiveSync] discusses this for Visual Studio 2005 beta2; it seems to be relevant. (This link is also cited in another answer to this question).
The instructions include copying 5 files from host \Program Files\Common Files\Microsoft Shared\CoreCon\1.0\Target\wce400\<CPU> to \windows on the device.
I copied the 5 files from \Program Files (x86)\Common Files\Microsoft Shared\CoreCon\1.0\Target\wce400\armv4 to \VSDebugFiles on my device (expecting to experiment with them). What I did find was that, if Visual Studio refused to connect following the above steps, running CMAccept on the device would help.
In case the link is ever removed, the five files are:
clientshutdown.exe
CMAccept.exe
eDbgTL.dll
CommanClient2.exe
TcpConnectionA.dll
Ok, I admit that this is still very hit or miss, but it is hitting more often than not.
If you don't have a convenient way to check your device's IP, try VxUtil; it's my go-to network utility for validating Windows Mobile network connections.
Good luck, hope it works.
Related
The problem that I have is that after I have built my Unity project using Microsoft's Mixed Reality Toolkit and the Windows SDK 10.0.18362.0 I try to deploy it using the Hololens 2 emulator (version: 10.0.18362.1019). The result is that even though the emulator opens, my Unity application does not get deployed and the following error is being shown in Visual Studio's error list:
Please ensure that target device has developer mode enabled. Could not
obtain a developer license on 192.168.9.57 due to error 80004005
I found several articles online that had the same problem like me, and they either referred to resetting the HoloLens device (which I do not need to do, since it is an emulator) or enabling the Developer Mode on the host machine (in my case a fully updated Windows 10 Enterprise Edition computer), which I already have. Nevertheless the error persists.
I just hope that there will be a way to get rid of this error and manage to deploy my Unity application onto the HoloLens emulator.
It seems that the solution is very simple. If you actually run Visual Studio as an Administrator the application is successfully deployed onto the emulator.
I'm working with Visual Studio 2017. On a remote machine, there is Visual Studio 2012. There I start up msvsmon.exe as administrator, and in the "Tools" menu, I set "No authentication", "Allow any user to debug" (in order to be really sure that I'm not blocked because of permission issues).
On my local PC, I try to setup a debugging session, as follows:
Connection Type: Remote (no authentication)
Connection Target: Find => MachineName: "<_remote_machine>"
A ping request to "<_remote_machine>" is successful.
However now connections are found, and in the msvsmon.exe debugging monitor, no messages are seen.
What can cause this and how can I solve it?
P.s. I know that there might be mismatches between the 2012 and 2017 versions, but in that case I expect an error message to be shown in the debugging monitor, but as I said there is nothing there.
As mentioned by Jszpilewski, simply copying the "Remote Debugger" directory to the remote machine and launching msvsmon.exe from there is the start of the answer.
Following point: once the remote debugger is started, it says something like "Msvsmon started a new server named '<Machine_Name:Port>'.
On the local machine you just need to copy/paste this into the "Connection Target" box => Don't try to use the "Find" button, it's a waste of time.
I am trying to remote debug an Asp.Net Core Web Application (with Web API) project deployed as an Azure App Service with Visual Studio 2017 Professional.
Followed the instructions as documented here. Essentially, using the Server Explorer-->App Service-->Attach Debugger
Also, enabled the necessary firewall ports as mentioned. The ones I opened are TCP (4022, 4023) and UDP (3702). Also, ensure remote debugger application is in allowed list of apps in Windows Firewall. Documentation for the firewall steps.
Despite all the settings, I am getting following error
System.Runtime.InteropServices.COMException (0x89710023): Unable to connect to the Microsoft Visual Studio Remote Debugger named 'essamplepoc2.azurewebsites.net'. The Visual Studio 2017 Remote Debugger (MSVSMON.EXE) does not appear to be running on the remote computer. This may be because a firewall is preventing communication to the remote computer. Please see Help for assistance on configuring remote debugging.
at Microsoft.VisualStudio.Debugger.Interop.Internal.IDebuggerInternal120.ConnectToServer(String szServerName, VsDebugRemoteConnectOptions[] pConnectOptions, CONNECT_REASON ConnectReason, Int32 fIncrementUsageCount, IDebugCoreServer3& ppServer)
at Microsoft.VisualStudio.Web.Azure.MicrosoftWeb.Operations.RemoteDiagnosticsSessionBase.ConnectToServer(String site, String user, String password)
Any suggestion would be helpful.
The issue is resolved. We had to open outbound ports 4024 for VS 2019, 4022 for VS 2017 and 4020 for VS 2015 on corporate firewall.
For more info check these out:
https://learn.microsoft.com/en-us/visualstudio/debugger/remote-debugger-port-assignments?view=vs-2019
https://learn.microsoft.com/en-us/visualstudio/debugger/configure-the-windows-firewall-for-remote-debugging?view=vs-2019
I also had this problem. I solved it by changing the Platform from 32-bit to 64-bit in Application Settings as I am trying to debug from 64-bit machine.
It seems remote debugging is not turned on for your App Service.
Open your App Service in the Azure portal and go to Application Settings. Then turn Remote Debugging to On and select Visual Studio Version to 2017.
It should look like this:
Screenshot source
I hope this helps.
First, what did NOT work. Opening the port in my Firewall did not work for me. Restarting my local machine did not work, neither did restarting the app in Azure, nor updating VS2019 with the installer. I kept getting:
System.Runtime.InteropServices.COMException (0x89710023): Unable to connect to the Microsoft Visual Studio Remote Debugger named 'empirepipedriveapi-newversion.azurewebsites.net'. The connection with the remote endpoint was terminated.
Finally, what DID work, I deleted the deployment slot and then added it again, I deleted the publish profile in Visual Studio 2019 and recreated it again, a published the app (without even recompiling it) and then WAS able to connect (I did refresh the available slots in the Cloud Explorer first just to be overly careful). I believe, and this is the 2nd time in about a year, that, on rare occasion, the deployment slot can become corrupted. I noticed this time when I published the app, it took longer and it seemed much more activity took place, leading me to believe that there was code in the old slot that was is not refreshed on each and every publish and it must have become corrupted.
I'm trying to remote debug from Visual Studio 2013 to a remote server running Windows Server 2012.
I have run Msvsmon from my remote server and the Server Name in Options is FEP\build#DSS1Build1. I have set Windows Authentication and also given EVERYONE permission to Debug.
On Visual Studio on my own machine I do Attach to process and in the Qualifier field put the same Server name ie. FEP\build#DSS1Build1.
However when I press Refresh I get the message:
"Unable to connect to Microsoft Visual Studio Remote Debugging monitor... does not appear to be running on remote computer"
Is there something I need to unblock in the Firewall?
A couple of things need to be done.
On the remote server, you need to start Visual Studio Remote Debugging monitor and make sure you run it as a admin user (as otherwise you can't connect).
Make sure it is the right version (depends on if your server is 64bit or 32 bit).
Also you need to make sure that the remote debugging service is running. You can run the configuration wizard to see the status.
Then you need to put the full qualifier in as you mentioned.
Has anyone successfully used the Unity profiler with a physical mobile device? (i.e. the Unity 3.4 IDE tool that provides real-time stats on Unity calls, not the iOS or Android internal profilers). And if so, can you post the details about your setup and your experience?
I'm starting to get the feeling that people aren't using the profiler to test their games on real devices, given how little I can find in the Unity documentation and forums or on the web in general. In particular, dreamora is the only person I have heard of who has successfully attached the Unity profiler to a real device running a game (and then, only on iPhone not Android). It is also suspicious to me that the Android remote tool for Unity 3.4 which I downloaded form the marketplace requires a cable to connect to the Unity IDE and doesn't seem to have a wireless option; I see this as a red flag that wireless profiling by attaching the Unity profiler to an Android device may be impossible (please correct me someone if I'm wrong).
I would like to know your experiences (good or bad) with this tool, and assuming you have been able to profile a device, specifically I would like to know:
1) Did you connect to and Android or iOS?
2) What device and API version (i.e. Nexus S1 AndroidAPI=2.3.7 Kernel=2.6.35.14 running Cyanogen MOD 7.10)
3) What type of computer are you using (Windows or Mac, and OS)?
4) What is the nature of the connection you were able to make between your computer and the device?
4.1) Wired or wireless?
4.2) If wireless, ad-hoc from computer to device, tethering from device to computer, or both connected to the same WLAN router?
4.3) If wireless, what is the setup (DHCP, Static IP, ttl=4, etc?)
5) What are the Unity build settings (i.e. Development Build checked/unchecked, Autoconnect Profiler checked/unchecked, etc?)
6) What were the specific steps you took to connect to the device? (i.e. Build and run on device, then restart Unity twice, then offer up a prayer to the gods by sacrificing a Symbian phone, then connect via the Active Profiler pull-down, etc.)
Let's get to the bottom of this together, I will repost any information this community can provide me with in the Unity forums as well.
Well, I am going to partially answer my own questions here: By following these steps I was able to connect to and profile my Android Nexus running the Cyanogen Mod (7.1) using my MacBook pro (running 10.6.8 "Snow Leopard") on both Unity 3.4.1 and 3.4.2:
Create a WiFi Hotspot using Internet sharing on your Mac. Use the "Share your connection from: Ethernet" and "To computers using AirPort (AirMac)" options. I did not password protect my network.
Connect to this the WiFi network on your Android.
Quit Unity.app (if you already launched it).
Disable the Ethernet interface under System Preferences -> Network (select 'Off' from the Configure IPv4 pull-down menu)
Launch Unity.app
Enable Ethernet interface under System Preferences -> Network (select 'Using DHCP' from the Configure IPv4 pull-down menu)
Now Your Android should be in the list of the Profiler window. Of course, you will need to launch a Unity application that was built with the 'Development Build' and 'Autoconnect Profiler' checkboxes selected under Build Settings (that's what I did at least).
Happy Hunting!
-Arun
If the above don't work or you need to profile specifically on a Windows Phone, try the following...
1.) Make sure in Build Settings you set it to 'Development Build'.
2.) Connect your phone to your Wifi Network, then click on the wifi connection to see your phone's IP address
3.) Enter the phone's IP address in the profiler, and press the 'Record' button and the profiler will begin profiling on your phone.
4.) Run your game from Visual Studio, wait and you will see the profiling will begin.
If you don't see your phone in the profiler, try this alternate method
1.) Connect the phone to your PC
2.) Make sure in Build Settings you set it to 'Development Build'.
3.) Build the game to Visual Studio
4.) Run the game in 'Debug' mode from Visual Studio
5.) When the game is running on the device and is past any loading screens, click on the 'Active Profiler' dropdown in the profiler, and the device should be listed there