I came across on following problem. When I run msbuild to buid solution (not project) within pre build event in visual studio I see that it prints messages after execution (not immediately). Such behaviour creates illusion that msbuild hangs. Is there any way to force it to print messages immediately?
Related
We have our C++ project codebase developed in VC++ IDE. I can compile and run the same.
The executable covers a lot of scenarios and flow executions. Is there a way by which during a flow execution - the VC++ Studio can tell us which are the methods the flow entered or trace the flow.
Assume that 3 functions are called out of 10 during a flow execution. Can we get a trace stating the 3 functions entered during execution in order?
In Visual Studio 2015(+), there is a 'Call Stack' window that can be used to do exactly what you are describing. With that being said, it still does require you to place at least one break-point somewhere. See this post for more information.
So what you can do is launch the application, then from Visual Studio click Debug > Windows > Call Stack. Unfortunately this window will remain empty until you designate a break-point somewhere in your script - somewhat frustrating. However the Call Stack window does provide more information than simply placing breakpoints in code and performing manual tracing.
Hopefully this information will help your project!
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).
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 :(
I have an .exe that crashes in release mode. I want to debug where the crash occurs.
How can I use VC++ to debug a crash in a release-mode .exe?
You can run Visual Studio and attach it to a process to debug.
Also check through the Windows Event Viewer (an often overlooked source of information) for any exceptions that Windows may have caught.
Firstly if you have access to the code you can open the workspace in visual studion and debug it by pressing F5 button.
Secondly go through the steps that leads to the crash. At that point of time check the location pointed to by the call stack.
This will give you indication on the funciton or line where crash is occuring.
We are assuming this application was written in VC++. How often are you able to reproduce this issue. Is it like everytime you can reproduce it or how is it.
I have a question regarding Visual C++. While executing a Visual c++ project file, the application runs and along with that, a command window gets opened. It normally disappears as soon as the application running is done. I am not sure if that command window could be avoided when the application runs.
Thanks,
Krishna
Win32 executables must be either a command line application or a GUI application.
If your EXE is a command line application and it is executed from a command line then no extra window is created.
If your EXE is a command line application and it is executed from a GUI application then a new console window will be created for it.
If your EXE is a GUI application then it's up to you to create whatever window(s) you want.
Check how your application is being compiled and then make the right decision for your app. In Visual Studio follow these steps:
In Solution Explorer right-click on the VC++ project node and choose Properties
Navigate to: Configuration Properties / Linker / System
Check the value of the "SubSystem" property
Two of the SubSystem options are Windows and Console, and these describe the two settings I mention earlier.
More information about this GUI vs. Command Line behavior is available on these links:
How do I write a program that can be run either as a console or a GUI application?
Program both as Console and GUI