If you use throw std::runtime_error anywhere inside a C++ program it brutally crashes the Visual Studio 2013 IDE without warning. When I first encountered the crash I uninstalled Windows 7 (64-bit with SP1) and upgraded to Windows 8.1 Enterprise (64-bit). Then I installed Visual Studio Ultimate 2013 (v12.0.21005 REL). I ran the program below with no problems and I thought that I had fixed the problem. However, when I installed Intel C++ Studio XE 2013 (included SP1 with update 1) the bug came back. So there seem (at least on my system, a 2012 Macbook Pro Retina i7 running Windows) to be an issue with how Visual Studio 2013 and Intel C++ Studio 2013 works together.
int _tmain(int argc, _TCHAR* argv )
throw std::runtime_error("Test"); // Crashes Visual Studio here
std::cerr << "Error" << std::endl; // never reached
return 0; // never reached
Steps to reproduce
Create a new Win32 console project by chosing "New Project" in the Visual Studio 2013 IDE, then under "templates" expand "Visual C++" , select "Win32", select the "Win32 Console Application" option, and click the "OK" button. Click the "Finish" button in the "Application Wizard" that immidiately pops up. Now you have a new Win32 project. Now, open the cpp file containing your "_tmain()" function, and add a reference to the include file <stdexcept>, ie:
, then add one line of code inside your "_tmain()" :
function throw std::runtime_error("Crashtest");
Now the code should look something like this:
int _tmain(int argc, _TCHAR* argv)
Now run it (press F5) and Visual Studio IDE crashes without warning; it does not matter if you try to run it in debug or release mode.
Tested operating systems
Windows 7 (64-bit with SP1) and Windows 8.1 Enterprise (64-bit)
Operating System Language
Crashes the Visual Studio 2013 IDE.
From the Windows event logs I can find the following after trying to run the aforementioned code (translated from Norwegian OS):
Error-bucket , type 0
Event name: APPCRASH
Answer: Not available
Files are available here:
Looking for solution once more: 0
Software with error: devenv.exe, versjon: 12.0.21005.1, time: 0x524fcb34 Module with error: ntdll.dll, versjon: 6.1.7601.18247, time: 0x521ea8e7 Exception code: 0xc00000fd Fault displacement: 0x000325c1 Error prosess-ID: 0x1920 Error starttime for software: 0x01ced687ba938040 Error software path: C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\devenv.exe Error module path: C:\Windows\SysWOW64\ntdll.dll
It should not crash the Visual Studio 2013 IDE.
A week since I posted this now. Why are no one from Intel giving me any feedback? Are there some other places I should post bug reports in Intel products? At least one more has reported the same bug http://stackoverflow.com/questions/19735162/throwing-stdexception-crashes-visual-studio-2013-ide#com... .
The crash only occurres after I install Intel C++ Studio XE 2013 (included SP1 with update 1) and not before. I did a clean install of Windows 8.1 and Visual Studio 2013 to confirm this. I don't know what else it could be. If you still think that Microsoft is to blame then you can add a comment to the bug report I filed to them here:
As matter of fact the crash originates probably inside CPUsideRDM.dll .Unfortunately that DLL is not present on my system therefore I cannot use dumpbin to inspect its Import/Export tables and thus trying to understand what that DLL does.Can you check on your system if you have CPUsideRDM.dll ?
@iliyapolak The CPUsideRDM.dll library file resides in the C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Packages\Debugger directory on my system. Even though it is inside a Microsoft Visual Studio directory it still is a Intel library, further investigation reveals that the CPUsideRDM.dll library file product name is "Intel(R) Debugger Extension for Intel(R)...", I have version 126.96.36.199.
I still did not receive my Parallel Studio XE 2013 edition.Anyway for now dump file is sufficient to perform crash analysis.It seems that error originated inside the CPUsideRDM.dll.Now Intel developers should perform more in-depth analysis of their code.
Inge H., the workaround from Steve Lionel in topic http://software.intel.com/en-us/forums/topic/494680 worked for me. Steve also mentions that the issue will be resolved by an update to be released in Jan. 2014. Thank your for posting a way to easily reproduce the problem.