Visual studio profiler shows that "No code was running during the selected time range", even when there was clearly code running (the time range was the entire execution time of the program). I have tried to reinstall C++ profiling tools but this issue is still here.
Related
I am migrating a Visual Studio C++ project from VS 2017 to 2022. Everything went fine, until I tried to use the Performance Profiler. It hit a frustrating issue where it's collapsing pretty obvious call graphs into single report lines, despite all attempts to fix. This worked fine with 2017.
For example there is this call:
This is a thin wrapper around another call that does the "real work", and you can see this in the profiling results:
But that inner Read() call does not show up in the profile, nor any of the stuff it calls.
I have "Enable Just My Code" turned off. This code is actually "my code", it's linked through a DLL. Debug information is turned on in the DLL build (/Zi) and link.
How can I get VS 2022 to expand stack traces properly? Again this all works flawlessly in VS 2017.
I recently upgraded from Visual Studio 2013 Community to Visual Studio 2015 Community.
I've heavily relied on the "CPU Usage" Tool that can be found by doing the following:
Click "Debug"
Click "Start Diagnostic Tools without Debugging"
Click "CPU Usage" Check box
Click "Start" button
When the program is complete, it is supposed to show you the functions and the time spent in each. What I get instead is just the name of my executable that I can keep expanding instead of seeing the function names -- It doesn't know the names of the functions.
This worked fine on Visual Studio 2013... I would be able to see the function names and everything worked. I tried creating a new "test" solution/project to see whether this works and I get the same results: No function names.
Does this work for anybody? I also installed VS2015 on a fresh development box and still have no results. This seems like Microsoft shipped with a Visual Studio bug.
Note: I'm writing a C++ console application. I've tried this on debug and release builds and ensured that I'm building with debug information.
It's in the Visual Studio 2015 Update 1 release notes, so I suspect it was broken in the initial release:
Profile your CPU Usage while debugging
Now, you can get a detailed per-function profile of your CPU Usage while you are debugging. You can turn CPU Profiling on and off while debugging and view the results when you are in a break state, which allows you to view a per-function breakdown of CPU Usage of code that executed between breakpoints and during steps. (To use this functionality, open the Diagnostic Tools window (Debug -> Diagnostic Tools), switch to the CPU tab, and then click the "CPU Profiling" button.)
I have also noticed this, but if you use that little search box (top right corner of the results area) and try typing in either the name of the function you're looking for or part of the name and it will expand everything (there's usually a lot to expand) and highlight the function you're looking for. Its the only way I've been able to profile specific functions.
I am using the Memory Usage analysis tool from the Performance and Diagnostics tool (Alt + F2) in Visual Studio Ultimate 2013 Update 4. My project is written using unmanaged C++.
During a memory profiling session, I am really hoping to have Visual Studio trigger several breakpoints which I have set. These breakpoints are triggered just fine whenever I run the program without the profiler, but under the exact same conditions during profiling, they are not triggered.
Is there a way to run the memory profiler with breakpoints?
Note: I know I could use application lifecycle marks or user marks to have them show up in the profiler graph. However, the breakpoints will be far more helpful to root out an issue by stepping through the code whenever I see a change in the memory usage.
I am using Visual Studio Premium 2013 Update 2 on a freshly installed (fast) machine with Windows 8.1 Update. Everything is running smoothly, only one thing bugs me:
Problem
When I debug a native C++ project (debug build) by going from line to line with F10 ("step over") it takes 1-2 seconds to go to the next line when I press the F10 key.
What I tried
I looked at several other questions related to slow debugging and made sure that neither of the following is not the reason in my case:
Everything is local (app and all data), no network shares involved
Disabling the Microsoft symbol server did not help
I only have a single breakpoint
Using the menu/toolbar instead of the keyboard does not make any difference
In the default configuration "edit and continue" is enabled, but apparently not for native code:
When I disabled "edit and continue" completely, F10 stepping became much faster (0.5-1 s). The speed is tolerable now. I had to restart Visual Studio after I changed the configuration to this:
I'm trying to wrap existing C++ code into a MATLAB callable function. I'm using Visual Studio 2013 to generate the MEX file . The MEX file is created properly, I can call it from MATLAB and pass arguments back and forth without any issues.
Now I want to debug my C++ logic, and I can't seem to get it to work. I've created an m script that calls my function, and had Visual Studio run MATLAB when debugging - as explained here .
When I hit F5 to debug my MEX file, Visual Studio runs MATLAB, and then exits debug mode very quickly, as if the MATLAB process terminated. A few seconds after that, MATLAB starts running the code. It is as if the MATLAB instance I'm running starts another instance and terminates, confusing Visual Studio.
How can I debug my MEX function?
UPDATE: Apparantly MATLAB is doing exactly that, as described here. Adding the -wait argument makes Visual Studio wait until the script is done running, but the breakpoints I set don't work - because the process being debugged is not the process loading the DLL.
Turns out <MATLABROOT>\bin\matlab.exe actually runs <MATLABROOT>\bin\w64\matlab.exe. So if I ask Visual Studio to run that, breakpoints are triggered as expected.
Running MATLAB this way under the debugger is a lot slower than any other way, but at least now I can debug my code.
You could also run a MATLAB session as usual, and then attach Visual Studio to the running process. This is explained in more details in the documentation. Here is a quick summary:
compile the source MEX-file with debugging symbols enabled.
open the source C/C++ file in Visual Studio, and place a breakpoint.
start a normal MATLAB session. Then from Visual Studio, attach to the running matlab.exe process.
finally from MATLAB, run the MEX-function. You should hit the breakpoint with execution paused.