VisualGDB crashing VS2022 on one PC.

Sysprogs forums Forums VisualGDB VisualGDB crashing VS2022 on one PC.

This topic contains 4 replies, has 2 voices, and was last updated by  drjonem 3 weeks ago.

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
  • #34649



    I’ve recently been having a problem with VisualGDB causing VS2022 to crash on one PC:

    • Start VS
    • Open a VisualGDB prject that has been used before.
    • Project opens in last used layout but VS is unresponsive and silently shuts down after a couple of seconds.

    If I delete the .visualgdb and .vs folders and try again, VS opens the project fine and allows me to work. However, the next time VS is started with this project, the same thing hapens again.

    I can create a new VisualGDB project and that functions the same – works fine until I close VS and reopen when it will crash unless I delete .vs and .visualgdb first.

    This occurs with a mix of STM32, NXP MCUXpresso and Linux VisualGDB projects.

    Non-visualGDB solutions continue to work without problems.

    This is only occuring on one PC; my other build PC continues to work without issues with the same projects. Both PCs have latest VS2022 instaled and same VisualGDB packages. I have tried updating to VisualGDB v6.0 beta on the problematic machine but it has not improved the situation.

    VS does not generate any crash reports but just reports VisualGDB as the cause for the previous session ending unexpectedly.

    Please advise how to debug.






    No problem, we will try to help you. First of all, please try updating to VisualGDB 6.0 Beta 1. If the problem persists, please try obtaining a stack trace of the crash as shown here:




    Sorry for the delay responding, holidays got in the way!

    I am using 6.0 Beta 1.

    I have obtained a stack trace, (see below). Also, when having the debugger attached, it reported this exception:

    System.AccessViolationException: ‘Attempted to read or write protected memory. This is often an indication that other memory is corrupt.’

    Stack trace:

    • This reply was modified 3 weeks, 4 days ago by  support. Reason: formatting



    Thanks for the stack trace. The crash actually happens inside the Visual Studio’s own language service assembly that implements helper functions for IntelliSense back-ends. It is hard to say what exactly triggers it, but AccessViolationException typically indicates corrupt DLLs somewhere.

    Doing a fresh complete reinstall of VS should normally fix it.




    Thanks, will give it a go.

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

You must be logged in to reply to this topic.