Running .Net application on visual studio code in MacBook pro - c#

I am doing C# programming in Visual Studio Code in MacBook Pro, so whenever I run the application, a dotnet process is left in the memory, when I open the Activity Monitor the memory is not disposed, and the CPU is running at 100% even after the debugging is stopped. Is something wrong with my code or is there anything else that I should be doing while writing c# code in Mac OS. Please let me know, right now after every run I am opening activity monitor and force quitting the process.

You just need to have .Net Core and C# extension installed.
The High CPU consumption is often caused by an issue in an extension.
You can open the Process Explorer using Help>Open Process Explorer to view the list of running VS Code processes running in real-time where you'll find what is causing High CPU consumption where extensions are executed by the Extension Host process.
If the High CPU consumption isn't caused by VS Code then it's probably your code and you'll have to optimize it.
You can check the Performance Issues Wiki for more details here

Related

Profiling managedCuda in Nsight or Visual Profiler

I'm trying to profile an CUDA-application written in C# with managedCuda using either Nsight Visual Studio Edition or Visual Profiler. Both profilers work well with a plain C++ CUDA app. To test the profilers with managedCuda I want to profile the project "vectorAdd" in ManagedCudaSamples.
First I tried to use Nvidia Nsight Visual Studio Edition 5.0 integrated in VS 2013. I use the x64 Debug configuration. If I try to launch the app in "Application Control" in Nsight Performance Analysis I get an error message:
Analysis Session - Start Application
Unable to launch 64-bit managed application '...\ManagedCudaSamples\vectorAdd\bin\x64\Debug\vectorAdd.exe'.
Additionally I tried to use Nvidia Visual Profiler 7.5 for profiling the same application. On running vectorAdd.exe nvprof console shows the following output:
==2944== NVPROF is profiling process 2944, command: ...\ManagedCudaSamples\vectorAdd\bin\x64\Debug\vectorAdd.exe
==2944== Warning: Some profiling data are not recorded. Make sure cudaProfilerStop() or cuProfilerStop() is called before application exit to flush profile data.
==2944== Generated result file: ...\nvvp_workspace\.metadata\.plugins\com.nvidia.viper\launch\7\api_2944.log
I'm new to CUDA and would be thankful for any advice how to profile managedCuda applications.
You need to call CudaContext.ProfilerStop() just before you exit the application (or destroy the context) in order to flush the collected data to the profiler. The managedCuda samples don't include this call why the profiler doesn't see the collected info. This explains the second error you get.
And regarding the first error:
In the release notes of Nsight 5.0 you can find a known issue:
Managed applications built with the AnyCpu configuration are not supported. The target application must be built using either the Win32 or x64 configurations.
The VS-project for vectorAdd is always set to AnyCPU, regardless what the solution platform is, see the configuration manager of the managedCuda samples-solution to change that.

.NET application memory usage Visual Studio 2005

I've got a C# application running on Windows CE smart device and I recently added a new graphing option which results in a "OutOfMemory" exception after running for a few hours. How do I find what is going wrong? The code looks fine, its based on one of the previous graphing options that runs for weeks without a problem.
I've tried the Debug > Windows > Memory options in VS 2005, but they all give the message "Unavailable when debuggee is running." I've also tried attaching to the process using the remote debugging tools (specifically the Windows CE Remote Process Viewer), but there's not enough functionality to see what I'm looking for.
Are there tools in VS 2005 to analyse either a remote C# app or one running locally (ie. Win32)?
a) see Memory profiler for .NET Compact Framework
b) see CF remote performance and ... viewer: http://www.microsoft.com/en-us/download/details.aspx?id=13442&751be11f-ede8-5a0c-058c-2ee190a24fa6=True
looks like you have a memory leak in code.

Running in Windows CE from debugger causing eventual out-of-memory crash

I'm building a C# application for a Windows CE machine. The CE machine is talking to a serial device, and I'm using the SerialPort class.
When I run the project from Visual Studio by right-clicking and deploying, it will run fine for fifteen to twenty minutes before slowing down and eventually crashing from running out of memory, but when I deploy the solution and run it locally from the CE machine (navigate to the folder, open the exe), it runs fine for a whole day, which is as long as I've tried it.
I don't know why. I've tried building for release and debug, and it makes no difference. The only thing that seems to is where it's run from. I've also tried profiling the application using dotTrace, and it appears that it's being deployed to the CE machine before profiling starts; in any case, I can't reproduce the bug while the profiler is running.
I've also tried packaging the code that's handling the serial stream into a DLL, thinking that maybe Visual Studio was messing with something inside of it while debugging, but that didn't change anything, either.
Is there anything I can do to increase the stability of running from the IDE? I like being able to debug with it, but the inconsistency makes me feel like I might be doing something wrong.
As far as we've been able to tell, the problem I described is related to the SerialPort class from System.IO.Ports. I think it might be related to some of the problems described here; the managed SerialPort class calls into WinAPI code that's unmanaged inside of a loop, something goes wrong, and that unmanaged memory is lost.

Deploy to Memory Card When Debugging

I'm trying to run and debug a C# winforms app on a mobile device running Windows CE 5. It's only got a tiny "hard drive" memory but I've stuck a memory card in it with plenty of space. Unfortunately when I hit debug in Visual Studio it deploys the app to "program files" on the main hard drive memory and it doesn't fit.
Is there a way to make Visual Studio deploy the app to the memory card when debugging rather than using the main drive? I can't find any option like this. I'm using VS 2008.
Thanks a lot
Mark
See the answer to this question.

C# WinForms App won't run on Win7 after Building

I have a program that I built that reads and writes files. I built it in Release mode, then tried to run the exe on Win7. At first, with troubleshooting on, Windows simply told me the application closed and it was looking for a solution. After a few seconds, the dialog would disappear and show nothing more.
So with some significant effort I got the debugger attached to the process, but it was only showing me disassembly, which tells me that the error taking place wasn't in my application code, but in the framework somewhere.
The strange thing is that when I let the debugger attach, then press "stop" in VS, and exit the debugger, the program actually runs at that point!
So now I'm stumped. I have an application that builds, that seems to be having a permission error when I run it, but if I let the debugger attach then close it, it runs, and there's no Exception to really look at.
How I troubleshoot this issue?
Edit: Responding to Merlyn:
It's a custom app written from scratch in c#. The only dependency it has outside of core .NET namespaces is the Ionic.Zip DLL.
Visual Studio 2008 (Writing in C# 3.5)
Windows 7 - Home Premium, v6.1 build 7600
CPU - x64 quad core
CPU are you compiling under: Any CPU
I haven't tried it on another machine or a different version of VS.
Edit: I was able to try the compiled version on another win7 computer, and it worked without issue, so it looks like a security (?) issue on my computer only.
Try it in the debugger with Just My Code disabled and Native Code enabled, then check the call stack.
Also, what happens if you run it directly in Visual Studio?
Uncheck Enable Visual Studio Hosting Process in Project Properties and see whether it still works in VS.
I'd suggest sending the issue to Microsoft support. Especially with the data given here, you will have an easy time convincing them it's their problem. You might need an MSDN subscription for that.

Categories