[support]

It looks like your technical support period has expired. We would be happy to help you, however we would kindly ask you to renew your technical support on the following page first: https://sysprogs.com/splm/mykey

[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?

[support]

Hi,

Sure, you can use the CMake platform/configuration GUI as shown here: https://visualgdb.com/tutorials/cmake/multiplatform/

[support]

Hi,

Sorry, we do not have any special support for LittleFS, but you should be able to achieve it via custom build steps and custom shortcuts.

[support]

Hi,

The ESP32 build is managed by the ESP-IDF build scripts. You would need to look through them to find out the details. A good starting point would be the <ESP-IDF>/tools/cmake directory.

[support]

Hi,

No problem, we have found and fixed the root cause. Turns out, the latest version of the ESP32 Arduino package started using the -iprefix/-iwithprefixbefore gcc options to pass include directories to gcc. We have not seen anyone else use them before, so they were not supported by VisualGDB.

We have added support for the options to this build: VisualGDB-6.1.103.5538.msi. It should now work out-of-the-box.

[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.

[support]

Hi,

No problem, we have updated our fork based on their latest tag and released an updated package. You can now install it via the VisualGDB Package Manager.

[support]

Hi,

This happens due to different default language standards between GCC/Clang. The easiest way to fix it is to explicitly select the C23 language standard in the project properties.

For CMake, that would be Target properties -> C/C++ -> Advanced -> Language Standard for C files -> C23, or directly in CMakeLists.txt:

set_property(TARGET EmbeddedProject1_bool PROPERTY C_STANDARD 23)

[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.

[support]

Hi,

Based on our experience with the ESP32 devices, we would advise using the Espressif’s OpenOCD fork (or our fork of their fork that adds minor convenience features). You can try using the Segger software by patching %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.segger-dmsp\edp.xml (GNUTargetFilter) and opening VisualGDB Package Manager to reload the debug package list, but it may not work as expected.

[support]

It looks like your technical support period has expired. We would be happy to help you, however we would kindly ask you to renew your technical support on the following page first: https://sysprogs.com/splm/mykey

[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.

[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.

[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).

[Author]

Posts