throw std::exception crashes Visual Studio 2013 with Intel Parallel Studio

throw std::exception crashes Visual Studio 2013 with Intel Parallel Studio

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.

#include "stdafx.h"
#include <stdexcept>
#include <iostream>

int _tmain(int argc, _TCHAR* argv [])
        throw std::runtime_error("Test"); // Crashes Visual Studio here
    catch (...)
        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: 

#include <stdexcept>

, then add one line of code inside your "_tmain()" : 

function throw std::runtime_error("Crashtest");

Now the code should look something like this:

#include "stdafx.h"
#include <stdexcept>

int _tmain(int argc, _TCHAR* argv[])
    throw std::runtime_error("Crashtest");
    return 0;

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.

Product Language


Tested operating systems

Windows 7 (64-bit with SP1) and Windows 8.1 Enterprise (64-bit)

Operating System Language


Actual results

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
Cab-ID: 0

Problem signature:
P1: devenv.exe
P2: 12.0.21005.1
P3: 524fcb34
P4: ntdll.dll
P5: 6.1.7601.18247
P6: 521ea8e7
P7: c00000fd
P8: 000325c1

Attached files:

Files are available here:

Analysis symbol: 
Looking for solution once more: 0
Repport-ID: 031b58cb-427b-11e3-97e4-a820661c62c8
Repportstatus: 5
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
Error-ID: 031b58cb-427b-11e3-97e4-a820661c62c8

Expected results

It should not crash the Visual Studio 2013 IDE.

20 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

It seems that this code  c00000fd stands for stack overflow.Can you dump context state.I would like to see the faulting IP if it belongs to devenv process.

Here you go, report file is attached.


Downloadapplication/zip appcrash-devenv-exe.zip682.99 KB

Thanks I will look at this.

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 .

It is still unknown if the crash is even coincidentally related to Parallel Studio.It could be also MS problem and it seems so by looking at dump file.

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 ?

I will upload a recurrence calls stack dump on MS forum.

@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

Can you run dumpbin on that dll?

Dumpbin output of  CPUsideRDM.dll  attached. Dissembly ommitted in accordance with license agreement.


Downloadtext/plain dumpbin.txt188.88 KB

Can you send me that file via private messaging.

Thanks in advance.

Sorry, that would be violating the license agreement. Could you not install Intel C++ Studio XE 2013 (included SP1 with update 1)  to get it?

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.

Ok, thanks for the help. Any word from Intel yet?

You are welcome.

Hopefully Intel devs will look at this annoying issue.

I have posted some information about this issue in this thread

Inge H., the workaround from Steve Lionel in topic 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.


Root cause of the stack overflow was MIC debugging integration.

Leave a Comment

Please sign in to add a comment. Not a member? Join today