I have Visual Studio Enterprise 2015 and a native C++ project. I would like to analyze memory usage. Our software runs as a Windows service, so I typically debug by attaching to the running service. I found that when I do that the Diagnostic Tools Memory Usage is not available:
However, when I start the software through the debugger (by pressing F5) the Memory Usage tool shows up:
Is it supposed to be like that, ie. is the Memory Usage Diagnostic Tool not supported when attaching to a process?
The Memory Usage Diagnostic Tool is missing both when attaching to a locally running process as well as when remote debugging (attaching to a process on another machine).
The Diagnostic Tools native memory profiler will support attaching to a process in the upcoming Visual Studio 2015 Update 1. There will be a CTP preview release coming out this Fall that you can try out.
Related
I'm using Visual Studio 2017 with a ClearCase dynamic view connected to a mapped drive.
Starting a debugger session fails with:
Unable to start program filename.exe.
Operation is not supported.
Unknown error: 0x80070057.
Using a ClearCase snapshot view, the debugging session works as expected, without error message.
Visual Studio 2013 works perfectly fine with a snapshot or dynamic view.
Any help would be appreciated.
It depends on your exact ClearCase version, as seen in this PI45450 (project issue, similar but not identical to your case)
PI45450: RUNNING AN .NET EXECUTABLE IN A DYNAMIC VIEW FAILS WITH RUNTIME ERROR SYSTEM.ARGUMENTEXCEPTION 0X80070057 (E_INVALIDARG)
Recommendation:
Running the executable by specifying its fully qualified UNC
pathname may work, such as
\\view\viewtag\vobtag\<application>.exe
In your case, with Windows:
m:\viewtag\vobtag\<application>.exe
See if the full path (M:\...\<application>.exe) works better with Visual Studio 2017.
Or try and upgrade ClearCase if possible (8.0.1.10+).
There is a new ClearCase APAR for this behavior, because it was initially reported only if the CC VS 2017 integration was installed. It actually doesn't need the integration, at least not on Windows 10 with UAC on. The APAR is PI86014, but it may not be visible yet as it's really new.
The issue is specific to Visual Studio 2017, Visual Studio 2015 will open and start the debug session fine, and the debug executables load just fine from a dynamic view.
The integration released in the technote seems to be a little buggy. Perhaps the one in 9.0.0.5 and 9.0.1.1 will behave better.
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 tried to use a Performance wizard tool for my short C++ testing in VS 2010 Ultimate.
But for any code the profiling process crashes and the following error occurs:
Could not launch xxx.exe. Injection of runtime library failed.
By this time I used Netbeans and with the VS 2010 profiler I do not have much experience.
I wonder whether this function is available for unmanaged C++... The C++ code is correct...
Configuration: VS 2010 Ultimate, Win 7 Prof. 32 bit.
Updated question:
An instrumentation method works well but the CPU sampling method still does not work.
Yes, the profiler works on native code.
Try running Visual Studio as an elevated admin user.
Check if you have enabled Application Verifer shims for your application.
This problem can be caused by some security or anti-malware program installing hooks in your program, so the profiler cannot get its hooks in. Some vendors provide ways to limit those hooks so you can profile, or you could just try turning it off for a period while profiling.
To get the dump file (for crashes) I am using the userModeProcessorDumper.exe. Now the question is how to read this file (to see the stack information). Regarding this I have couple of questions
Yes I know I can use WinDbg (related tools) to analyze the .dmp file. My question is - Can this be analyzed in Visual Studio? To be more specific - I am having Visual Studio Enterprise Edition 6 - In this particular pack - can the .dmp file be opened for analysis.
If Yes, Please help me with steps.
I see in web advice to use Visual Studio 2XXX version. So I am feeling that the same cannot be done using VS Enterprise Edition.
The application is built on MinGW, even these application - can we analyze in Visual Studio (what ever is the edition - i.e Visual Studio 2XXX or VS Enterprise Edition X.Y)? Should I take care of any additional setting for this.
Any material link on this topic would be very helpful to me.
Thanks a lot in advance for your advice.
PS : My application is a C++ based application.
From what I remembered, VS6 cannot be used to debug dumps. It's been a while since I last used it, and trying to verify me memory I came across a workaround that might allow you to debug those dumps after all: Visual C++ 6, and post-mortem (crash dump) debugging.
I don't have VC6 at hand, and have no idea if this really works. Other than that, I feel for you... There are IDEs so much better than VC6. Hope this inability gives you the push towards an upgrade. Debugging dumps is really easy with VC7 and above.
This question already has answers here:
Closed 13 years ago.
Possible Duplicate:
Why use windbg vs the Visual Studio (VS) debugger ?
I Use Visual Studio 2005 for C++ development.
What does WinDbg give me, that Visual Studio doesn't?
I know its good for client installations and remote debugging, as it's easy to install.
Other reasons? What are your favorite functions/commands?
In WinDbg you could force to load PDB file that has incompatible (with EXE) checksum/date. Just write .symopt+0x40 in command line. Visual Studio doesn't allows that.
From Wiki:
WinDbg can be used to debug user mode applications, drivers, and the operating system itself in kernel mode. It is a GUI application, but has little in common with the more well-known, but less powerful, Visual Studio Debugger.
WinDbg can be used for debugging kernel-mode memory dumps, created after what is commonly called the Blue Screen of Death which occurs when a bug check is issued. It can also be used to debug user-mode crash dumps. This is known as Post-mortem debugging.
With WinDbg you have the ability to remotely debug an application with two WinDbg instances (client/server). That can be quite handy to debug an already deployed application at the customers site.