I'm trying to use profiler from Visual Studio 2015 Community for CPU usage, and all I get is just my exe and [External code], nothing else:
There is a generated pdb file, and I tried to clean and rebuild my project, disabled just my code; could someone help me ? Thanks.
Try this: Debug -> Start Diagnostic Tools Without Debugger and from there select Performance Wizard rather than CPU Usage, and only from there select CPU or other option you need, this solved the problem in my case.
The accepted answer didn't work for me - in my case the problem seems to be that I didn't have Debug Info generated in my Program Database File.
The fix I needed was to change Configuration Properties → Linker → Debugging → Generate Debug Info to Yes for my Release configuration, and then recompile all.
In my case the problem was resolved by checking "Enable .net Framework source stepping" option in Tools > Options > Debugging > General. This would also disable "Enable Just My Code".
On a side note, it appears that VS2015 profiler is not particularly effective in finding out finalizer issues if you have lot of disposible objects that you never explicitly dispose (causing finalizer thread to over work). I used JetBrain dotTrace which did pointed out this issue.
I found this thread, and then found a solution... At least in the VS2015 Update 3, the Diagnostic Tools -> CPU Usage -> Filter drop-down has a "Show External Code" checkbox, which when checked expands all [External Code] placeholders.
Sometimes, it is just the lack of relevant information that may cause such error.
In some of my cases, just try cleaning the solution/builds and then start again and the problem would be fixed.
Related
I ran into this problem today while migrating a VS2008 solution to VS2010. The problem occurred in either of the following scenarios:
Rebuild Solution
Clean followed by Build Solution
If I did a second Build after either of these, the problem did not show up. Using Google, all I really came up with was year-old blogs from Microsoft saying they are unable to reproduce the problem, or that it is fixed in a future release.
The best thing I found was here: Mikazo Tech Blog: Solve MT.exe Errors in Visual Studio 2010
In the above article it said that the problem is related to Manifest generation, and that the solution is to turn off Manifests in settings under Linker-->Manifest. I don't need Manifests for this project, but I still wasn't satisfied.
I have solved this, and am simply going to answer my own question, because I haven't found this specific error (code 31) on StackOverflow.
WARNING: This exact error can also happen as a result of having a Windows Explorer window open in the folder containing the *.exe which you are currently attempting to build.
For example: Explorer open in /.../MyProj/Debug/ while trying to build the Debug version of your code in Visual Studio.
I was angry with myself for ~10min before realizing this.
Using process monitor and dbgview I discovered msmpeng (Microsoft Security Essentials) was accessing the file, just when mt.exe wanted to have it exclusively. Excluding the development directory solved the problem.
It is still a workaround of course.
In my projects, the Intermediate and Output directories were set to:
Intermediate Dir : $(Configuration)\
Output Dir : $(SolutionDir)bin\$(Configuration)\
Under C/C++-->Output Files, I had the following:
ASM List Location : $(IntDir)\
Object File Name : $(IntDir)\
Program Database File Name : $(OutDir)\$(TargetName).pdb
Under Linker-->Manifest File, I had:
Manifest File : $(IntDir)$(TargetName)$(TargetExt).intermediate.manifest
The cure was to remove the trailing \ from my C/C++-->Output Files section (because it's already part of those variables):
ASM List Location : $(IntDir)
Object File Name : $(IntDir)
Program Database File Name : $(OutDir)$(TargetName).pdb
Normally, the double-up of using $(IntDir) or $(OutDir) with a trailing \ doesn't seem to cause trouble, even though it's bad practice. I can't remember now whether I did it by accident or if the conversion process did it, but for whatever reason, it seems to have been messing up MT.exe.
I hope this is useful to anyone else who encounters this problem. Your settings may well be different, but consider that it may be related to improperly formed filenames.
Try turning off Windows Defender (or possibly other anti-virus related software). Windows Defender is known to lock files because MT.EXE runs after the linker is finished. WD jumps in the middle to check up on the newly built EXE and locks it up for the MT.EXE.
Giving credit to https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/c5a3e2c3-fbf4-4268-a551-8cee195be586/test-case-13-for-vista-certification?forum=windowscompatibility, I found this was resolved by fixing the '-' character in the post build commandline. I believe some bad copy/paste efforts have replaced a hyphen with a dash.
deleting the "program debug database" in "debug" folder worked for me.
This problem happened when I was running the .exe in the debug folder on high priority.
Run VS as administrator. It solved the problem for me.
I have a project (*.sln) written in visual studio c 8.0. It was migrated to VC10 recently. When I choose the "Release mode", it was compiled sucessfully. But if I choose "Debug mode", the error " MSB6006 mt.exe code 31" happened.
I found that, in the debug mode, it used a wrong sub-project to startup.
After fixing the startup sub-project, it goes fine so far.
---- new status ---
This won't fix the problem. It just makes the problem disapear temporalily by rebuilding-all. Also, there are other faults caused by the migration. The "resources.h" is missed from the new project and the "winres.rc" is shorten.
In my case it was a problem with TortoiseGit. Removing Debug and Release folders from the GIT repository solved the problem.
Check if you have any anti-virus software like AVG. Exclude the manifest files in the anti-virus software exclusion list.
Look for an MSB8012 warnings. Likely you have a different output specification for the C++ output value and the Linker Output value.
Try Sysinternals/Procmon and filter on process = "mt.exe". It might tell you that a build input cannot be found.
In VS2013, I used to be able profile the performance of my projects of my c++ solution by intrumentation. Recently, I had to change a few things to make my project compile correctly in release, and now my projetss are now shown anymore as projet to profile in the dialog.
See: http://imgur.com/edit
I must have removed something required for the performance profiling of visual studio. I verified that I still have /DEBUG in the linker, and /PROFILE.
Anybody know what are the other requirement that could be missing ?
Thanks
We have been moving to our new profiling platform the performance and diagnostics hub http://blogs.msdn.com/b/visualstudioalm/archive/2013/07/12/performance-and-diagnostics-hub-in-visual-studio-2013.aspx . You can go to the Analyze -> Profiler -> New Performance Session. That will cause the performance explorer to open up. You can then right click on targets and select Add target project to get your project selected. Let me know if this does not work for you
I suspect that this relates to having managed-code DLL projects in the solution, since in VS2010 the menu-item was also missing unless I manually unloaded all managed-code projects from the solution.
In VS2012 though, I now have many more managed DLLs in the solution (not by personal choice), so I am hoping that there might be a way to enable "Apply Code Changes" even with managed DLLs in the solution.
I have set my local debugging mode to "Native Only" and also edited the "Edit and Continue" options under Debug - Options and Settings... to enable native "Edit and Continue", but still I get no "Apply Code Changes" icon under the Debug menu.
If I manually add the 'Apply Code Changes' button to a toolbar, it remains continually disabled.
Please can anyone offer any hints and tips as to how I might get this to work, or do I simply have to unload all managed-code projects from the solution?
Supposing that I do have to unload the managed-code projects, is there a straightforward way to maintain two different sets of solution options so that I can quickly decide whether I wish to mount all projects or native-only?
Although I do not have a definitive solution to your problem (I am an a similar position myself) I suspect that a good thorough reading of this MSDN document would be productive for us both:
Edit and Continue (Visual C++)
How do I prevent VS from showing user the following warning:
No Debugging Information
Debugging information for 'MyExe.exe' cannot be found or does not match. Cannot find or open the PDB file. Do you want to continue debugging?
In my situation the user of my product wants to develop a plugin and (s)he want to debug it. There is appropriate configuration in VC++ project so that when (s)he presses F5 then my application will start and load the plugin. However, VS complains about lack of debugging information. While in general lack of valid debugging information is a valid concern, in this case I don't want to deliver .pdb file for MyExe.exe (user has no reason to debug my MyExe.exe application). Is there a way to prevent VS from searching for debugging information for MyExe.exe?
You don't say which version and edition of VS your customer is using, but at least in VS 2005 and VS 2010, open Tools->Options->Debugging->General, there is a list of settings, scroll down, find the "Warn if no symbols on launch (Native only)" setting and clear the check mark.
I believe that this will accomplish what you're looking for, in that the dialog won't pop up unless/until the debugger stops in your code. If it stops (or hits a breakpoint) in the customer's plugin, then it should be able to find the symbols, and I think it won't cause the popup.
I don't believe you can turn off VS's messaging about missing or mismatched PDB's, however, you might be able to create PDB using the /PDBSTRIPPED option when building -- this will give the user a .pdb containing minimal information (just the public symbols, basically).
I have a native C Dll that calls 'LoadLibrary' to load another Dll that has the /clr flag turned on. I then use 'GetProcAddress' to get a function and call it on dynamically loaded dll. I would like to step into the dynamic library in the debugger, but the symbols never load. Any idea?
And I should have said I'm using Visual Studio 2008.
Update: Thanks to some tips below, I changed the project debugging to Mixed. It didn't work, but I think I know why. I am developing an addin to an existing application. The app I'm connecting to starts one exe then it starts another. So I have to use "Attach to process" to fire up the debugger. My guess is launching the debugger that way will default to "Auto". Is there a way to change the default behavior of VS to use "Mixed" debugging?
This is from VS2008, but if I remember correctly VS2005 was similar. In the native project's properties, under "Configuration Properties->Debugging" there is a "Debugger Type" which is set to "Auto" by default. You'll need to change it to "Mixed", because VS isn't smart enough to realize you need managed debugging
I've had mixed experiences with doing similar things like this in VisualStudio. You might consider using ProcMon to see where VisualStudio is looking for the PDB file. Alternatively, you might try using WinDbg. It seems to do better at loading symbols and if it doesn't, you can explicitly load them yourself. Using WinDbg involves riding a steep learning curve, but if you're burning time right now, isn't it worth it?
You can also run the exe on its own and from the source of the managed dll, attach to the process to debug it.
Modify the mixed-mode dll to throw a CLR exception where it enters the first code you're interested in debugging. This should give you an opportunity to launch the managed debugger.
In VS2005, there are per-project options to enable native and CLR debuggers separately. You might need to enable the CLR debugger for the native dll project from which you start the debugger.