Remote Debugging on Linux ARM not Available

[nzain]

Environment data

Developer machine:

PS D:\somehwere\> dotnet --info
.NET Command Line Tools (2.0.0-preview1-005977)
Product Information:
 Version:            2.0.0-preview1-005977
 Commit SHA-1 hash:  414cab8a0b
Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.10240
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.0.0-preview1-005977\
Microsoft .NET Core Shared Framework Host
  Version  : 2.0.0-preview1-002111-00
  Build    : 1ff021936263d492539399688f46fd3827169983

Target machine is an embedded ARM Cortex-A7 - but it will fail on any non-x64 architecture.

    root@colibri-imx7:~# dotnet --info
    Microsoft .NET Core Shared Framework Host
    Version  : 2.0.0-preview2-25407-01
    Build    : 40c565230930ead58a50719c0ec799df77bddee9
    root@colibri-imx7:~# uname -a
    Linux colibri-imx7 4.1.39-2.7.2+gba2f75f #1 SMP Thu Jun 8 14:05:02 CEST 2017 armv7l GNU/Linux

VS Code version: 1.13.0 C# Extension version: 1.10.0

Steps to reproduce

Follow the remote debugging guide: https://github.com/OmniSharp/omnisharp-vscode/wiki/Attaching-to-remote-processes

The critical step is the VSDBG installation on the server.

curl -sSL https://aka.ms/getvsdbgsh | bash /dev/stdin -v latest -l ~/vsdbg

Expected behavior

An ARM debugger is installed.

Actual behavior

The script fails to determine the RID. It seems only x64 RIDs are supported, I tried to supply several RIDs manually, but the download only works for very few x64 RIDs. My application is successfully targeting -r linux-arm. See https://github.com/dotnet/corefx/blob/master/pkg/Microsoft.NETCore.Platforms/runtime.json for a list of RIDs.

I see that this is the same debugger that Visual Studio 2017 uses and not part of the OmniSharp project. Who is responsible for those mysterious debuggers and why are they built for x64 only? Is it part of an open source project (hope) or closed source (hopeless). Any directions are welcome. Remote debugging is essential for ARM devices!

[gregg-miskelly]

@nzain just to confirm - this is currently expected. We do not yet support ARM.

[gregg-miskelly]

@nzain BTW: Does the .NET Team have official ARM packages yet? Last I head they did not.

[nzain]

@gregg-miskelly ARM is well supported in the upcoming 2.0 release, see https://github.com/dotnet/core-setup. The linux releases are less distro-specific and there is a generic "linux-arm" package on the Release/2.0.X track, which I'm using right now. There are quite some raspberry PI tutorials based on .net core 1.x and even tizen (armel, not armhf) is getting support in 2.0.

I agree that I'm too early for "official" support, but I'm ok with compiling the debugger offroad. Since I'm compiling the whole linux for my device, this is just another step during my "asp.net core on ARM" journey :)

Are there any plans for arm debugging support? Alternatives? It is quite easy to simulate / mock regular webserver stuff, e.g. connecting to some in-memory database instead of real servers. However, it is difficult to properly mock real hardware sensors (e.g. a 3D laser scanner) connected via low level hardware (UARTs and the like). Debugging support would improve productivity enourmously.

Suggestions welcome!

[gregg-miskelly]

@nzain producing a build of the debugger for ARM is something on a radar, but it isn't something that we have started on yet, or figured out exactly when we will deliver. From my understanding, the .NET Core debugger team hasn't started looking at their APIs on Linux ARM, so I am not sure if it is even possible to make a managed debugger yet. Regardless, vsdbg, the debugger that this extension uses, is a proprietary product, so it isn't something that you will be able to build. So unfortunately there isn't much you can do at this point.

[nzain]

Thanks for clarification!

[gregg-miskelly]

@nzain I will leave your issue open as this is something we plan to address. I just am not sure the exact timeline yet (other than it will not be super soon).

