When compiling my C++ project or running it, everything is fine.
But when starting my project with the debugger, Visual Studio 2015 crashes.
I tried this, I have found two errors:
<entry>
<record>484</record>
<time>2017/02/14 14:09:32.187</time>
<type>Error</type>
<source>Color Theme Service</source>
<description>The color 'Popup' in category 'de7b1121-99a4-4708-aedf-15f40c9b332f' does not exist.</description>
</entry>
and
<entry>
<record>558</record>
<time>2017/02/14 14:10:08.617</time>
<type>Error</type>
<source>VisualStudio</source>
<description>Loading UI library</description>
<guid>{8C0C630B-37F1-11E3-8259-6C3BE516EAD0}</guid>
<hr>800a006f</hr>
</entry>
I don't know what to do to make VS's debugger work.
Edit: I use the dark theme if this can help...
One issue is that whether all projects have the same issue or just the specific one.
(1) Collect the crashed dump file and debugging it is also a good suggestion for the crashed issue.
(2) I also provide some suggestions which could narrow down this issue.
Please uncheck symbols server under Tools -> Options -> Debugging -> Symbols.
Uncheck "Edit and continue", "Load dll exports (native only)" and "enable just my code(managed only)". Debug it again.
Disable the IntelliTrace under TOOLS->Options->IntelliTrace, and "Use Native Compatibility Mode" under TOOLS->Option->Debugging->General or mix mode/native debugging project property(right click project->Debugging). Test it again.
I met the crashed issue before which was related to certain settings, so if possible, you could test it in your side.
But if all projects have the same issue, I suggest you repair your VS, or install the latest update package for your VS, and then debug it again.
If just one specific project has this issue, we would think about the project itself.
Update:
As our discussion, I found that you have reported this issue here:
https://connect.microsoft.com/VisualStudio/Feedback/Details/3123487
I will help you vote it and add my comment there. If I get any latest information from the report team, I will update it here.
Related
I have recently installed Qt Creator 4.8.0 based on Qt 5.12.0 and I have it configured like in the image below. However, I haven't managed to start the debugger. As it can be seen, the debugger is correctly set for this kit, the one I'm using right now.
Any solution?
Thanks!
Wow! I found it!!! Here in the tab "projects", there are several build and run configurations. Despite you select a default kit, the final one being executed is the one in black under this tab.
Finally I disabled all of them except the one that was properly configured in the Kits window and it worked. I hope this information is helpful for someone. I don't think that part of the configuration is clear.
I got the same error, but in my case I was using the MSVC compiler and the kit didn't manage to find the CDB debugger. I was able to fix it by going to "Add or remove programs" -> "Windows Software Development Kit" -> Modify -> Change -> Debugging Tools for Windows.
In my case it was needed to select "Enable C++" under Debugger settings
screenshot
The same dumm error QT creator shows when you simply don't have gdb installed.
Worked in my case ;)
I had the same error in MacOS, debugger suddenly stopped working (LLDB debugger worked in XCode but not Qt Creator).
In this case, I reinstalled Qt Creator and reinitialized the config by removing the .config/QtProject directory located in homedir. This solved the problem.
I had the same issue when Qt Creator didn't recognized the path to the Debugger. Due to some reason it showed multiple Auto-detected Debuggers at the same location. And on the top one of the list with the red error indicator.
see
Projects->Manage Kits...->Debuggers
I removed the erroneous Debugger and restart the Qt Creator.
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.
I have several C++ codes I develop in VS2013 Professional. Today, I installed the Intel Fortan Compiler (Composer XE2013 SP1), and now none of my C++ Projects will load. When I open my solution, I see:
myprojectname (load failed)
The Project requires user input. Reload the project for more information
If I reload the project, I get a popup error that reads:
Parameter "path" cannot be null.
Any suggestions on how to solve this without just reinstalling VS?
Thanks!
A Google search on this error message tends to suggest that you may get this if the project is on a network drive. The recommended solution is to right click on the project (in Solution Explorer), select Reload Project, and respond to the prompts.
I'm writing a C++ application using VS2010 on two dev computers - both are Win7 64bit SP1. I use git to sync the repositories.
On one of the machines the compiled executable (and also the test exec) stopped working with the following error, while on the other machine it works fine and I'm able to continue development.
The application was unable to start correctly (0xc000000d). Click OK to close the application.
I tried deleting the repository and cloning it again. I also made sure I have the same versions of Boost, git, Visual Studio. Also, I tried debugging (stepping in) but the error occurs before any line of code is reached.
Notice as far as I understand I'm tracking Visual Studio's solution\project configuration files as detailed here.
I'm at a loss, how would you debug this?
UPDATE 1:
Only the Debug version fails to run. The Release version runs fine
UPDATE 2: The executable that doesn't work does work on the other computer!
UPDATE 3: I've reinstalled VS2010 (exactly the same version) - didn't help. Surprisingly the compiled files are not the same size between the two machines.
I got the same problem as you mentioned.
My solution:
Clean the manifest file and rebuild
In the property page-> Manifest tool -> make sure "Additional Options" is set to nothing.
(I set it as "/validate_manifest" before).
Or you can try "Embed Manifest -> NO", rebuild and then set back to Yes. It sounds to be ridiculous, but it really works sometimes. I don't know why.
I got the same phenomenon suddenly without a warning on Win7 / VS2010 / C++. Debug App couldn't be launched, got 0xC000000D at initializing and loading multiple dlls. Found one base dll of my own responsible, played around with linker settings. Modifying settings, incremential rebuild -> app starts, rebuild all -> app crashes again. After setting "generate manifest" to "no" in the linker settings the sample app works, but the main app still crashes. After setting "generate manifest" to "no" for the most of my dlls -> the app starts in debug mode again. The stuff is very spurious, because some dlls need the modified settings others do not.
Have a look at the top two answers to this question
Program crashes with 0xC000000D and no exceptions - how do I debug it?
On the machine where it fails, try running the debug executable NOT under the debugger, and update your question to say what happens. If it crashes, are you able to then attach the debugger whilst the message box is still there and get a stack trace that tells you what function it is crashing in?
This is the weirdest thing....
Try deleting the "ipch" directory and then rebuilding.
Hope it works for you, I have wasted hours on this.
disabling/enabling precompiled headers fixed the issue for me.
I was facing crash on Debug x64 only - I guess it was related to an upgrade from boost 1.50 to 1.52, while keeping pch files.
in my case i got it working again by setting generate manifest to NO on all projects
I have changed "Embed manifest" setting to NO and then back to YES but it didn't help.
For me setting General->Platform Toolset to Windows SDK 7.1 for my program and all dependent libraries compiled with it helped.
It's the ipch just delete the entire folder and it will clear it up. I was confused for a while too.
I saw the error while using OpenCV library compiled with MSVC2010 in a project running on MSVC2015. Changing project configuration properties->General->Platform toolset from Visual Studio 2015(v140) to Visual studio 2010(v100) resolved the error.
I posted this on programmers first, but was told it belongs here. Funny, I didn't think so.
I have VS10 installed on a Windows Server 2008 R2 box, along with several other versions of VS dating back years. This is our production build machine.
When I load or create any C++ project and do a Rebuild or Clean, the IDE crashes. In the crash details, I see this:
I have seen other reports what seems to be the exact same error on the web (example). Other than the advice to open a ticket, I've seen no solution.
Has anyone else encountered and fixed this problem? I've opened a ticket with MS, but I'm covering my bases posting here as well.
EDIT:
I ran a logfile as suggested in comments. These are the only entries that occured after I loaded up VS, so this includes the build & the crash:
<entry>
<record>229</record>
<time>2010/12/01 19:35:39.804</time>
<type>Information</type>
<source>VisualStudio</source>
<description>Entering function CVsPackageInfo::HrInstantiatePackage</description>
<guid>{68939055-38E0-4D17-92CB-8909710D8178}</guid>
</entry>
<entry>
<record>230</record>
<time>2010/12/01 19:35:39.836</time>
<type>Information</type>
<source>VisualStudio</source>
<description>Begin package load [Windows Forms Designer Hosting Package]</description>
<guid>{68939055-38E0-4D17-92CB-8909710D8178}</guid>
</entry>
<entry>
<record>231</record>
<time>2010/12/01 19:35:39.882</time>
<type>Information</type>
<source>VisualStudio</source>
<description>End package load [Windows Forms Designer Hosting Package]</description>
<guid>{68939055-38E0-4D17-92CB-8909710D8178}</guid>
</entry>
How about contacting MS support directly? If this is blocking your work, you can push them to have it fixed (don't know about costs though, will probably depend on the product and specificities of your license...).
Alternatively, you can build your solution in the commandline: open a VS 2010 command prompt (shortcut is located somewhere in the start menu):
msbuild yoursolution.sln /p:Configuration=Debug
That shouldn't use devenv.exe (which is the thing crashing here) and invoke the tools directly.
The P8 bucket has a strange value, at least when compared to my machine. Check this post for a way to reverse-engineer the crashing method. The crashing assembly is stored in the C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.VisualStudio.Shell.10.0\v4.0_10.0.0.0__b03f5f7f11d50a3a directory on my machine.
The P7 bucket (note that yours doesn't match the linked one) points to ServiceProvider.GetService(). The P8 bucket gives an IL offset of 0x4b but I see the method end at 0x41. However, I haven't yet figured out how accurate that can really be when the JIT compiled code gets optimized.
If this is anywhere accurate then you don't got much for a lead. A GetService() method is hopelessly generic. Although it certainly looks like it came up with a bad one that didn't survive a cast. It is the kind of stuff that addins can mess up.
Btw, this doesn't actually affect the build output, MSBuild.exe runs as a separate process.
For anyone still having this problem, the answer that fixed mine was that I had tried to completely wipe Internet Explorer from my computer- leading to the DLL call failure that crashed devenv.
Here is their official solution page:
http://support.microsoft.com/kb/983279
My question to Microsoft is... Why would a dependency on internet explorer to compile applications even make sense under any circumstances?