I ignored this tool for a long time, because it was .NET only.
According to MSDN, the diagnostics tool works for native code, compiled in Visual Studio 2015 in Debug.
I am following:
https://learn.microsoft.com/en-us/visualstudio/profiling/memory-usage
I enable 'Heap Profiling' in the 'Diagnostic Tools' window, under the 'Memory Usage' tab. I then rebuild all, making sure the toolset is 'Visual Studio 2015' for every project, and making sure PDBs are built for every project that is a dll or exe. I set a breakpoint at main, when a client connects to my process, and after that client is sent data. There are thousands of calls to new in between. Each time I click 'Take Snapshot'. When I click take snapshot, a row appears with time, Allocations, and Heap Size. The latter two are zeroed out.
If I do the same with my one of my unit tests, they are filled out and I can drill down as described in the documentation.
What should I look for to get it to work with my main project?
Are there certain linking settings? Does it matter that I am building statics libs and dynamic libs? Anything specific to to look for?
I've had a similar issue (the vs2015 or vs2017 showed 0 allocations on the heap).
Then I've noticed I had my gflags enabled to full page heap verification (can be checked by gflags /p).
I've just disabled it and now heap snapshots started to work again :-)
Related
Creating a ATL COM DLL in Vs2015 for a VB6 consumer is going badly because the "fault tolerant heap shim" is being applied to VB6, which I am running from the vs2015 debug command.
I have found many posts about disabling FTH in Windows 7, and indeed I have applied them all, including deleting the DLL in \Windows\AppPatch, as well as disabing FTH in the registry AND running the rundll script that is cited.
Still, this damn thing is making it impossible for me to debug the dll, because the FTH makes it run like a dog under VB6 in debug mode.
I even added "vb6.exe" and "full_path_to_vb6.exe" in the exclusions list in the registry -- to no avail.
I desperation, and needing to get some work done today, I have renamed vb6.exe to myvb7.exe (!) and this gets rid of the FTH alert in the VS debugger. But why can't I disable FTH for vb6.exe?
In fact, why does it even get enabled at all when a debugger is attached? It's driven me mad today.
Anyone?
There wasn't too much help forthcoming on this. For future reference, if the application (in this case VB6) is set to run in compatibility mode (either from a right click on the shortcut you use to launch it, or from a property set on the target exe itself) then nothing you do will release the shim!
Solution: don't run vb6 in compatibility mode under Windows 10!
I'm setting break points in Visual Studio before running the Local Windows Debugger, and they all say this when the debugger is running, with a small warning label on each break point. I can't see why this would be happening; people have talked about using different versions of Visual Studio and getting this error, but I made this project earlier today, pasting the base code from my professor into a new project created on my copy of Visual Studio 2012.
I found this when trying to fix a strange error in my program that wouldn't go away even though I manually fixed things (it was a string error that claimed I was using an index outside the bounds of the string; setting this value to 0 explicitly did not fix it) so I presume that this is the actual culprit.
Make sure you're properly building the code (Build Solution or Rebuild Solution).
In the output panel you should now be able to locate where the binaries are located.
Make sure you're debugging the said binaries by looking in the Debugging page of your project properties, the Command property should most likely be set at $(TargetPath).
Other things to look for. The project should be "Set as startup project", the program database option should be activated (by default). Don't modify the source after you started debugging.
I've a solution with ceratin no: of projects (all of them EXE projects in VC++).
I use VS2013.
This is tied to a version control system (Perforce).
I see that as soon as I start building any of the projects in this particular solution, the VS gets hung.
I see a text "Not Responding" at the top of the VS window.
Howvever teh compilation happens successfully but it takes a very long
time for the compilation due to this hang.
Id the expected compilation duration is "10seconds" it takes 3 mins to compile.
THis problem is seen in both Relaese and debug mode.
A point to note it that the very same projects were building super fast few days back & this issue started few days back.
Evevry other solution and it's projects (except this particular solution projects) are compiling very fast.
Any help is really useful.
You can also try to reset Visual studio settings trough:
Tools > Import and Export settings > reset all settings
this will reset all enviroinment settings, then restart visual studio.
edit:
I would also create a new project and copy/paste header and source files from old project to new one, and then compile.
I am not sure if you are using the P4VS Perforce Plugin with Visual Studio or not. However, there is a possibility that the compile is changing files that are checked into perforce or possibly somehow triggering an update. If you are using P4VS, please try building with it disabled and see if that
builds faster.
Try restarting your computer to see if that works. You may have some memory that was leaked from your program which is making it compile slower than usual. A restart of the computer should free all the memory.
Environment: I have a .NET 4.0 solution that references some Visual C++ projects. Visual Studio 2010.
If I build my solution and run the resulting .exe right from the bin directory, I can reproduce my bug. But if I run it hitting the "play" button in Visual Studio (or if I run the process and attach to it) I can step through the code, and everything works as normal.
For reference, the problem I'm getting is an Access Violation which is most definitely happening the C++ code.
But more broadly, I'm wondering what other reasons there might be that attaching a debugger to a process "fixes" the issue.
MS VS is working like a sandbox. When you are starting app in that sandbox, your program inherits all settings from solution properties (or just VS settings). Make sure, all your options provided for the environment are correct. If that wont solve the problem, please double check those settings and think what can prevent access violation and uncheck/check it.
If you are using external DLL, those from you system and those from IDE may have different version. They, of course, may work in both cases, but also may cause problem like access violation or subcribent out of range, depending what is changed inside those dlls.
If its Windows app, try enabling/disabling LargeAddressAware.
If you are compiling stuff for another machine with different OS, it may happen very often due to changes in memory handling by native OS. Memory can sometimes be multi-blocked, extremely fragmented or even multi-deviced, so compile your program only with compilation especially made for targeted OS/machine
debug mode uses assert() and other stuff directly linked to debugging. If something is wrong in debugging and not in release, it means that it is acceptable by machine but not by debugging insertions. In that case you are screwed but if its not appear to be problem in other debugger, well... problem solved, its debugger issue, espeially if release without debugging options is working.
most tiring method - try to pinpoint access violation address and see inside memory windows to what are you referring.
in other cases, supply us with snippet, so we can tell something more!
#Matt this cant be heap problem, it can happen but its extremely rare.
#Huytard its wont happen, without linked dll's program should't even start.
The correct and short answer. Run Windows Updates.
The correct and long answer.
It turns out my build machine hasn't been updated in a while and was using an outdated version of Visual C++ compiler. There was a bug in the compiler for .NET 4 where static constructors were not getting called first before any other types of constructors (only in Release Mode).
But here's the kicker!
If you run the process in the Visual Studio debugger OR you attach to a remote process. The static constructors DO get called first like they are supposed to! (Hence making the issue completely un-reproducible in a debugging environment -- Even in Release mode) I found the issue by placing message boxes all over the place to determine the code path.
http://connect.microsoft.com/VisualStudio/feedback/details/611716/c-cli-class-static-constructor-not-called-in-release-build
Running the green "play" button will use the IDE's environment
Executing from the directory will use the default environment
My guess is that there are probably some DLL's or dependencies that need to be added (directory paths) to your %PATH% environment variable.
Once you identify the dependencies and double check or something with dependency walker - you can set them in a batch script and then call your application.
For example:
#echo off
set PATH=%PATH%;C:\myLibs
call MyApp.exe
I have a large project that has > 1000 files.
When I press the green 'Play' button to start debugging, once everything is built, it can take up to 5 minutes for the app to start running.
It looks like Visual Studio is loading and unloading various DLLs, but it also just sits there occasionally doing nothing.
Running from the command line takes only a few seconds.
What's going on? How can I speed it up?
[EDIT] It turned out to be our Symbol Server. The administrator had killed it without informing anyone. Doh.
Thanks for your help guys.
Some thoughts and suggestions:
It could be caused by complex dependency checking that VS2005 does to ensure that no components have changes and have to be re-built prior to debugging. Sometimes tweaking the inter-project dependencies in the solution can help.
Are you using source control integration in Visual Studio? If so, sometimes accessing the source control repository elsewhere on the network can cause Visual Studio to slow down like this. If using a source control system like ClearCase where you can reduce unnecessary LAN communication (e.g. using a snapshot view), consider doing this.
I also find that running the executable separately (from outside Visual Studio) and then using VS2005 to attach to the process can be much faster. This is predominantly the way I work, and I find it much less frustrating.
Another thing to consider is whether you are using a symbol server to access debug symbols for the Windows DLLs. If so, VS2005 can sometimes try to access the symbol server every time you debug. The way around this is to load the symbols once, and then uncheck the symbol server URL under Tools->Options->Debugging->Symbols. As long as the OS libraries haven't changed since you last downloaded the symbols, there's no reason to access the remote server every time.
It sounds like it could be loading symbols for various DLL's which you probably don't care about. You can disable these in Options.
If not, what do you see in the Output window?