[nzain]

Great to hear, definitely looking forward to this!

Am 13.06.2017 6:50 nachm. schrieb "Gregg Miskelly" <notifications@github.com

:

Reopened #1562 https://github.com/OmniSharp/omnisharp-vscode/issues/1562 .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OmniSharp/omnisharp-vscode/issues/1562#event-1121767690, or mute the thread https://github.com/notifications/unsubscribe-auth/ANUK-6gnmXUIff_WmJDEd_EXRuc8LkVCks5sDr3PgaJpZM4N3DMm .

[JP-CZ]

Hello! We are starting a project where we want to port our existing framework to .NET Standard and use .NET Core on a linux based ARMHF architecture. We would definitely vote this up, since it is of fundamental interest for us to be able to debug on the device. Is there any descision made on this topic yet?

[gregg-miskelly]

Our tentative plan is to start work on this sometime in the next month, but there are too many unknowns to at all guess when the work will be done.

[tamaskaroly]

Hi! Any updates on this? Remote debugging is a must have for embedded devices (we are also using an ARM processor). Is there any way the community (me :)) can help with this?

[gregg-miskelly]

We are getting quite close to releasing an "alpha" version.

A few notes:

1. Debugging support in .NET Core 2.0 is very busted. So, trying this will require running the target app under one of the daily builds of .NET Core 2.1.
2. If anyone subscribed to this thread has any feedback on what OS distro/version they would like to use that may be helpful. Thus far we have been using Raspbian 9.

[gregg-miskelly]

I should add: we will post information here about how to set things up once we have this alpha version available.

[Suchiman]

👍 for incomming debugger support I am using Ubuntu Server 17.10 on raspberry pi 2

[nzain]

Exciting and an important step for "dotnet everywhere". Regarding the distribution, you will see Raspian when people "try things out" and Selfmade Linux (buildroot or yocto are popular) for many real world applications. We use buildroot, because it is simple, you can customize every bit, easily add your own apps and end up with 40MB Linux without dotnet. Great, when you ship updates for your firmware! Third party updates never destroy your product.

Am 17.11.2017 03:08 schrieb "Gregg Miskelly" notifications@github.com:

I should add: we will post information here about how to set things up once we have this alpha version available.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OmniSharp/omnisharp-vscode/issues/1562#issuecomment-345123947, or mute the thread https://github.com/notifications/unsubscribe-auth/ANUK-xwGDaHCUk5v4RNcWGX6AroowMXBks5s3OqZgaJpZM4N3DMm .

[fabien-chevalley]

I am using raspbian 9 on raspberry pi 3 thank's for this improvement!

[tamaskaroly]

We are using a custom distro created with Yocto.

Gregg, you mentioned version 2.1, but I haven't seen any announcement regarding what the planned features are. Do you have any info on that? (Do you know if ARM64 is even talked about?)

Thanks for the great work!

[gregg-miskelly]

The only info I have on 2.1 -

• It makes ARM debugging work :)
• So far at least, official arm64 work is not part of the plan
• Here is the roadmap: https://github.com/dotnet/core/blob/master/roadmap.

@petermarcu may be able to comment further on any possible timeline for official arm64 support, or if there is an issue tracking it somewhere

[Petermarcu]

I don't know of any concrete plans for linux arm64 in .NET Core 2.1. That said I know that there are runtime builds of linux arm64 here is an example

Its probably something that the community could help bring up if someone is interested.

[tamaskaroly]

The link to the roadmap page is broken.

[nzain]

When I wrote about self-built custom linux, I wondered what the debugger guys should do with that information. Key for self-builders are documented dependencies, ideally nothing too fancy. Yocto and Buildroot both have a large repository of dependencies that can be enabled (built into the resulting OS).

• Easy: a list of stable-branch dependencies commonly available (download & build latest)
• Ok: beta dependencies (in yocto/buildroot you target certain commits for each dependency)
• Bad: dependencies that are not generally available for a wide range of platforms. Chances are, that someone made it work for debian-arm32 or raspbian, but not for anything else. Yocto and Buildroot should be able to build all dependencies.

