Program crashes with 0xC000000D and no exceptions - how do I debug it?

5

I have a Visual C++ 9 Win32 application that uses a third-party library. When a function from that library is called with a certain set of parameters the program crashes with "exception code 0xC000000D".

I tried to attach Visual Studio debugger - no exceptions are thrown (neither C++ nor structured like access violations) and terminate() is not called either. Still the program just ends silently.

How does it happen that the program just ends abnormally but without stopping in the debugger? How can I localize the problem?

c++
winapi
debugging
visual-c++
asked on Stack Overflow Nov 22, 2010 by sharptooth

3 Answers

5

That's STATUS_INVALID_PARAMETER, use WinDbg to track down who threw it (i.e. attach WinDbg, sxe eh then g.

answered on Stack Overflow Nov 22, 2010 by Ana Betts
2

Other answers and comments to the question helped a lot. Here's what I did.

I notices that if I run the program under Visual Studio debugger it just ends silently, but if I run it without debugger it crashes with a message box (usual Windows message box saying that I lost my unsaved data and everyone is sooo sorry).

So I started the program wihtout debugger, let it crash and then - while the message box was still there - attached the debugger and hit "Break". Here's the call stack:

ntdll.dll!_KiFastSystemCallRet@0()  
ntdll.dll!_ZwWaitForMultipleObjects@20()  + 0xc bytes   
kernel32.dll!_WaitForMultipleObjectsEx@20()  - 0x48 bytes   
kernel32.dll!_WaitForMultipleObjects@16()  + 0x18 bytes 
faultrep.dll!StartDWException()  + 0x5df bytes  
faultrep.dll!ReportFault()  + 0x533 bytes   
kernel32.dll!_UnhandledExceptionFilter@4()  + 0x55c bytes
//SomeThirdPartyLibraryFunctionAddress
//SomeThirdPartyLibraryFunctionAddress
//SomeThirdPartyLibraryFunctionAddress
//SomeThirdPartyLibraryFunctionAddress
//OurCodeInvokingThirdPartyLibraryCode

so obviously that's some problem inside the trird-party library. According to MSDN, UnhandledExceptionFilter() is called in fatal situations and clearly the call is done because of some problem in the library code. So we'll try to work the problem out with the library vendor first.

answered on Stack Overflow Nov 25, 2010 by sharptooth
1

If you don't have source and debugging information for your 3rd party library, you will not be able to step into it with the debugger. As I see it, your choices are;

  • Put together a simple test case illustrating the crash and send it onto the library developer
  • Wrap that library function in your own code that checks for illegal parameters and throw an exception / return an error code when they are passed by your own application
  • Rewrite the parts of the library that do not work or use an alternative

Very difficult to fix code that is provided as object only

Edit You might also be able to exit more gracefully using __try __finally around your main message loop, something like

int CMyApp::Run() 
{
    __try
    {
        int i = CWinApp::Run();
        m_Exitok = MAGIC_EXIT_NO;
        return i;
    }
    __finally
    {
        if (m_Exitok != MAGIC_EXIT_NO)
            FaultHandler();
    }
}
answered on Stack Overflow Nov 22, 2010 by SmacL • edited Nov 22, 2010 by SmacL

User contributions licensed under CC BY-SA 3.0