I'm trying to attach Visual Studio 2019 to a linux machine (64-bit Intel) running a custom Buildroot OS. When I try to connect via ssh with a password I get the error:
"Unable to connect to the Microsoft Visual Studio Remote Debugger named user#ip.address. Operation not supported. Unknown error: 0x80004005."
This is what happens right after I enter my credentials in the Attach to Process screen. That is before I even see the list of processes to attach to.
If I point VS to a different Linux machine (Ubuntu) it immediately shows me a list of processes running on it.
Any idea what I'm missing? Buildroot's sshd server says: OpenSSH_7.5p1, OpenSSL 1.0.2k 26 Jan 2017 and I do have wget installed. I installed curl in case that was it, but it still didn't work.
My Buildroot system is not on the public internet, but I'm not sure that matters. I'm guessing/hoping there's a secret requirement that I'm missing and can't find via google. Anyone have any ideas to try?
Maybe your OS image has a minimalistic “ps” command which accepts no argument, I think the problem comes from there : maybe VS runs a “ps” with several arguments (e.g. aux) to get the process list but the ps returns an error.
Update: even if you change the "ps" command to a more complete one, you can see the list of processes but you still can't attach to a process. VS apparently uses other commands that don't exist under a minimalist Linux distribution for embedded.
Related
I'm trying to run my code on a different PC and I keep getting an error when I try to launch my code via "docker compose".
I see that it is complaining about the path not being absolute, but I question why this is.
This is not something that happens on my other PC. If I check the SQL Server object explorer, the only difference I see is that the (localdb)\MSSQLLocalDB is a newer version than on my PC (the pc with the older version does not have the issue). The difference in versions are 15.0.41 (has error above) and 13.0.4001 (no error).
If this is the issue, how do I change my version to the other one?
And if this is not the issue would anyone know what causes it, I've tried a couple things (clean, rebuild, reinstall docker, delete the code and pull it again,...)
Thank you for your time and help.
I'm running a .Net Core microservice on Linux (Ubuntu) and am trying to remote debug with Visual Studio over SSH. But the service is run under the user svcuser and my user is mainuser. Main user is in the same group as the service user.
In visual studio, I can see the process that the service is running under, but when I try to attach I get:
One or more errors occurred. Failed to attach to process. The .Net Debugger has insufficient privileges to debug the process. To debug this process, vsdbg must be running with root permissions.
I checked in MS documentation but for Linux all they have is this: https://learn.microsoft.com/en-us/visualstudio/debugger/remote-debugging-dotnet-core-linux-with-ssh?view=vs-2019 which has no info on running the service with a different user
And the only info they have on fixing such a problem is for windows only: https://learn.microsoft.com/en-us/visualstudio/debugger/error-the-microsoft-visual-studio-remote-debugging-monitor-on-the-remote-computer-is-running-as-a-different-user?view=vs-2019
If you have sudo privileges then this is relatively easy, and can be kept secured to those users with sudo privs. Avoids needing to reconfigure users/environments, and allows you to debug any process on the machine regardless of which user account it is running as.
If you use Visual Studio to make an initial attempt to debug you will find that a ~/.vs-debugger folder has been created in the home directory of the user account you were attempting to use. This command will help you locate the vsdbg binary which was installed. You can install VsDbg manually but I find leveraging the automated process is easier. If you are using VSCode this becomes a manual process, and an exercize left for the reader, but I would still use VS2019 IDE to prep the target just to keep things consistent between tools.
find ~ | grep vsdbg
For my installation the binary is located at ~/.vs-debugger/vs2019/vsdbg and this path will most likely change over time.
First, rename the binary to something convenient:
mv ~/.vs-debugger/vs2019/vsdbg ~/.vs-debugger/vs2019/vsdbg-bin
Second, create a script to replace the binary:
touch ~/.vs-debugger/vs2019/vsdbg
chmod 770 ~/.vs-debugger/vs2019/vsdbg
nano ~/.vs-debugger/vs2019/vsdbg
The script content might look something like this, note the full path to vsdbg-bin, the use of $# ensures all command-line args passed to your script are forwarded to VsDbg.
#!/bin/bash
sudo ~/.vs-debugger/vs2019/vsdbg-bin $#
Now retry your debug session from Visual Studio, if you did things correctly you should be able to attach to any remote process on the target machine using SSH->VsDbg. "Works on my machine." ;) This was confirmed with VS2019 16.8.4, .NET 5.0, and VsDbg 16.9.20122.2 debugging an ASP.NET Core application running on Debian 5.4.8 (x64) launched by systemd under a service user account in Azure. "Sweet."
HTH!
I want to port my C#-Code to linux, so i have to debug under Mono.
Therefore i would use a VM Box with Linux OS and conect the Xamarin Studio, that runs under Windows, to the Box to debug on it with Mono.
Is it possible to connect my Xamarin Studio to the Oracle VM Virtual Box?
I tried it several times but the debugger didn't Start in 10 minutes. If i closed Xamarin during this starting process there was a this Message: Couldn't connect to Debugger.
If you have an other(easier) way to debug with Windows under Mono i am openminded for everything.
Does remote debugging still work?
https://ebsteblog.wordpress.com/2013/12/04/remote-debugging-with-monodevelop/
For those who are interested: Seems that it is possible. You have to connect the Xamarin to your VM Device and there you star the debugger agent. I couldn't start it yet but theoreticaly it should work. There's the problem:
patrick#patrick-VirtualBox:~$ mono --debug --debugger-agent=transport=dt_socket,adress=X.X.X.X:12345,server=y OSTest.exe
Cannot open assembly 'OSTest.exe': No such file or directory.
* Assertion at threads.c:391, condition `shutting_down' not met
Stacktrace:
Native stacktrace:
Don't know yet what this means.
I deployed a web role in windows Azure, based on the following tutorial.
http://weblogs.asp.net/scottgu/archive/2013/10/22/windows-azure-announcing-release-of-windows-azure-sdk-2-2-with-lots-of-goodies.aspx
but when I try attaching the debugger I get the following message:
"there was a failure to launch the remote debugger"
apparently this is a known issue, and the suggested solution from Microsoft is to restart the visual studio and try again, which unfortunately didn't work for me
http://msdn.microsoft.com/en-us/library/windowsazure/dn459835.aspx
Remote debugging may fail to attach to an existing Cloud Service:
After deploying a new Cloud Service the debugger may fail to attach to
an existing cloud service with the error message “There was a failure
to launch the remote debugger”. To correct this problem, restart
Visual Studio and reattach the debugger to the new deployment.
So I thought to ask here in case anybody faced the same issue and found another solution other than restarting the visual studio!
I'm using visual studio 2012, with Azure SDK 2.2
Make sure that you deployed a Debug build to your web role and that you have checked "Enable Remote Debugging for all roles" on the advanced tab during deployment. Failure to do either of these could lead to the problem your seeing.
I was using Azure SDK 2.2, so as to use "Attach debugger", but unfortunately I needed to use SDK 2.1 as 2.2 needs some references that weren't included in 2.1, so I guess this is the problem.
Thank you all for your help
I tried all of the solutions above and found that none worked for me. My problem turned out to be stale or inaccessible certificates that the VS debugger uses to connect to the service. I discovered this was the problem by going to event viewer and found:
A fatal error occurred when attempting to access the SSL client
credential private key. The error code returned from the cryptographic
module is 0x8009030D. The internal error state is 10003.
I had had other problems with permissions on private keys and so I ended up deleting all of the certificates from my personal store (current user) with the "Issued To" equal to "Windows Azure Tools". When I redeployed my service VS created new certificates and uploaded them.
Voilà -- attach remote debugger works again.
I got the same exception trying to remotely debug a VM in Azure, following the guide in Debugging Azure Virtual Machines.
What worked for me was to simply install the remote debugging tools matching my version of Visual Studio (VS2013 Update2).
Further I had to add a new endpoint in the Azure portal. This didn't work initially but eventually using the same public and private port number did the trick. The default port of 4018 worked.
Start the remote debugger program on the client machine in adminstrator mode and remember to set to port number, e.g. to 4018. I chose Windows authentication as well.
From within Visual Studio: Debug menu -> Attach to Process -> [yourVMName].cloudapp.net:4018 or whatever port number you chose. You should now see a list of processes on the virtual machine.
In case its helpful for someone else, I've just spent 3 hours on this! In the end I gave up and using 'Cloud Explorer' (in VS 2013, after installing the Azure SDK) I selected 'Disable Debugging' and noticed it cleared out port rules in the Network Security Group for the VM.
I hadn't seen it set these up (which is where I'd spent hours guessing that these were the issue and trying to figure them out from patchy MS documentation, broken links, etc).
So, I 'enabled debugging' for the VM and saw it set up security rules - something it didn't do the first time!
At a guess this is because I had initially enabled debugging for my VM soon after I installed the Azure SDK into VS. Since then I rebooted the VS server, and that may have enabled something in the SDK.
Anyway - before spending hours figuring out ports, reboot the VS server and then disable/reenable debugging in Cloud Explorer - you should see a status message (in the Azure Activity Log) saying 'Configuring networking security group debugging port' - this is the magic step that it didn't do the first time around.
I think you should try lunching VS in administrator mode, and see if you always have the same problem.
Else I think you should put more details about your problem.
This is what I did to enable debugging on an Azure VM.
At the time of this writing my current setup is as follows
Windows Server 2012 R2 IIS 8.5 (Virtual Machine)
Visual Studio 2013 Update 4
Microsoft Azure SDK Tools 2.5
Update Visual Studio to the latest Azure SDK
go th the server window (server explorer)
Expand the Azure node
Expand the virtual machines node
Right click on the VM you want to debug
Choose "Enable Debugging" Visual Studio will begin to add a debugger extension to your virtual machine
Once complete, Right click on the virtual machine from the virtual explorer and choose attach debugger
I am trying attach process on other PC to debug remote. But Type of code in the "Attach to process" dialog is always Native (x86 or x64) and never Managed code (my App is 100% managed). And after attaching I can't debug managed code. Why is that happens?
Now I have to change my question. The problem was in Remote transport mode(only native code support). But now I cant start working.
I made user with my login name and password on other PC with admin rights
I have run remote debugger from that user
After i chose Brows to that PC( server name from remote debugger), debugger says:
Unable to connect to server. The requested name is valid, but no data or the requested type was found.
On the remote computer look for in the Visual Studio Remote Debugging Monitor for something like Msvsmon started a new server named 'user#servername'...
Now, on the computer running Visual Studio enter the same server name in the Qualifier text field in the Attach to Process window. Unless you're on a 'safe network', leave the Transport at Default.
You should now be able to see your application under Available Processes.