I wonder, what dependencies are required to get this debugger project going - not the easiest task, I guess.

[Czlw]

For our project on a Dragonboard with Debian Linux it would be very helpful to have a remote debugger. Definitely vote up for this.

[gregg-miskelly]

We haven't yet tried any distro aside from Raspbian, but we have our first beta release up. Instructions for anyone who wants to try it: https://github.com/OmniSharp/omnisharp-vscode/wiki/Remote-Debugging-On-Linux-Arm

[bus710]

So vsdbg for RPI3 is available now, right?

This is the news I have waited for such a long long time! Previously I tried to write a manual to do it in Korean and I realized that that is not possible because of absence of vsdbg for RPI. Also the setup seems like almost same as the setup process for x86 systems' remote debugging so that I can finish the manual soon!

Thanks for you guys' hard working on it. Very appreciate it.

PS. which means I can make a DLL from the BCM2835 library to control RPI's GPIO and play with the vsdbg! great!

[gregg-miskelly]

Yes, this should work on Pi3s (its one of our test systems in fact).

[Suchiman]

I've managed to get debugging running from VS using these instructions on ubuntu 17.10 on the raspberry pi 2 😄 👍 🙌 💯 🥇.

My first attempts using vs code failed because the process terminated with StackoverflowException after printing Loaded '/home/ubuntu/test/System.Private.CoreLib.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled. but updating to a newer runtime and deploying in Debug (instead of Release) configuration made it work!

[chuckries]

@Suchiman I'm glad you have it working! Do you know what version of the runtime you were initially using? The StackoverflowException coming from the app is what we saw when running netcoreapp2.0 on coreclr 2.0, which is why we are saying only netcoreapp2.1/coreclr 2.1 are supported.

[Suchiman]

@chuckries the StackoverflowException was happening with 2.1.0-preview1-25929-02 which is the version used by default by the 2.2.0-preview1-007622 SDK from a few days ago so then i upgraded to the very latest from myget

<RuntimeFrameworkVersion>2.1.0-preview1-25930-03</RuntimeFrameworkVersion>
<NETStandardImplicitPackageVersion>2.1.0-preview1-25930-03</NETStandardImplicitPackageVersion>

which made it work (all using Self Contained Deployment)

[RoySalisbury]

Am I mistaken, or is this debugger only useful if you're using Visual Studio Code, and not the standard Visual Studio IDE on Windows? I don't see how the launch.json system works in Visual Studio.

[Suchiman]

@RoySalisbury as i've explained, when you follow those instructions, you can get it to work in VS. Instead of the Machine setup - Linux Computer steps, use these steps. But this is "offroad" debugging, so it's a little cumbersome. For reference, here's how my launch.json for VS looks like (same name as VS Code but different structure for VS):

{
  "version": "0.2.0",
  "adapter": "C:\\tools\\plink.exe",
  "adapterArgs": "-i C:\\tools\\piberryCert.ppk ubuntu@piberry -batch -T ~/vsdbg/vsdbg --interpreter=vscode",
  "languageMappings": {
    "C#": {
      "languageId": "3F5162F8-07C6-11D3-9053-00C04FA302A1",
      "extensions": [ "*" ]
    }
  },
  "exceptionCategoryMappings": {
    "CLR": "449EC4CC-30D2-4032-9256-EE18EB41B62B",
    "MDA": "6ECE07A9-0EDE-45C4-8296-818D8FC401D4"
  },
  "configurations": [
    {
      "name": ".NET Core Launch",
      "type": "coreclr",
      "cwd": "~/ConsoleApp1",
      "program": "ConsoleApp1",
      "request": "launch"
    }
  ]
}

[RoySalisbury]

@Suchiman

