Problems measuring performance of C++ project in Visual Studio 2010 - c++

I am trying to measure the performance of some functions and methods of a console application project in Visual Studio 2010.
I configured the profiling method to instrumentation. The problem is that the performance monitor doesn't work. The message that I get to the output is:
Profiling started.
Instrumenting w:\MyProject\ProfilingTest\Build\Debug\ProfilingTest.exe in place
Info VSP3049: Small functions will be excluded from instrumentation.
Microsoft (R) VSInstr Post-Link Instrumentation 10.0.40219 x64
Copyright (C) Microsoft Corp. All rights reserved.
File to Process:
w:\MyProject\ProfilingTest\Build\Debug\ProfilingTest.exe --> w:\MyProject\ProfilingTest\Build\Debug\ProfilingTest.exe
Original file backed up to w:\MyProject\ProfilingTest\Build\Debug\ProfilingTest.exe.orig
Successfully instrumented file w:\MyProject\ProfilingTest\Build\Debug\ProfilingTest.exe.
The process cannot access the file 'w:\MyProject\ProfilingTest\Build\Debug\ProfilingTest.exe' because it is being used by another process.
Data written to w:\MyProject\ProfilingTest\ProfilingTest110611(17).vsp.
Profiling finished.
File contains no data buffers
File contains no data buffers
Analysis failed
The process cannot access the file 'w:\MyProject\ProfilingTest\Build\Debug\ProfilingTest.exe' because it is being used by another process.
Profiling complete.
I presume that the "root of all evil" is:
The process cannot access the file '...' because it is being used by another process.
Did anybody faced such problems trying to profile native applications developed in Visual Studio 2010 and solve them?
Later add:
If, instead of choosing a project to profile, I am choosing directly the built executable, I succeed to profile, without receiving process blocking, I even received the file analysis. However, the monitoring application is crashing at the end of the profiling. I suspect is related to IDE, but I can't tell for sure.

from the performance wizard choose executable as your target and give the path to the executable. This solved problem for me.

Use process explorer's find handle feature (ctrl + F) to figure out which process has ProfilingTest.exe open. That'll get you to the next step of the troubleshooting process.

Another work-around that I found was to do the following:
1) Launch performance wizard
2) choose your project
3) un-check the box to automatically start your profiling
4) Choose "New Performance Session" and choose your project again (top button on Performance explorer window)
5) Select your performance session from "Targets" and choose "Start Profiling"
I wonder if the nice folks at Redmond have taken notice of this..
Regards.

Related

Starting VS2019 and either starting profiler or skipping welcome screen

I often use VS 2019 (16.8.5) to profile applications developed with Qt on Windows (10). I've got it configured as an external tool in Qt Creator.
However, every time I open it by just running devenv.exe, I have to go through the same process of clicking "Continue with No Code" on the startup welcome screen, then selecting Debug → Performance Profiler from the menu. I'd like to automate that as much as possible.
So my question is: Is there any way, from the command line, to start the IDE, skip that welcome screen, and go straight to the profiler? If not, can I at least skip the welcome screen?
I looked in the manual but couldn't find anything that seemed to do the job (/NoSplash doesn't skip the welcome screen, btw). However, I noticed that the output of devenv.exe /? in the console listed a slightly different option set, and also there's the /Command switch (which I also read the docs for), and both of these together, combined with past experience, lower my confidence in the completeness of the documentation there. I also found Running the Visual Studio Profiler from the command line but it discusses using the command-line profiler directly; I want to run the graphical profiler in the IDE, though.
If there's no way via devenv.exe, is there maybe some other way to automate this? And if there is a way, the bonus question is: Can I go further than just opening the profiler and actually start profiling given an executable filename or a running PID?
You can start VS and open the profiler like this:
"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\devenv.exe" /Command Debug.DiagnosticsHub.Launch
It is easy to configure Visual Studio Code to your liking through its various settings. Nearly every part of VS Code's editor, user interface, and functional behavior has options you can modify.
in order to stop the welcome screen do the following things
go to File > Preferences > Settings
search "Startup Editor"
choose "None" from the drop-down menu
in order to edit / make a new screen when app started follow the below steps
go to File > Preferences > Settings
search "Startup Editor"
choose "NewUntitleFile" from the drop-down menu
Setup your own file

Headless debugging on Windows

There is a bug that I would like to fix that only occurs on Windows Server without a GUI running. I have set up a Windows Server 2019 machine on Google Compute Engine that reproduces the bug, and would like to debug it.
Ideally, I would like to use gdb, but seeing as the program was built with Visual Studio 2019, gdb can't read the debugging symbols.
I don't have a Windows machine, so using Visual Studio will be difficult. I could set up a VM, but if there's an in-terminal way to do this that would be preferred.
I did a pretty thorough Google search, but it didn't turn up anything. Is there really no Windows solution for debugging C++ code headlessly?
MS has 2 console debuggers called CDB and NTSD so you don't actually need Visual Studio GUI to do the debugging. In fact there are a lot of debugging environments in Windows from MS beside the usual Visual Studio. Just install them in your Windows Server and control them remotely from your terminal
You can also debug MSVC-compiled code with LLDB since the PDB format has been published long time ago and LLVM on Windows does support it. No idea about current LLDB on Linux though
And since you have the source code, sometimes the old-school printf debugger is the best way to analyze the issue
If you can get a Windows VM it'll be much better to do remote debugging. In fact almost all debuggers support that feature including GDB or LLDB, so even if you don't have the source code you can still run any Windows debugger and step through the instructions instead of high-level code lines from a remote machine
An alternative way is to take a memory dump and debug later. After getting the dump file, just drag it into your VS solution or any debugging tool like WinDbg and then select "Start Debugging". Now you can step through instructions/code lines and examine variables' values, or jump to an arbitrary function's stack frame just as if you're really running the malfunctioning app
There are many ways to dump a process' memory. You can set Windows to automatically save a dump file when your app crashes, or just capture memory snapshots manually during runtime. Comparing 2 snapshots is also useful for detecting leaked memory. For more information on how to do that read
Collecting User-Mode Dumps
Steps to Catch a Simple “Crash Dump” of a Crashing Process
There's also an easy way to take a dump of a live process using task manager (or any other similar tools)

