JIT debugger is not initiated after exception in unmanaged library used by managed application.

Question

I want for JIT debugger to catch exception in unmanaged library.

I have "Attempted to read or write protected memory" exception in unmanaged dll. If I execute MFC application using faulty library JIT debugger kicks in and everything is ok - I can start debugging via VS and so on. But if I run managed application which uses the same unmanaged dll only the plain error popup is shown.

Any suggestions?

Answer 1

turn on "enable unmanged code debugging" in the project properties of the project that produces the .exe which later loads the unmanged code dll.

WM_HOPETHISHELPS
-thomas woelfer

---

http://www.die.de/blog

Answer 2

Hello Aleksas,

Would you please tell us what do you want to see? The exception message specified in unmanaged code will not be popped up.

As far as I know, most unmanaged exceptions will be thrown as System.Runtime.InteropServices.SEHException in managed world. That's because CLR does not know about all the SEH exception code that currently exists. Only few of them are mapped to managed exceptions, for example, a STATUS_NO_MEMORY exception is mapped to OutOfMemoryException, while a STATUS_ACCESS_VIOLATION is mapped to NULLReferenceException/AccessViolationException. But in MFC projects, C++ exception is available.

However, as thomas_woelfer suggestted, we could enable unmanaged code debugging to debug into the unmanaged code to see where does the exception occurred.

For the detailed information about how CLR maps SEH exceptions to managed exception types, please refer to:
http://blogs.msdn.com/clrteam/archive/2009/05/14/how-clr-maps-seh-exceptions-to-managed-exception-types.aspx

Best regards,

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
If you have any feedback, please tell us.
Welcome to the All-In-One Code Framework!

Answer 3

What I want to see is a JIT debugger popup when error occurs. 

Now I get only error message window with single OK button. This is only the case when faulty library is used by managed application, doesn't matter if compiled in debug mode or release with Unmanaged code debugging  enabled in both cases. If used by unmanaged applications JIT debugger pops up as mentioned before. I tested same library with plain C console application - same result - JIT debugger kicks in.

So why JIT debugger does't catch the error when I run managed application?

Answer 4

Hello Aleksas,

Thanks for your feedback and I got the key point now.
I suspect that the exception is thrown by the C++ runtime library, right?
As I said in my previous reply, most unmanaged exception will be mapped to SEHException in CLR, hence, to let the CLR know the exception, we may need to use a try-catch block and throw the SEHException again. Would you please post a code snippet of your code?

By the way, an additional App.config file is needed for our application. Please add an App.config file and make sure there is a section as below exists:
<configuration>
  <system.windows.forms jitDebugging="true"/>
</configuration>

Best regards,

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
If you have any feedback, please tell us.
Welcome to the All-In-One Code Framework!

Answer 5

The code snippet raising error:

int __stdcall RaiseError()
{
	int a[2];
	int * b;
	a[234] = 34;
	b[2234234] = 334;
	b[34534543] = 234;
}

Of course  the code is written this way on purpose to raise error.  I did it to test debug symbol usage in VisualStudio together with SymbolServer.

Tried adding app.config before and did it once again - same problem. 

Faulty library is written in plain C. Functions are called from managed code by wrapping unmanaged dll functions using DllImport.

Some Unmanaged Library Project properties:

Use of MFC: Use standard Windows Libraries

Use of ATL: Not using atl

compiler command parameters for library:

/O2 /GL /I "..\..\Include" /D "WIN32" /D "NDEBUG" /D "N_PREPROCESSED" /D "_WINDLL" /D "_UNICODE" /D "UNICODE" /FD /EHsc /MT /Fo"obj\Win32\Release\\" /Fd"obj\Win32\Release\vc90.pdb" /W4 /nologo /c /Zi /TP /errorReport:prompt

linker parameters:

/OUT:"C:\Documents and Settings\alex\My Documents\Visual Studio 2008\Projects\DebugTest\/bin\Win32_x86\Release\MyLib.dll" /INCREMENTAL:NO /NOLOGO /DLL /MANIFEST /MANIFESTFILE:"obj\Win32\Release\MyLib.dll.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEF:"obj\Win32\Release/MyLib.def" /DEBUG /PDB:"c:\Documents and Settings\alex\My Documents\Visual Studio 2008\Projects\DebugTest\bin\Win32_x86\Release\MyLib.pdb" /OPT:REF /LTCG /DYNAMICBASE /NXCOMPAT /IMPLIB:"C:\Documents and Settings\alex\My Documents\Visual Studio 2008\Projects\DebugTest\/lib\Win32_x86\Release\MyLib.dll.lib" /ERRORREPORT:PROMPT kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib

Answer 6

Hello,

JIT debugging is supported by Visual Studio Standard edtion or higher, could you please tell us which version do we have? Also, to make sure that we installed the JIT debugger, please go and check the following registry keys (for 32bit machines):
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\DbgManagedDebugger

For more information about JIT debugging, please refer to:
http://msdn.microsoft.com/en-us/library/5hs4b7a6(VS.80).aspx

Best regards,

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
If you have any feedback, please tell us.
Welcome to the All-In-One Code Framework!

Answer 7

I have VS2005Pro and VS2008Pro installed.

Adding app.config solved the problem for Debug configuration, but not for release.  

I 've found the solution in the following thread: 

http://social.msdn.microsoft.com/Forums/en-US/netfxtoolsdev/thread/9dc0126a-3b39-46c6-bd15-44c130cbeb48

Cited:

"In a release build of your application, the JITDebugLaunchSettings will not be respected. So, if you want WinForms to respect the NetFramework debugging registry keys regardless of the type of build, call Application.SetUnhandledExceptionMode ( UnhandledExceptionMode.Throw) in Main() prior to Application.Run(…).  This will mitigate the issues you are currently seeing with your release builds. However, it does have some side-effects. If you have added an event handler for Application.ThreadException (applies to exceptions from the UI thread) this will not be called."