Thanks. I also noticed that I can start vsdbg with the '--interperpreter=mi' param. Then use the Visual Studio debugger attach using SSH (built in). I'm going to try that as well.

Roy

[Suchiman]

@RoySalisbury yeah if you've installed vsdbg in the default location, you can attach over ssh without starting vsdbg manually IIRC. With the launch.json you can start debugging on the remote machine. Now it just needs auto deployment 😃. Interesting thing with the --interpreter mi vs. vscode, any recommendation from debugger folks which one is better for VS?

[RoySalisbury]

Initially I was unable to ge thte Visual Studio debugger to attach by selecting the process. However, I figured out what was going on.

Basically, Visual Studio runs the following command on the remote:

GetVsDbg.sh -v vs2017u5 -l "/home/pi/.vs-debugger/vs2017u5" -d vscode

So, we know two things right off. It uses the 'vscode' command set and not the 'mi' one. And second, it wants the debugger installed in '/home/pi/.vs-debugger/vs2017u5'. So, I renamed the existing directory (didn't want to loose it just in case), and copied over the ~/vsdbg version that was installed for linux-arm.

Then I tried to attach again. Still no go. I then looked at the files. Hmmm.. they got updated (or downgraded depending on how you look at it). It seems the the GetVsDbg script will always check to see if it's the latest version and if not, update itself. Well, the version that it downloads is not for linux-arm and won't even run. However, there is a switch that can be set to NOT update. So in the script I can changed:

SkipDownloads=false to SkipDownloads=true

Then updated my vs2017u5 directory with the latest code again.

Now it works. I can attach the Visual Studio debugger to a running process on the linux box all native.

[RoySalisbury]

If anyone is interested, I got this working with the Bitvise SSH client (I like it better than Putty). I tried using the terminal client (stermc.exe), but it kept throwing an error with 'SetConsoleScreenBuffer'. However, the sexec.exe works perfect.

"adapter": "C:\Program Files (x86)\Bitvise SSH Client\sexec.exe", "adapterArgs": "pi@192.168.1.170 -pw=yourpassword -cmd=\"~/vsdbg/vsdbg --interpreter=vscode\"",

There are all kinds of ways to authenticate (password, keys, profiles, ect), so you don't have to hardcode the password like I did. I was just testing. All console output goes into the debug window.

Roy

[fabien-chevalley]

thank's for this feature, but I have a question. How can I launch remote debug and give root permission to my app ?

[gregg-miskelly]

You would want to login as root when launching vsdbg. For example if you are using ssh, pass root@yourTargetComputer as the credentials.

[fabien-chevalley]

@gregg-miskelly thank you !

[robertturner]

I'm also trying to debug a dotnet core app on a remote linux arm machine. The simple hello world app runs if I start it manually.

When I start the debug session in VS2017 (latest stable ver 15.5.3) it even does it's sort of "debug session" context jump, but then I get a dialog "The debug adapter exited unexpectedly". The debug adapter log output is:

1> DebugAdapterHost version: 15.5.11011.1 commit:fe222a7058cc72ec98f7fd365f34d79fa9a22d75
1> Starting 'c:\Rob\Downloads\plink.exe' with arguments '-i c:\users\nzrotur\key.ppk root@10.141.18.150 -batch -T ~/vsdbg/vsdbg --interpreter=vscode'
1> [DebugAdapter] --> C (initialize-1): {"command":"initialize","arguments":{"clientID":"visualstudio","adapterID":"coreclr","linesStartAt1":true,"columnsStartAt1":true,"pathFormat":"path","supportsVariableType":true,"supportsHandshakeRequest":true},"seq":1,"type":"request"}
1> [DebugAdapter] <--   R (initialize-1): {"seq":0,"type":"response","request_seq":1,"success":true,"command":"initialize","message":"","body":{"supportsConfigurationDoneRequest":true,"supportsFunctionBreakpoints":false,"supportsConditionalBreakpoints":true,"supportsEvaluateForHovers":true,"exceptionBreakpointFilters":[{"filter":"all","label":"All Exceptions","default":false},{"filter":"user-unhandled","label":"User-Unhandled Exceptions","default":true}],"supportsSetVariable":true,"supportsModulesRequest":true,"additionalModuleColumns":[{"attributeName":"vsLoadAddress","label":"Load Address","type":"string"},{"attributeName":"vsPreferredLoadAddress","label":"Preferred Load Address","type":"string"},{"attributeName":"vsModuleSize","label":"Module Size","type":"number"},{"attributeName":"vsLoadOrder","label":"Order","type":"number"},{"attributeName":"vsTimestampUTC","label":"Timestamp","type":"unixTimestampUTC"},{"attributeName":"vsIs64Bit","label":"64-bit","type":"boolean"},{"attributeName":"vsAppDomain","label":"AppDomain","type":"string"},{"attributeName":"vsAppDomainId","label":"AppDomainId","type":"number"}],"supportedChecksumAlgorithms":["MD5","SHA1","SHA256"],"supportsExceptionOptions":true,"supportsValueFormattingOptions":true,"supportsExceptionInfoRequest":true,"supportTerminateDebuggee":true,"supportsExceptionConditions":true,"supportsDebuggerProperties":true,"supportsSetExpression":true}}
1> [DebugAdapter] --> C (launch-2): {"command":"launch","arguments":{"noDebug":false,"name":".NET Core Launch","type":"coreclr","cwd":"~/rob","program":"~/rob/CoreConsoleDemo1","request":"launch"},"seq":2,"type":"request"}
1> [DebugAdapter] <--   C (handshake-1): {"seq":1,"type":"request","command":"handshake","arguments":{"value":"nOGlxr9w497R8aq5AG1Gf0unMa2hJSmDt9pfdkP9eyE="}}
1> [DebugAdapter] --> R (handshake-1): {"request_seq":1,"success":true,"command":"handshake","body":{"signature":"8120e5zh/XjZtAzrmsM41e32piDLz74Y9Iv90jBeCeKyo0="},"seq":3,"type":"response"}
1> [DebugAdapter] <--   E (output): {"seq":2,"type":"event","event":"output","body":{"category":"console","output":"-------------------------------------------------------------------\nYou may only use the Microsoft .NET Core Debugger (vsdbg) with\nVisual Studio Code, Visual Studio or Visual Studio for Mac software\nto help you develop and test your applications.\n-------------------------------------------------------------------\n"}}
1> [DebugAdapter] <--   R (launch-2): {"seq":3,"type":"response","request_seq":2,"success":true,"command":"launch"}
1> [DebugAdapter] <--   E (initialized): {"seq":4,"type":"event","event":"initialized","body":{}}
1> [DebugAdapter] --> C (setDebuggerProperty-4): {"command":"setDebuggerProperty","arguments":{"DisableJITOptimization":0},"seq":4,"type":"request"}
1> [DebugAdapter] <--   R (setDebuggerProperty-4): {"seq":5,"type":"response","request_seq":4,"success":true,"command":"setDebuggerProperty","message":"","body":{}}
1> [DebugAdapter] --> C (setDebuggerProperty-5): {"command":"setDebuggerProperty","arguments":{"InterpreterOptions":1},"seq":5,"type":"request"}
1> [DebugAdapter] <--   R (setDebuggerProperty-5): {"seq":6,"type":"response","request_seq":5,"success":true,"command":"setDebuggerProperty","message":"","body":{}}
1> [DebugAdapter] --> C (setDebuggerProperty-6): {"command":"setDebuggerProperty","arguments":{"JustMyCodeStepping":1},"seq":6,"type":"request"}
1> [DebugAdapter] <--   R (setDebuggerProperty-6): {"seq":7,"type":"response","request_seq":6,"success":true,"command":"setDebuggerProperty","message":"","body":{}}
1> [DebugAdapter] --> C (setDebuggerProperty-7): {"command":"setDebuggerProperty","arguments":{"StopOnExceptionCrossingManagedBoundary":0},"seq":7,"type":"request"}
1> [DebugAdapter] <--   R (setDebuggerProperty-7): {"seq":8,"type":"response","request_seq":7,"success":true,"command":"setDebuggerProperty","message":"","body":{}}
1> [DebugAdapter] --> C (setDebuggerProperty-8): {"command":"setDebuggerProperty","arguments":{"TraceSettings":"PropertySetting;WindowsBase;System.Diagnostics.PresentationTraceSources;AnimationSource=Off;PropertySetting;WindowsBase;System.Diagnostics.PresentationTraceSources;DataBindingSource=Warning;PropertySetting;WindowsBase;System.Diagnostics.PresentationTraceSources;DependencyPropertySource=Off;PropertySetting;WindowsBase;System.Diagnostics.PresentationTraceSources;DocumentsSource=Off;PropertySetting;WindowsBase;System.Diagnostics.PresentationTraceSources;FreezableSource=Off;PropertySetting;WindowsBase;System.Diagnostics.PresentationTraceSources;HwndHostSource=Off;PropertySetting;WindowsBase;System.Diagnostics.PresentationTraceSources;MarkupSource=Off;PropertySetting;WindowsBase;System.Diagnostics.PresentationTraceSources;NameScopeSource=Off;PropertySetting;WindowsBase;System.Diagnostics.PresentationTraceSources;ResourceDictionarySource=Off;PropertySetting;WindowsBase;System.Diagnostics.PresentationTraceSources;RoutedEventSource=Off;PropertySetting;WindowsBase;System.Diagnostics.PresentationTraceSources;NatvisDiagnostics=Off;"},"seq":8,"type":"request"}
1> [DebugAdapter] <--   R (setDebuggerProperty-8): {"seq":9,"type":"response","request_seq":8,"success":true,"command":"setDebuggerProperty","message":"","body":{}}
1> [DebugAdapter] --> C (setDebuggerProperty-9): {"command":"setDebuggerProperty","arguments":{"WarnIfNoUserCodeOnLaunch":1},"seq":9,"type":"request"}
1> [DebugAdapter] <--   R (setDebuggerProperty-9): {"seq":10,"type":"response","request_seq":9,"success":true,"command":"setDebuggerProperty","message":"","body":{}}
1> [DebugAdapter] --> C (setExceptionBreakpoints-10): {"command":"setExceptionBreakpoints","arguments":{"filters":[],"exceptionOptions":[{"path":[{"names":["CLR"]}],"breakMode":"userUnhandled"},{"path":[{"names":["CLR"]},{"names":["System.AppDomainUnloadedException","System.Threading.ThreadAbortException"]}],"breakMode":"unhandled"},{"path":[{"names":["CLR"]},{"names":["System.Windows.Markup.XamlParseException","System.Reflection.MissingMetadataException","System.Reflection.MissingRuntimeArtifactException"]}],"breakMode":"always"},{"path":[{"names":["MDA"]}],"breakMode":"unhandled"},{"path":[{"names":["MDA"]},{"names":["CallbackOnCollectedDelegate","ContextSwitchDeadlock","DateTimeInvalidLocalFormat","DisconnectedContext","FatalExecutionEngineError","InvalidFunctionPointerInDelegate","InvalidMemberDeclaration","InvalidVariant","LoaderLock","NonComVisibleBaseClass","PInvokeStackImbalance","RaceOnRCWCleanup","Reentrancy"]}],"breakMode":"always"}]},"seq":10,"type":"request"}
1> [DebugAdapter] <--   R (setExceptionBreakpoints-10): {"seq":11,"type":"response","request_seq":10,"success":true,"command":"setExceptionBreakpoints"}
1> [DebugAdapter] --> C (configurationDone-11): {"command":"configurationDone","arguments":{},"seq":11,"type":"request"}
1> [DebugAdapter] <--   E (output): {"seq":12,"type":"event","event":"output","body":{"category":"telemetry","output":"VS/Diagnostics/Debugger/vsdbg/ProcessCreate","data":{"VS.Diagnostics.Debugger.vsdbg.LinuxDistroVersion":"Linux version 4.6.0-rt1-xilinx-22210-g9b02b83 (ubqt@ubqt) (gcc version 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) ) #4 SMP PREEMPT RT Thu Jun 1 13:59:22 NZST 2017","VS.Diagnostics.Debugger.vsdbg.KernelRelease":"4.6.0-rt1-xilinx-22210-g9b02b83","VS.Diagnostics.Debugger.vsdbg.OSFamily":"Linux","VS.Diagnostics.Debugger.vsdbg.Version":"15.6.11121.1 commit:93a9297b4a8aa3937d73947014b85b6914bec9ca"}}}
1> [DebugAdapter] <--   E (process): {"seq":13,"type":"event","event":"process","body":{"name":"~/rob/CoreConsoleDemo1","systemProcessId":1372,"startMethod":"launch"}}
1> [DebugAdapter] <--   E (output): {"seq":14,"type":"event","event":"output","body":{"category":"telemetry","output":"VS/Diagnostics/Debugger/vsdbg/Launch","data":{"VS.Diagnostics.Debugger.vsdbg.AdapterId":"coreclr","VS.Diagnostics.Debugger.vsdbg.Launch.Duration":660,"VS.Diagnostics.Debugger.vsdbg.VisualizerFileUsed":false,"VS.Diagnostics.Debugger.vsdbg.LinuxDistroVersion":"Linux version 4.6.0-rt1-xilinx-22210-g9b02b83 (ubqt@ubqt) (gcc version 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) ) #4 SMP PREEMPT RT Thu Jun 1 13:59:22 NZST 2017","VS.Diagnostics.Debugger.vsdbg.KernelRelease":"4.6.0-rt1-xilinx-22210-g9b02b83","VS.Diagnostics.Debugger.vsdbg.OSFamily":"Linux","VS.Diagnostics.Debugger.vsdbg.SourceFileMappings":0,"VS.Diagnostics.Debugger.vsdbg.Version":"15.6.11121.1 commit:93a9297b4a8aa3937d73947014b85b6914bec9ca"}}}
1> [DebugAdapter] <--   R (configurationDone-11): {"seq":15,"type":"response","request_seq":11,"success":true,"command":"configurationDone"}
1> ERROR: The debug adapter exited unexpectedly.

My launch file is:

{
  "version": "0.2.0",
  "adapter": "c:\\Rob\\Downloads\\plink.exe",
  "adapterArgs": "-i c:\\users\\nzrotur\\key.ppk root@10.141.18.150 -batch -T ~/vsdbg/vsdbg --interpreter=vscode",
  "languageMappings": {
    "C#": {
      "languageId": "3F5162F8-07C6-11D3-9053-00C04FA302A1",
      "extensions": [ "*" ]
    }
  },
  "exceptionCategoryMappings": {
    "CLR": "449EC4CC-30D2-4032-9256-EE18EB41B62B",
    "MDA": "6ECE07A9-0EDE-45C4-8296-818D8FC401D4"
  },
  "configurations": [
    {
      "name": ".NET Core Launch",
      "type": "coreclr",
      "cwd": "~/rob",
      "program": "~/rob/CoreConsoleDemo1",
      "request": "launch"

    }
  ]
}

Am I missing something? Those with eagle-eyes may have noticed from the log that we're running a custom kernel, and our distro is a custom yocto build, but I'm mostly sure the dotnet core deps are there. I originally posted this in the wrong forum (no ARM-specific) so reposted.

[chuckries]

@robertturner Please see the comments from @RoySalisbury here. When launching from Visual Studio, we will attempt to download the latest stable version of vsdbg. Since the arm work is still in preview, it will not be downloaded by this script. This means that you end up trying to use an x64 version of vsdbg on linux-arm, which will not work.

There are instructions here on how to manually download the correct linux-arm version of vsdbg. @RoySalisbury also provided instructions on how to coerce the vsdbg download script to not downgrade the debugger in the case of automatic deploy.

Please let us know if you have additional questions.

[robertturner]

@chuckries have downloaded the arm beta vsdbg and it runs. This is evident in the VS2017 debug log as the two chat a bit first and then it crashes. Is the auto-download still a problem then?

[robertturner]

I ran vsdbg through strace to get a better idea of what it was doing when it crashed, but nothing obvious jumps out. strace log: stracedump.txt

[robertturner]

Any more thoughts on how I might debug this?

[chuckries]

@robertturner is it at all possible for me to get an image of the linux distro you are working with?

[chuckries]

@robertturner another idea is to run vsdbg under gdb to see if it captures any error. I am not 100% sure if this will produce useful output, but it is a start.

In your launch.json, replace

 "adapterArgs": "-i c:\\users\\nzrotur\\key.ppk root@10.141.18.150 -batch -T ~/vsdbg/vsdbg --interpreter=vscode",

with

 "adapterArgs": "-i c:\\users\\nzrotur\\key.ppk root@10.141.18.150 -batch -T gdb -ex run --args ~/vsdbg/vsdbg --interpreter=vscode",

and see if this produces any interesting output.

[chuckries]

The best option is probably to collect a core dump of the process and let me take a look at it (I am unsure if this will work for arm, but if we can collect the dump I can investigate from there).

To enable core dumps from a bash shell, run ulimit -c unlimited. Now any program run from this shell that crashes will create a core dump. Amend your launch options to the following:

"adapterArgs": "-i c:\\users\\nzrotur\\key.ppk root@10.141.18.150 -batch -T ulimit -c unlimited && ~/vsdbg/vsdbg --interpreter=vscode",

Repro the crash and collect the core dump, it should be the file core in your home directory. Email me at chuckr@microsoft.com so we can discuss a private means to share the file, as you will not want to upload it here. I will take a look at it from there.

[skwinnik]

Hello! Has anyone tried to debug an ASP.NET Core app on RPi 3? I'm going to try this within a couple of days, would be great to hear about any positive experience though.

[gregg-miskelly]

Yes, ASP.NET Core + RPi 3 is one of the things we tested.

[robertturner]

Hi guys, thanks for the support. I'll be trying your suggestions in the coming weeks. Cheers

[dknippel]

Hi all,

I have been able to successfully attach from VS2017 to a simple HelloWorld .NET Core console app process running on a RPi3 per @RoySalisbury instructions.

However, I have not been able to get any breakpoints [set within my VS2017 IDE] to hit. And if I try to set a new breakpoint after attaching to said process I get a fatal error stating "Could not set breakpoint". Said process is "killed" on the RPi3 and my VS2017 debugging session is ended.

The only thing I wasn't able to do exactly per @RoySalisbury instructions was to "Install .NET Core SDK v2.2.0 preview locally (IDE computer)". Could someone provide details on how to specifically get the .NET Core SDK v2.2.0 preview/beta?

Thanks

[chuckries]

@dknippel The latest SDK that you'll want to install is here. These are listed as 2.1, so I'm not exactly sure what's going on with versioning, but these are the latest.

How are you building/deploying the app to the RPi3? What .NET Core Runtime version are you running on the RPi3?

[dknippel]

@chuckries , thank you for your quick reply. Attached below are

1. "Failed to set break point" dialogue
2. SDK version before install
3. SDK version after install (for verification)
4. Debug general options in VS2017

RE: your questions:

1. I am building a self-containing app and deploying onto the RPi3 via SSH and the pscp.exe util from Putty
2. The .NET Core Runtime on the RPi3 is: Microsoft .NET Core Shared Framework Host --> Version: 2.0.4