Embedding thread names in Windows minidump files

Our 32-bit C++ application names its threads using the standard approach on Windows. We generate minidumps when errors occur, but when the dumps are loaded into Visual Studio 2013 the thread names are missing. This makes it harder to debug the problem given the high number of threads present.
The only way I've heard of to improve this comes from this Microsoft User Voice posting, where the caller suggests embedding them in a custom stream, and writing a custom Visual Studio extension to rename the threads upon loading the dump. However, this seems cumbersome and apparently adds a lot of time to the loading process.
Is there an easier way to embed thread names in the dump so they "just work" when loading them in Visual Studio?
For reference: we use Visual Studio 2013 to build, our apps run on Win7 or higher, and we use Google Breakpad to generate dumps.
Microsoft has indicated that the SetThreadDescription API will be the basis for any proper support they add in the future for thread names in dumps, debuggers, and/or analysis tools.
Unfortunately it appears that this API is rather new and is not yet supported in dumps, WinDbg, Visual Studio Debugger, etc. There is a User Voice request to add this support, so please vote for it if you would like a way to properly give threads a persistent name.
After some more digging, it seems like one way to do this would be to store a pointer to the name in the ArbitraryUserPointer field of the TEB of the thread.
If the TEB was then embedded in the minidump (which can be achieved with the MiniDumpWithProcessThreadData flag, according to this article) then it seems like at the very least we could view the current thread name in the Visual Studio watch window by evaluating
(*(char **)(#TIB+0x14))
Perhaps a Visual Studio debugger add-on could be written to examine the contents of the TEB when a process is attached to, and use the exception 'hack' to set the name of the thread in the Threads window.

Can the visual studio debugger still be used to debug ppapi trusted plugins when using the --ppapi-out-of-process flag?

I am using the new MessageLoop class introduced in pepper-25 so I can run a background thread with blocking ppapi calls for File IO. Up until now I have been running chrome from visual studio with the flags --single-process and --register-pepper-plugins so I can debug my plugin from within visual studio.
Using these flags I found that the call to PPB_GetInterface get_browser for PPB_MESSAGING_INTERFACE was returning null and after some searching I found this issue which states you must run with the flag --ppapi-out-of-process to get MessageLoop support.
With that flag added get_browser does return a valid interface pointer but I can no longer debug my plugin with the visual studio ide as it cannot attach to the child process that my plugin is run from. Is there anyway to tell it to attach to my plug-in process or a way of running from a single process with support for MessageLoop?
Thanks,
James
To get Visual Studio to attach to child processes automatically, you can use the workarounds described at Can Visual Studio be made to debug child processes like WinDBG?.
A different approach is to use the flags --no-sandbox and --ppapi-startup-dialog when you start Chrome. This will cause a message box to appear with the process id when a plugin process is created. You can then connect the Visual Studio debugger to that process using Debug -> Attach to process... -> pick process id. Of course, you could have attached to the process without the Chrome flags and it's not automatic, so this really just gives you certainty that you're attaching to the right process if you have many running at the same time.
A third approach is to use the free Microsoft-provided debugger WinDbg. It is complex and much less user-friendly than the built-in debugger in Visual Studio, but it does have the ability to attach to child processes automatically. Download is available from http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx.
As for MessageLoop it will not be supported for in-process plugins. As the issue you link to mentions, developers should move to out-of-process, even if it adds the inconvenience of not being able to attach the Visual Studio debugger automatically without workarounds.

How can I configure windows to generate a core dump from an application?

How can I configure windows to generate a core dump from an application?
I'm using Win xp, and the application is build with Visual Studio 2003.
Microsoft has a free tool called Userdump.exe which will do this.
It's pretty simple to use that tool to create a dump (.dmp) file for a process that shuts down with an exception or to create a dump file for a hanging process
Just to throw in some other suggestions:
ProcDump that is part of the MS SysInternals suite (it captures crashes but also does a load more, can take dumps if CPU usage spikes for an amount of time, etc)
You can put code into your exe using MiniDumpWriteDump to save out dumps youself (which I've done in a few tools). You have control over the name and location (i.e. network path). There's some sample code here
You can open Task Manager (by right clicking the task bar), find your process in the processes tab, right-click it and select Create Dump File.
You might try using WinDbg as described here.
You can use adplus to produce a crash dump for a running application. The command may look something like this:
C:\Program Files\Debugging Tools for Windows\adplus.vbs -hang -do -o c:\ -quiet -pn theprocess.exe
You can also attach to a process with windbg and run this command:
.dump /ma c:\somepath\filename.dmp
I refer you to the follows MS KB article on the subject. You would typically debug the dump file using one of the Windows debugging tools, e.g. WinDbg. There are many articles on the web describing how to do this.