Visual Studio Crashes when Debugger Stops

Sysprogs forums Forums VisualGDB Visual Studio Crashes when Debugger Stops

This topic contains 9 replies, has 2 voices, and was last updated by  support 5 days, 15 hours ago.

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #33650

    kurt123
    Participant

    Hi there,

    I am experiencing an issue where every time I stop my Visual GDB debugger, Visual Studio crashes and immediately restarts. I am running VisualGDB Embedded Edition (version 5.6R9 build 4777), Visual Studio Community 2022 (version 17.4.3), and a Segger J-Link ARM V11.00.

    I’ve tried reinstalling Visual GDB (including the previous version) but have had no success.

    Also, here is the output from the end of my log file:

    Does anyone have any thoughts on how I should go about fixing this? I would greatly appreciate the help.

    Thank you,

    Kurt

    #33651

    support
    Keymaster

    No problem, please try attaching a debugger to the devenv.exe process and capturing a stack trace of the crash as shown here:  https://visualgdb.com/support/callstack

    #33687

    kurt123
    Participant

    Hi there,

    Here is the Visual Studio call stack just before the crash, when Visual Studio hangs. Sorry for the delay.

     

    • This reply was modified 2 weeks, 3 days ago by  kurt123.
    #33689

    support
    Keymaster

    Hi,

    This doesn’t look like a crash – it looks like you are ending the GDB session, VisualGDB sees that gdb is not responding, and shows the “GDB Command Timeout” window.

    Did you obtain this call stack by manually pausing the VS process (Debug->Break all), or did it stop with an exception? In the latter case, could you share the full exception message?

    #33693

    kurt123
    Participant

    Hi,

    You are correct. I end the GDB session and the GDB exit command times out. When I click “stop debugging” to forcibly end the debugger, that’s when the crash happens. For the previous stack trace I manually paused Visual Studio on the timeout message.

    I would like to get the VS stack trace after I press “stop debugging”, but the VS instance doesn’t halt, meaning that the second VS instance never gets a chance to get the threads/call stack.

    I’ve attached a picture of the error message, too.

    What are your thoughts on this?

     

    Attachments:
    You must be logged in to view attached files.
    #33695

    kurt123
    Participant

    Update: enabling “asynchronous GDB mode” might have fixed the crashing. This is odd though since I’m using an embedded application and the note about async mode says that embedded environments don’t support async mode.

    #33696

    kurt123
    Participant

    Enabling “asynchronous GDB mode” did not fix it 🙃

    #33706

    support
    Keymaster

    If the inner VS instance crashes without reporting anything to the outer one, you have likely selected an incorrect debug engine when attaching the outer VS instance to it.

    Please try selecting both “Native” and “Managed (.Net 4.x)” as the debug engines in the Attach dialog. This should catch crashes caused by both managed and native code.

    #33754

    kurt123
    Participant

    Sorry for the slow update here.

    I resolved the issue by re-cloning my git repository. I’m guessing there is a VS/Visual GDB config file somewhere that is not being tracked.

    #33755

    support
    Keymaster

    No worries and thanks for the update. If resetting the repository solved the issue, it was likely caused by corrupt VS-level or VisualGDB-level cache (although VisualGDB-level issues are usually visible on the call stack).

    Either way, if you weird intermittent behavior again, you can simply try deleting the .vs and .visualgdb subdirectories – it should have the same effect as re-cloning the repository, but you won’t need to do a full rebuild.

Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.