Optimizations disable JitDebugging


  • Hi,

    whenever an exception occurs inside my application (x64, Target Framework 4.5) without a debugger being attached, the JitDebugging dialog is shown:

    The setting mentioned in the dialog has already been set in all machine.config files, and additionally in the application.exe.config file. Still that dialog is shown. I expect the dialog to chose a debugger to be shown instead.

    This happens only in the release version, not in the debug version. After narrowing the problem down, the difference is whether "optimizations" are set in the project properties. So, with optimizations enabled, jit debugging does not work.

    This happens when compiling with VS 2015 and VS 2017. The problem doesn't exist if compiling with VS 2013. Where's the difference and how to solve this?



    Saturday, March 11, 2017 10:58 AM


All replies

  • To find out the difference, I've dumped the IL code of the executables built by the three versions (2013, 2015, 2017) to files and compared them. However, there are a trillion differences, so this attempt is a dead end.


    Saturday, March 11, 2017 11:53 AM
  • Hi Armin,

    Does this happen with any exception, or is there a particular exception you have been testing?  Is it possible that the cause of a particular exception is removed with the optimization?  Or does the program still close unexpectedly, just without giving the dialog?

    I assume that there is no code in the application's unhandled exception event, is that correct?

    You might want to try a Visual Studio forum or file an issue on Connect if no one here has any ideas.

    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"

    Saturday, March 11, 2017 9:22 PM
  • Hi Reed and Cor,

    yes, I was just about to write that I saw myself this might not be the right forum. First it seemed to be VB realted, but it seems it's not. Hm, don't know if a VS forum or the "Windows Desktop debugging" forum is the best one. Almost no traffic there. :/  Anyway, sorry for bothering. (Edit: before, I'll try to dig into it more myself...) Edit #2: Always nice to see you guys again. :)


    Saturday, March 11, 2017 11:27 PM
  • (FYI:

    This was a turbulent journey since yesterday. Long story short:

    Implicitly, there is the DebuggableAttribute attached to the assembly. If I examine it right at the start of Sub Main, it's property value of "IsJITTrackingEnabled" is True in the Debug build, whereas it's False in the Release build. This value is taken into account inside System.Windows.Forms.NativeWindow.AdjustWndProcFlagFromMetadata, which is called when initializing System.Windows.Forms.NativeWindow.wndProcFlags.

    If one of the bits (0x4) of wndProcFlags is set, windows message processing is done without exception handling. Otherwise, messages are processed within a try..catch block. If an exception occurs, OnThreadException is called. (source)

    Within OnThreadException, if there are no exception handlers attached, the thread exception dialog as I've shown in the first posting is displayed.

    So. What remains is the question: Why is that "IsJITTrackingEnabled" property set to False in a Release build? I've checked the IL code of the Debug and the Release build. For the Release build it says:

      // --- The following custom attribute is added automatically, do not uncomment -------
      //  .custom instance void [mscorlib]System.Diagnostics.DebuggableAttribute::.ctor(valuetype [mscorlib]System.Diagnostics.DebuggableAttribute/DebuggingModes) = ( 01 00 02 00 00 00 00 00 ) 

    In the debug build, the values at the end are " ( 01 00 07 01 00 00 00 00 )". A bit confusing is that this attribute is commented.

    What happens is the default behavior. We can override it by calling


    before creating any window. However, I consider it a workaround only. I do not know why active optimizations must enforce this behavior.


    EDIT: Of course this could be moved to a different forum. No clue which one.


    Sunday, March 12, 2017 7:35 PM
  • After verifying this issue, problem reported.


    • Marked as answer by Armin Zingler Monday, March 13, 2017 1:30 PM
    Monday, March 13, 2017 1:26 PM
  • After verifying this issue, problem reported.
    As MSFT connect has been retired, where did all the open issues go? Alle the links to specific topics don't work anymore? Good move...


    Friday, February 16, 2018 1:28 PM
  • Did we not have some experience with newsgroups

    If you currently look how the forums are organized it is as well weird, some are in the Azure group, some in the Microsoft development group (windows and azure) and some in the Microsoft Development group, but that is than Visual Studio currently, although I'm not sure of this, can be changed an hour ago. 


    Friday, February 16, 2018 5:34 PM
  • IMO, this company has become are scatterted something.

    (OT: I'm using the umatrix browser plugin to control access to domains etc. Only on Microsoft sites, I have to grant access to many different domains until one single page works correctly. Examples?,,,,,,,,,,,,,,,,,,,,, Just an indication...)

    Duplicate content on different servers. No clue where to go to anymore. I've seen there is now. And why do I need google-analytics to be able to click on Visual Studio? Just asking dumb questions... Is this the new MSDN? Or does it exist in parallel? IMO, MSFTs whole web presence needs a reboot. (just saying ;) )

    It was an impudence if all open issues would not have been migrated and users would not even have been informed about it in advance. I can not even search for it in order to reopen it on the new platform. Making it readonly would have been an option, but things suddenly disappear... (IF it's true)

    All that happens to this is... being postponed.

    Hope you're doing well, Cor.


    Wednesday, February 21, 2018 2:26 AM