VGDB 6.1 Freezes visual studio 2022

[vdl]

After updating to 6.1 my visual studio 2022 starts to freeze from time to time. Only for stm32 project ( i have esp32 project opened in other visual studio – no problem with that. also regular c/c# projects dont freeze )

It does not matter if project is running or stopped. After some time vs stops responding to mouse/keyboard – it does not freeze/hung up – content is still displayed. I tried to resize window via windowse tool – content is still refreshed.

[support]

Hi,

Sorry about that. We have heard a few similar reports from other users, and asked to provide some details, but have not heard back from anyone yet. We will be more than happy to fix this, as long as anyone could provide the diagnostic information needed to narrow it down.

Next time Visual Studio freezes, could you please try attaching a debugger to it as shown here, and capturing the call stack along with the exact build number from Help->About VisualGDB? It would also help if you could share more context (e.g. you started VS, opened a project, switched to something else for 10 minutes, and then VS froze).

[vdl]

vgdb 6.1 build 5512

yesterday i left project opened ( not running ) today its frozen

attached thread info

Attachments:

You must be logged in to view attached files.

[support]

Thanks for the call trace. The auxiliary thread waiting for the IPC socket is unrelated. It’s used for communicating with the IntelliSense engine, that runs in a separate process so it can’t crash VS itself.

The main thread stack, however, looks like VS is locked up trying to handle a system notification (OnUserPreferenceChanged). We just had another user mention that the freezing appears to happen when the system goes to sleep. We’ve just tried reproducing it in our test environment, but it did not trigger, so it must be something more specific.

Could you please try the following:

1. Start a new VS instance and open a project. Immediately after it is open, put the system in and out of sleep. Does it trigger the problem?
2. If not, try working normally, and after about 1 hour of work, try sleeping/resuming. Does it trigger?
3. If yes, try opening Visual Studio again, and doing some steps that you could have done before (building the project, debugging it, etc.) and then sleeping/resuming. Does doing any particular step (e.g. editing properties) before the sleep/wake cycle trigger the problem?

You can also try walking the call stack of the main thread, and checking the locals window. If it mentions and VisualGDB-related types in any of the variables (specifically, WinForms-based controls), it could provide a clue for us to investigate further.

[vdl]

not connected to sleep in my case. just happened while i was working with different window/software ( vs in background ) – so sleep was not triggered. also locking/unlocking session does not trigger bug ( at least right away after opening project )

tried to debug using this – https://learn.microsoft.com/en-gb/archive/blogs/dsui_team/debugging-windows-forms-application-hangs-during-systemevents-userpreferencechanged

so far got nowhere

[support]

OK, we looked into the recent changes done on our side and found a potential cause for this.

VS2026 changed the way it handles internal build requests (used to load the MSBuild project structure into the Clang IntelliSense) in a way that our old logic would just wait forever. You might have seen it with Beta 5 where the loading window for MSBuild would stay on forever and the syntax highlighting would be broken afterwards. Our fix changed the order in which the tasks are created, and one of the things that got moved was the “loading” form that would be sometimes created from a background thread.

Based on what the article says, this could have triggered the frozen GUI later when a system notification would arrive.

We have redesigned the logic for loading the project structure to avoid the temporary GUI altogether, so it should not trigger the issue anymore. Feel free to try this build: VisualGDB-6.1.101.5522.msi.

Unless anyone reports that the problem persists with the new build, we will release it next week as v6.1R2.

[vdl]

seems to be fixed

[support]

Thanks for confirming it. We have now released VisualGDB 6.1R2 that includes this fix, and also addresses a glitch with CMake property handling.

[Jensa]

I still seems to have some similar issues even with the R2.
Basically it seems to just be frozen when I come back to work in the morning after having the computer in hybernation overnight with VS running.
Looking at the main thread callstack I’m guessing it has to do with plugging it back into a docking-station with attached external monitor.

WindowsBase.dll!System.Windows.Threading.DispatcherSynchronizationContext.Wait(System.IntPtr[] waitHandles, bool waitAll, int millisecondsTimeout) Unknown
[Native to Managed Transition]
[Managed to Native Transition]
> mscorlib.dll!System.Threading.WaitHandle.InternalWaitOne(System.Runtime.InteropServices.SafeHandle waitableSafeHandle, long millisecondsTimeout, bool hasThreadAffinity, bool exitContext) Line 251 C#
mscorlib.dll!System.Threading.WaitHandle.WaitOne(System.TimeSpan timeout, bool exitContext) Line 187 C#
WindowsBase.dll!System.Windows.Threading.DispatcherOperation.DispatcherOperationEvent.WaitOne() Unknown
WindowsBase.dll!System.Windows.Threading.DispatcherOperation.Wait(System.TimeSpan timeout) Unknown
WindowsBase.dll!System.Windows.Threading.Dispatcher.InvokeImpl(System.Windows.Threading.DispatcherOperation operation, System.Threading.CancellationToken cancellationToken, System.TimeSpan timeout) Unknown
WindowsBase.dll!System.Windows.Threading.Dispatcher.LegacyInvokeImpl(System.Windows.Threading.DispatcherPriority priority, System.TimeSpan timeout, System.Delegate method, object args, int numArgs) Unknown
WindowsBase.dll!System.Windows.Threading.DispatcherSynchronizationContext.Send(System.Threading.SendOrPostCallback d, object state) Unknown
System.dll!Microsoft.Win32.SystemEvents.SystemEventInvokeInfo.Invoke(bool checkFinalization, object[] args) Unknown
System.dll!Microsoft.Win32.SystemEvents.RaiseEvent(bool checkFinalization, object key, object[] args) Unknown
System.dll!Microsoft.Win32.SystemEvents.OnDisplaySettingsChanging() Unknown
System.dll!Microsoft.Win32.SystemEvents.WindowProc(System.IntPtr hWnd, int msg, System.IntPtr wParam, System.IntPtr lParam) Unknown

Attachments:

You must be logged in to view attached files.

[support]

Hi,

There could be still other instances of the issue. The problem itself is very sneaky – an operation that used to work just fine for a decade (creating a WinForms form from a background thread) now starts a delayed monitoring task that will freeze the application later, when a system event arrives. Once the freeze happens, the original form is long gone, so it’s hard to track it down. The R2 fixed the most commonly triggered instance of the bug, but there can be others due to the sheer complexity of the VS thread model.

We have added special logging to VisualGDB that detects incorrectly created forms and creates log files under %LOCALAPPDATA%\VisualGDB\InvalidGUIThreadTraces.

Feel free to update to this build: VisualGDB-6.1.103.5538.msi. If it freezes again, feel free to check the trace directory for recent traces, and share them here, so that we could fix them as well.

[Jensa]

I don’t seem to get any traces, it has frozen twice for me now since I updated to that new build but that folder doesn’t exist for me.
The parent folder exists and contains a lot though with some recent changed files so I don’t think it’s a permission issue at least.

[support]

Thanks for the update. Could it be caused by a different extension then? The problem is very sneaky: any extension creating a Winforms window from a background thread within the VS process will cause VS to hang later when a system notification arrives. On our side, it started happening after we added a very specific workaround to the final v6.1, and this one got fixed in 6.1R2 after multiple users confirmed the issue.

We have not heard of anyone else reporting this after 6.1R2, so it could have a completely different cause. Have you encountered the issue before v6.1 or when not using VisualGDB at all?

[Jensa]

I don’t think it’s from another extension, I don’t really have that many others installed. Just “git extensions” and “Microsoft Child Process Debugging Power Tool” and they don’t really create any UI’s.
I never saw this sort of freezing issue until I updated to 6.1.

It didn’t happen for a while but this morning it was locked again when I woke up my PC from hibernation. Today I also had a total of 3 different VS instances running and it was only the one with an active VisualGDB target configuration that was locked. The other two was working fine, one is a pure Win32-Wdk project and the other was a Win32 solution but that contained some help projects that contains VisualGDB targets but not active in the active configuration. Unfortunately no logs from today either. But I did find two identical from a couple of days ago:

Time: 2026-03-19 17:24:39
Version: 6.1.103.1
Class: rq1
Trace:
at iz3..ctor
at rq1..ctor
at rq1.i
at sa1.c1
at sa1.l
at sa1+p.f
at System.Threading.ExecutionContext.RunInternal
at System.Threading.ExecutionContext.Run
at System.Threading.ExecutionContext.Run
at System.Threading.ThreadHelper.ThreadStart

[Author]

Posts