The cluster debugging option is removed from Visual studio 2012.
So is there any way to debug MPI apps in VS2012 ?
Visual studio 2012 and later versions do not support MPI debugging. However there is a workaround:
Start debugging by specifying mpiexec.exe as your command and related parameters and the name of your executable as command arguments:
Command-> mpiexec.exe
CommandArguments-> -n 2 myapp.exe
When the execution starts, use Debug->Attach to process... to attach the debugger to one your processes. Sometimes I add a simple press any key to continue logic to my app, just to pause the program until I finish this attaching process.
In order to ease tings you can use an extension called Reattach that lets you attach to the last processed you attached with one button click.
One problem with this workaround is that you cannot select which MPI process you attach :(
Related
I'm using Visual Studio 2019 to develop a .NET Core 3 application which runs on embedded Linux. I am able to build the code in Visual Studio 2019. If I copy the binaries manually to the Linux machine and then start the application running there then I am able to attach the Visual Studio debugger to the remote process over SSH in Linux and debug the application. This does work, but it's tedious to deploy it, start it and attach the debugger manually for each debug session. I do have a script in Visual Studio Code which works, but I want to use Visual Studio Professional.
I'm trying to write a Visual Studio Extension so that I can press a key in Visual Studio to have the application built, deployed, started and then connected to the debugger. I would then share the extension with my team. It's very nearly working, except for attaching the debugger.
In the extension I am able to list the processes running in the Linux machine and select my application using this code:
EnvDTE100.Debugger5 debugger = (EnvDTE100.Debugger5)dte.Debugger;
EnvDTE80.Transport transport = debugger.Transports.Item("SSH");
EnvDTE80.Engine engine = transport.Engines.Item("Managed (.NET Core for Unix)");
EnvDTE80.Process2 process = (EnvDTE80.Process2)debugger.GetProcesses(transport, "192.168.11.1").Item("app");
process.Attach2(debugger);
There are two problems:
The call to GetProcesses() opens a dialog where I need to enter the Linux username and press enter, how can I specify the username in code to avoid the dialog appearing?
Even though the selected process looks like the right one (process.ProcessID matches what I see in Linux if I run the ps command), I get an exception when I call Attach2(). The exception message is "Exception from HRESULT: 0x8971001E"
I feel like I'm really close to getting this to work, any suggestions for how to finish it?
I also solved the second problem by changing the parameter passed to Attach2() from debugger to engine, as shown below:
EnvDTE100.Debugger5 debugger = (EnvDTE100.Debugger5)dte.Debugger;
EnvDTE80.Transport transport = debugger.Transports.Item("SSH");
EnvDTE80.Engine engine = transport.Engines.Item("Managed (.NET Core for Unix)");
EnvDTE80.Process2 process = (EnvDTE80.Process2)debugger.GetProcesses(transport, "root#192.168.11.1").Item("app");
process.Attach2(engine);
I found out how to add the user Name, but not the Password:
In GetProcess(), set transportQualifier to $"{userName}#{hostName}".
The 1st time the Window will still Pop up and ask for the Password.
But after that VisualStudio has stored the connection including the password.
I have a C++ application (it's built using Qt 5.8 library and works with PostgreSQL 9.5 database in case it's relevant). The application is build by MSVC 2012 compiler, is 64-bit application and both debug and release versions run normally on their own and under cdb debugger.
When I try to profile the running application by Visual Studio instrument (Analyze -> Profiler -> Attach), it seemingly hangs as soon as it tries to do something meaningful: simply resizing a window or clicking on checkboxes works, but any attempt to compute new values and write them to database never succeeds, as if control flow didn't return from some call.
When I stop the profiling, Studio marks as a "hot path" sequence of calls RtlWalkFrameChain->RtlpWalkFrameChain->RtlpLookupFunctionEntryForStackWalks->RtlLookupFunctionTable->RtlAcquireSRWLockShared.
RtlpWalkFrameChain has the biggest "exclusive samples" count.
Trying to filter data to exclude initial several seconds of run (until the apparent freeze) results in "No Call Tree Data Is Available" message.
I didn't manage to find any article or post with a similar problem.
The project is build in Qt Creator (I don't have a project file Studio would understand, so I can't run "normal" performance analysis).
OS is Windows 7, exact version of Visual Studio is 11.0.61219.00 Update 5.
Any idea on the subject would be welcome.
Upd: When I try to profile the application with Luke Stackwalker profiler, it aborts with the message ERROR: StackWalk64-Endless-Callstack!. The only relevant comment about the message I found is this Stackoverflow question. When I run application under cdb debugger and then try to profile it with Luke Stackwalker, the error message is the same, but subsequent pause in the debugger shows the proper (or at least believable) stack for all threads. For the working thread debugger points to a line of code inside system library and doesn't advance no matter what I do (once again, without profiling attempts the application runs normally, debugger or not).
I am working on this node.js application using Visual Studio Code IDE. Everytime I run this application, it is attaching a debugger (which takes around 2-5 seconds) and then executing the application.
So, my issue is everytime if I modify some code (or a simple variable name) and execute the program, it takes this much time to see the output even though I haven't set any breakpoints.
Need help in disabling the debugger in Visual Studio Code IDE for node applications development. I can't find anything helpful on net :( .
There is workbench.action.debug.run which is bound to cmd+f5 / ctrl+f5 by default.
You can find it in the command palette under the name "Debug: Start without Debugging"
Inside the VsCode terminal, I've switched the terminal to zsh instead of the JS Debug Console and it fixed it:
Screenshot of the terminal's dropdown
You can just switch from "Javascript Debug Terminal" to "powershell" (command terminal). it doesn't attach the debugger again
consider passing the option below on settings.json
"debug.javascript.autoAttachFilter": "onlyWithFlag"
with this option, you will always need to pass ---inspect option to start debugging mode. otherwise, it will always start normal running mode.
I recently installed NodeJS Tools for Visual Studio which touts support for Node environments in VS. Notably, it has the ability to set debug breakpoints from the IDE.
It's unclear to me if it is possible to set breakpoints when debugging Gulp tasks. The Task Runner has the ability to detect the Gulp task and output console.log statements to a window, but I haven't found a better means of debugging.
I found this post from a while back: How can I debug gulpfile.js when running it with Visual Studio Task Runner Explorer? However, this post doesn't involve NodeJS Tools for VS. So, I'm re-asking the question to take that plugin into consideration.
You can. Right-click the Node project, select Properties, and configure your app as follows (in the image, default is the Gulp task that you want to run).
Alternative method:
In a terminal, and in the directory where the gulpfile is, run node --debug=44331 --debug-brk ../node_modules/gulp/bin/gulp.js default. In my case, default is the task name I want to run/debug.
In Visual Studio, go to Debug | Attach to Process. Select Node.js Remote debugging as Transport, and in the qualifier select localhost:44331. Press enter and you should see the Node process appear in the list. Click Attach.
Voila, the breakpoints are hit.
A couple of things to notice:
If you get something like Unable to attach to process. Error 0x80004005 use a different port. I couldn't get it to work with port 5858.
It may not work the first time you attach to the process (see my previous screenshot how I got ECANCELED?). Try again.
After I installed Windows 8 perfectly legit statement like this doesn't work anymore:
#if DEBUG
Debugger.Launch();
#endif
Service starts ignoring that thing.
Yes, I am building the project in a debug mode.
if I change that to a Debugger.Break() - the service just fails, and still there's no dialog for attaching a debugger.
The secret lies in changing the registry key for the Visual Studio JIT debugger via the following:
reg add "HKCR\AppID\{E62A7A31-6025-408E-87F6-81AEB0DC9347}" /v AppIDFlags /t REG_DWORD /d 8 /f
Before making this change the value on my machine was 0x28. The above changes it to 0x8. In essence it removes the 0x20 flag.
If you search the Microsoft include files (WTypesbase.h) then you find the following:
#define APPIDREGFLAGS_IUSERVER_ACTIVATE_IN_CLIENT_SESSION_ONLY 0x20
Once you make this change then the JIT debugging window is displayed again. I believe that all of this relates to various session 0 security changes made by Microsoft.
Sourced from this post:
http://forums.arcgis.com/threads/69842-Debugging-your-SOE-on-Windows-8
Debugger.Launch would launch an application with a visual GUI. By default services do not interact with a desktop and thus anything they do cannot be "seen".
Support for interacting with the desktop has slowly been removed from Windows services ("Interact with the desktop" option has been removed from some Server versions for example). I would imagine they've continued this trend.
Windows Services by nature are not GUI applications, they can run before and after a user logs into a desktop and thus cannot show a GUI all the time. It's not generally a good idea to depend on an ability to have a GUI in a Service.
If what you want to do is debug a service, I suggest running it as a regular application so that you can do things like Launch and Debug. Shameless plug: you can see Developing Windows Services in Visual Studio for a way to write a service that supports that.
Is this a Windows Store app or a desktop app?
Try right-clicking on your project (the C# executable project if that's what you have) and selecting "Properties". Then in the left sidebar of options, click "Debug". In the "Start Action" section, check the box for "Do not launch, but debug my code when it starts".
Now you can hit F5 and run Visual Studio with breakpoints in your code, and it will sit and wait for you to fire up the process. Then run your application (outside of Visual Studio), and Visual Studio will attach the debugger.