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.

Log In Register Lost Password
Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • January 9, 2023 at 15:13 #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

    January 9, 2023 at 15:15 #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

    January 12, 2023 at 13:45 #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.
    January 12, 2023 at 13:50 #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?

    January 13, 2023 at 08:46 #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.
    January 13, 2023 at 08:57 #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.

    January 13, 2023 at 09:27 #33696

    kurt123
    Participant

    Enabling “asynchronous GDB mode” did not fix it 🙃

    January 16, 2023 at 16:53 #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.

    January 24, 2023 at 12:22 #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.

    January 24, 2023 at 12:26 #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.

  • Author
    Posts
Log In Register Lost Password
Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.