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.
-
AuthorPosts
-
August 31, 2023 at 03:51 #34649
Hi,
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.
Thanks,
Jon.
August 31, 2023 at 11:52 #34653Hi
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: https://visualgdb.com/support/callstack
September 8, 2023 at 03:48 #34695Hi,
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:
C++123456789101112131415161718192021[Managed to Native Transition]> Microsoft.VisualStudio.Package.LanguageService.15.0.dll!Microsoft.VisualStudio.Package.LanguageService.RefreshUI() Line 924 C#Microsoft.VisualStudio.Package.LanguageService.15.0.dll!Microsoft.VisualStudio.Package.LanguageService.OnParseComplete(Microsoft.VisualStudio.Package.ParseRequest req) Line 919 C#VisualGDBPackage2022.dll!a43.l2(Microsoft.VisualStudio.Package.ParseRequest a) UnknownWindowsBase.dll!System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate callback, object args, int numArgs) UnknownWindowsBase.dll!System.Windows.Threading.ExceptionWrapper.TryCatchWhen(object source, System.Delegate callback, object args, int numArgs, System.Delegate catchHandler) UnknownWindowsBase.dll!System.Windows.Threading.DispatcherOperation.InvokeImpl() UnknownWindowsBase.dll!MS.Internal.CulturePreservingExecutionContext.CallbackWrapper(object obj) Unknownmscorlib.dll!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) Unknownmscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) Unknownmscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) UnknownWindowsBase.dll!MS.Internal.CulturePreservingExecutionContext.Run(MS.Internal.CulturePreservingExecutionContext executionContext, System.Threading.ContextCallback callback, object state) UnknownWindowsBase.dll!System.Windows.Threading.DispatcherOperation.Invoke() UnknownWindowsBase.dll!System.Windows.Threading.Dispatcher.ProcessQueue() UnknownWindowsBase.dll!System.Windows.Threading.Dispatcher.WndProcHook(System.IntPtr hwnd, int msg, System.IntPtr wParam, System.IntPtr lParam, ref bool handled) UnknownWindowsBase.dll!MS.Win32.HwndWrapper.WndProc(System.IntPtr hwnd, int msg, System.IntPtr wParam, System.IntPtr lParam, ref bool handled) UnknownWindowsBase.dll!MS.Win32.HwndSubclass.DispatcherCallbackOperation(object o) UnknownWindowsBase.dll!System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate callback, object args, int numArgs) UnknownWindowsBase.dll!System.Windows.Threading.ExceptionWrapper.TryCatchWhen(object source, System.Delegate callback, object args, int numArgs, System.Delegate catchHandler) UnknownWindowsBase.dll!System.Windows.Threading.Dispatcher.LegacyInvokeImpl(System.Windows.Threading.DispatcherPriority priority, System.TimeSpan timeout, System.Delegate method, object args, int numArgs) UnknownWindowsBase.dll!MS.Win32.HwndSubclass.SubclassWndProc(System.IntPtr hwnd, int msg, System.IntPtr wParam, System.IntPtr lParam) Unknown-
This reply was modified 3 weeks, 4 days ago by
support. Reason: formatting
September 8, 2023 at 10:35 #34697Hi,
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.
September 12, 2023 at 03:43 #34705Thanks, will give it a go.
-
AuthorPosts
You must be logged in to reply to this topic.