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.
Related
when it's installing C# dependencies Visual Studio Code (powered by OmniSharp), I receive these message:
[WARNING]: x86 Windows is not currently supported by the .NET Core debugger. Debugging will not be available.
[ERROR]: C# Extension failed to install the debugger package.
I test new and older version of this extension, but it doesn't work.dotnet-sdk-3.1.419-win-x86
My system is win7 sp1 .x86.
I installed dotnet-sdk-6.0.300-win-x86 and dotnet-sdk-3.1.419-win-x86.
Thanks
Unfortunately it's not supported:
[https://github.com/OmniSharp/omnisharp-vscode/issues/844][1]
Unfortunately due the low usage of x86 Windows operating systems and many competing priorities, we are unable to fund adding x86 debugging support at this time. The C# extension will of course continue to function as an editor on x86 Windows.
We recommend anyone looking for .NET debugging on x86 Windows to use Visual Studio instead. See https://www.visualstudio.com/downloads/ for more information.
[1]: https://github.com/OmniSharp/omnisharp-vscode/issues/844
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.
I have a .NET 3.5 (C#) application, but interestingly it does not run on Windows XP. I have checked .NET Framework 2.0 SP2, 3.0 SP2, 3.5 SP1 are installed. When I run the application, no error message pops up. It just does not run. What could I try out?
this is may be because you have build this application on 64 bit machine please try to compile it over 32 bit machine and re run
You could install WinDbg (it has the advantage of being quite light, not too invasive, not like a full Visual Studio install), and run your .EXE from its console. WinDbg will break on the first exception. You will be then able to dig out further using something like SOS (WinDbg extension for managed .NET programs).
If your application requires the full ".Net Framework 3.5" make sure so it isn't the ".Net Framework 3.5 Client Profile" that is installed.
This have fooled me more than once...
Check if you have "appname.exe.config" file next to your app, or, in some cases, it have helped moving app in different drive/folder.
Folder path containing some language specific symbols might allso cause some compatability issues or runtime errors on some systems.
Have you copied all necessary DLL files with the EXE file? Except those already included in the .NET framework, of course.
If so, you should check the event log to see If you can find any hints. You can also use the PDB files in a test period bexcause this will provide more info to the exception and event log.
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.
I have the source code for a C# project (which wasn't written by me) which I run on one of our servers.
There is a particular part of this program (a menu option) which occasionally fails silently and I can't figure out why from just looking at the source. (The part of the program that fails requires various features that are not on my development machine, so I can't test it on my own machine).
I would like to debug this program and in particular step through the code line by line. Since the server is outside our firewall, remote debugging feature will not work.
Is there any alternative other than installing Visual Studio on the server, ie are there any runtime debuggers that will show the C# source code and allow you to set breakpoints etc?
The project was written in VS 2008 and targets Framework 2.0.
You should be able to use DbgClr for a framework 2.0 app. It is a standalone graphical debugger that comes with the SDK. You will need to ensure that the PDB files, that matches the running build of the application, are available to the debugger.
That being said, if you have any option to punch a hole in the firewall, so you can use remote debugging, that would probably be the easiest way to go.
Of course, it would be best practice to setup your local environment so you can reproduce the bug and debug locally; but I can understand if there are reasons that might make this unfeasible.
Another option is to use WinDbg with the SOS extensions. It's an extremely light weight debugger that doesn't even require the .Net framework to be installed. It leaves much to be desired in the way of UI and has a steep learning curve. But once you get the hang of WinDbg it's an amazingly powerful debugging tool.