locked
VS 2013/2015: "Internal error" catching exceptions in OnLoad RRS feed

  • Question

  • Hi,

    I guess, we all still remember this problem:

    The case of the disappearing OnLoad exception 

    I'm using Win7/64. The problem above is not an issue anymore. However, this seems to be true for VS 2008 only: If I run a project from within VS 2008 and an exception occurs in OnLoad, the exception is caught by the IDE. This applies to 32 and 64 bit processes.

    Now, using VS 2013 or 2015, I seem to have my first exception inside OnLoad. The IDE does not catch it. Instead, if 32 bits, I get the following message before confirming it and the process closes:

    (Internal error. Unhandled exception in Debugger::HandleIPCEvent. Event ID=0x246, etc.)

    If 64 bits, I do not get this message. Instead, the process silently quits.

    Do we have to bother again with this problem in 2016 now? (or go back to VS 2008?)

    • There is no difference with and without the vs hosting process active.
    • The problem is only there in OnLoad, not at other locations like a button's click event handler.
    • If I run the Exe standalone, have Windows' error dialog pop up, select "Debug" to attach either the VS 2013 or 2015 debugger, it seems to be handled well, i.e. the current source line is highlighted and the exception assistant is shown.
    • The search results in the web all seem to treat the cause of the exception of the debuggee, not the cause of the exception in the debugger. I've also found problem reports about it at connect.microsoft.com, but nothing really helpful.

    Before reporting it, is this my machine specific problem, or can you reproduce it? Just throw an exception in OnLoad if you'd like to test it. Thanks!

    EDIT: If I switch the project's target framework from 4.5 (default) to 3.5, it works again! However, this can not be a solution.


    Armin


    Saturday, January 30, 2016 12:52 PM

Answers

All replies

  • This is what I get:

    x86

    x64

    Windows 10 10.0.10586,
    VS Version 14.0.24720.00 Update 1,
    Microsoft .NET Version 4.6.01038

    No warranty
    With kind regards
    Monday, February 1, 2016 10:13 AM
  • 40 seconds video showing the problem:

    http://1drv.ms/1JUhBnt



    Armin

    Tuesday, February 2, 2016 1:52 AM
  • This is what I get:

    Ok, thanks. So, everything correct in x86 but silent exit in x64 with an access violation, if I see this correctly.


    Armin


    Wednesday, February 3, 2016 11:31 PM
  • Unfortunatelly, we can not attach another debugger to catch the problem in the debugger, because the message I get (see screenshot) is not from devenv.exe but from the debugee.

    Armin

    Wednesday, February 3, 2016 11:33 PM
  • Ok, thanks. So, everything correct in x86 but silent exit in x64 with an access violation, if I see this correctly



    Ah yes, x86 seems correct.
    I have no idea, to get hold of the access-violation, when debugging x64 -
    'Enable native code debugging' (x64) shows only
    "'An unhandled exception of type 'System.ApplicationException' occurred in VBForm1.exe"
    but not the access-violation. Same in windbg. -
    x86 (managed debugging) does not show the dialog-box with the exception in clr!Debugger::HandleIPCEvent on this box, but stops as expected.
    Regarding your 'Debugger::HandleIPCEvent' dialog, I'd try to get a dump manually with task-manager or procdump, assuming the process exists as long the dialog is open. Probably one gets at least a stack for this.

    With kind regards


    Thursday, February 4, 2016 10:22 AM
  • This is really amazing... They put so much effort into exception propagation & unwinding for x64 - and it still does not work for important code path??

    -- pa

    Thursday, February 4, 2016 2:40 PM
  • Just came into my mind, getting stack for Debugger::HandleIPCEvent:
    Windbg can 'Attach to Process' 'Noninvasive' to an already debugged process.
    Sysinternals 'Process Explorer' is also able to show thread-stacks.

    With kind regards

    Thursday, February 4, 2016 5:19 PM
  • Just came into my mind, getting stack for Debugger::HandleIPCEvent:
    Windbg can 'Attach to Process' 'Noninvasive' to an already debugged process.
    Sysinternals 'Process Explorer' is also able to show thread-stacks.

    That's a good hint. However, as I can not execute code in Windbg then, I can only break into the error message box (as in my 1st post) and look at the call stack. It's an unmanaged thread. Well, in the end..... it doesn't help because we would need someone to fix this! :) I'll post a bug report later.

    USER32!NtUserWaitMessage+0x15
    USER32!DialogBox2+0x222
    USER32!InternalDialogBox+0xe5
    USER32!SoftModalMessageBox+0x757
    USER32!MessageBoxWorker+0x269
    USER32!MessageBoxTimeoutW+0x52
    USER32!MessageBoxExW+0x1b
    USER32!MessageBoxW+0x18
    clr!LateboundMessageBoxW+0x3b
    clr!MessageBoxImpl+0x2b0
    clr!UtilMessageBoxNonLocalizedVA+0x319
    clr!UtilMessageBoxNonLocalizedVA+0x1b
    clr!UtilMessageBoxVA+0x8c
    clr!UtilMessageBoxCatastrophicVA+0x31
    clr!EEMessageBoxCatastrophic+0x16
    clr!_debugFilter+0x3e
    clr!HandleIPCEventWrapper+0x44
    MSVCR120_CLR0400!_EH4_CallFilterFunc+0x12
    MSVCR120_CLR0400!_except_handler4_common+0x8d
    clr!_except_handler4+0x1e
    ntdll!ExecuteHandler2+0x26
    ntdll!ExecuteHandler+0x24
    ntdll!RtlDispatchException+0x127
    ntdll!KiUserExceptionDispatcher+0xf
    clr!IsUnmanagedToManagedSEHHandler
    clr!GetNextCOMPlusSEHRecord+0x14
    clr!GetClrSEHRecordServicingStackPointer+0x37
    clr!DebuggerExState::SetDebuggerInterceptInfo+0x45
    clr!Debugger::GetAndSendInterceptCommand+0x262
    clr!Debugger::HandleIPCEvent+0xc15
    clr!HandleIPCEventWrapper+0x23
    clr!DebuggerRCThread::HandleRSEA+0x88
    clr!DebuggerRCThread::MainLoop+0xda
    clr!DebuggerRCThread::ThreadProc+0xcb
    clr!DebuggerRCThread::ThreadProcStatic+0xb9
    KERNEL32!BaseThreadInitThunk+0xe
    ntdll!__RtlUserThreadStart+0x70
    ntdll!_RtlUserThreadStart+0x1b



    Armin

    Monday, February 8, 2016 4:16 PM
  • But it's nice that it already worked in VS 2008 (32 and 64 bits). ^^

    Armin

    Monday, February 8, 2016 4:18 PM
  • Hi Armin,

    Thanks for your friendly response.

    >> it doesn't help because we would need someone to fix this! :) I'll post a bug report later.

    If you submit a feedback to the connect report team, please share us the link here, so other members who get the same issue would help you vote it. I will also help you follow up your connect report.

    Best Regards,

    Jack


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Tuesday, February 9, 2016 10:01 AM
  • >> it doesn't help because we would need someone to fix this! :) I'll post a bug report later.

    If you submit a feedback to the connect report team, please share us the link here, so other members who get the same issue would help you vote it. I will also help you follow up your connect report.

    Hi Jack,

    I've submitted feedback:

    https://connect.microsoft.com/VisualStudio/feedback/details/2340136

    Meanwhile, I've fixed the cause of the exception in OnLoad in my code. ;)


    Armin

    Tuesday, February 9, 2016 2:00 PM