I'm running a .Net 7 application on a Raspberry Pi running the .Net 7 runtime and SDK.
The application runs fine, but as soon as I attached the remote debugger in Visual Studio 2022 I get a segmentation fault, with no indication of what caused it. I have increased the logging to the maximum.
The only error I receive is on the Pi itself 'Segmentation Fault' and an immediate exit with Visual Studio reporting nothing.
To fault find I've run and attached the debugger to a new test application which rules out the Pi and my PC, so I know its my application, I've also tried it on another Pi.
I then stripped back the code in my application to try and see what is going on and rule out hardware, ethernet comms and serial comms. I find that if I disable my Hosted Services in my Startup.cs file, that the debugger does attach to the application, but this is catching issues because things aren't initialised, so doesn't really load fully.
My application communicates with a sensor via serial comms, uses the GPIO on the Pi and uses SignalR to stream data to a front end. I don't think these are causing the issues, but I don't know for sure.
Are there any tools, or logs I can look at to try and solve this issue?
Resolved by reverting to .Net 6 as the workaround stated in this issue.
https://github.com/dotnet/runtime/issues/81921
.Net 7 and 32bit Linux-arm aren't working for remote debugging.
Related
I have a dotnet app, which I'm running on a Raspberry PI. I don't have a way to run full-fledged IDE on it, like Visual Studio or Rider. I run it on Raspberry PI with dotnet run. Since the app depends on some Raspberry PI hardware specifics, I cannot run it anywhere else.
I noticed that sometimes the app gets stuck somehow and the logs are no longer being generated. How can I find out which place in my code is the place where runtime is stuck? I don't see any exceptions. I can't even exit the app with SIGINT. I have to kill -9 it.
You can publish your application in Debug configuration and use remote debugging via SSH (first of all you need to configure SSH on raspberry). More information here: https://learn.microsoft.com/en-us/visualstudio/debugger/remote-debugging-dotnet-core-linux-with-ssh?view=vs-2022
I've written a Hello World console app in .Net Core 2.0 using VS 2017 and deployed the Debug build to a Raspberry Pi 3 running Windows 10 IoT. I can execute the app remotely via PowerShell and everything seems fine.
Having installed the Visual Studio 2017 Remote Debugging tools, I'm now trying to hook up the Remote Debugger so as I can step through my code on the Pi and I'm running into problems.
When I try to "Attach to process" from the Debug menu in Visual Studio and enter the IP and port number supplied by the IoT device portal I get the following error:
Unable to connect to the Microsoft Visual Studio Remote Debugger named '192.168.1.139:8116'. Connection request was rejected by the remote debugger. Ensure that the remote debugger is running in 'Windows Authentication' mode.
The following screenshot of the IoT Device Portal shows both the IP and Port for Remote Debug and the fact that my app (echo.exe) is running:
I've tried running the remote debugger both with and without the "Run as DefaultAccount" option checked, but this seems to make no difference.
I've also checked the firewall settings on my dev PC to ensure that it is not blocking traffic (I am connecting over the Private network)
Although the error message warns about Windows Authentication Mode, I can find no such setting for the remote debugger. Any help in getting the Remote Debugger attached and operational would be gratefully received.
You may need to select the connection type to "Remote" instead of "Default".
It works for me. You can have a try and feel free let me know if there is any problem.
One thing that I think it could help is when deploying the app to the Remote Machine and you are presented the ‘Remote Connections’ dialog you can choose there what type of authentication you want. One of the options is Windows Authentication. Try deploying and running the app like that and then the Remote Debugger should work.
In your VS Studio Project Properties -> Debug Tab -> Authentication Mode: Window Authentication
I'm getting this error message when I run my UWP (Windows 10) application with the target set to "Device" (using my Windows Phone).
It says "Deploying" and suddenly fails. Usually, VS crashes and restarts. I have just installed Windows 10 and Visual Studio 2015 Update 3.
What can I do to fix it? I cannot run my app on my phone.
I finally discovered what was wrong!
It was due to a "bad" USB 3.0 connection.
I was connecting using a USB 3.0 hub. It seems the connections using my hub are somewhat unstable. I solved my issue connecting my Lumia directly to one of the USB ports the come directly from the motherboard.
Now, it works flawlessly!
I'm trying to debug my C#-mono program on a Pi 3 using the latest MonoRemoteDebugger (1.0.10).
The program compiles on both the build machine (a windows 10 64 bit laptop) as well as on the target (Pi 3). The binary also runs on the target machine.
But when i try to remote debug using Visual studio 2015 Community with the MonoRemoteDebug extention it fails.
The debug server that runs on the target machine is found by the extention client.
When i select the server and press connect then it connects.
But when it tries to start the binary it fails, it returns with the message that the .exe cannot be found.
It seems that is tries to find it in the directory of the development machine (C:\users\user\projects\project\Program.exe).
I have followed this tutorial:
https://mmkaram.wordpress.com/2015/04/18/run-and-debug-c-net-on-a-raspberry-pi/
and also read the following post Mono remote debugging from Visual Studio
But i can't seem to get it to work, can anyone help me?
I would suggest you to use Xamarin Studio.
Remote-Debugging from Windows to Linux (for me on a Beaglebone) works without any problems.
https://store.xamarin.com/account/my/subscription/downloads#all-versions
https://eladnava.com/debug-remote-mono-apps-via-xamarin-studio/
I also tried to get the debugging running from within VS. It is "possible", but only very basic and awkward to use.
Xamarin Studio is also free and fully compatible to the VS Solutions. So if you want you can use VS to write your code and then load the solution in Xamarin Studio to do your debugging.
I am working on a WPF application.
Which is running fine with "Any CPU" as Active solution platform, but when it is changed to "x86" application starts but stoping without showing up any form or error message.
Application neither throws any exception nor logging any error in event log.
I am running this application on .NET 4.0 framework and Windows 7 64 bit OS.
appreciate your help to solve this issue.
Thanks,
maxk
First off, it's strange that you don't get any error messages. Not even when you launch the built application without debugger?
The best answer anyone can give based on the information provided, is to do some trial and error debugging:
1) Create a new empty project, set it to x86, see if it runs. If not, there is some serious problems with your machine setup, you'll probably have to reinstall.
2) In your own project, if you have any external references start removing them one by one and see if your app starts to run. Maybe a referenced dll is causing havoc in 32-bit mode.
3) Start commenting out blocks of code to see if your app starts to run then. I've found out that having errors in Window_Loaded methods (especially while debugging) can cause problems - exceptions not being handled, application crashing etc.
4) Could be that you have a bad Visual Studio plugin (I assume you are using VS and problems are occuring on your development machine). Try running the app without debugging...
5) Create a virtual machine and try your app in there, if it works there, then your machine is somehow "corrupted"..
PS! Just for your information, because you are running a 64-bit OS, then the Any CPU setting causes your app to be 64-bit. Forcing it to be 32-bit can cause problems if you are using badly written native dlls (although it's usually the other way round - problems occuring when going to 64-bit from 32-bit).