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

[support]

Hi,

It should not be dependent on the project type. The size is always displayed in bytes for very small values, and then gets rounded to KB.

[support]

Hi,

The STM32CubeMX-based projects are based on the Advanced CMake project subsystem, hence their settings follow the layout described here: https://visualgdb.com/documentation/projects/cmake/#settings.

[support]

Thanks for renewing your license.

The spell checker is a part of the regular VC++ IntelliSense engine. It is less accurate then the Clang-based IntelliSense provided by VisualGDB, and only works with MSBuild and GNU Make projects (not advanced CMake). You can switch between Clang Intellisense and regular VC++ IntelliSense as shown here.

Another option would be to enable the Clang’s spell checker by adeding “-fspell-checking” to VisualGDB Project Properties -> IntelliSense Settings -> Additional flags for C/C++ files, and also to the RelevantCFLAGS field in %VISUALGDB_DIR%\CppEngineTuningInfo.xml. That said, there is very little information available on Clang’s spell checker, and it doesn’t seem to be very popular.

Yet another option would be to use a stand-alone command-line spell checker, and create a custom shortcut to run it (VisualGDB Project Properties -> Custom Shortcuts). This way you could run it via a menu command in Visual Studio or the VisualGDB toolbar.

[support]

Hi,

The Arduino-based projects are built using arduino-builder.exe – a tool that comes from the Arduino IDE and handles all the build logic. We forked it to produce accurate IntelliSense information, but did not change anything else.

You can try capturing the arduino-builder command line as shown here and building the project manually. Is it still slow? Does the command line in Arduino IDE look different?

Also please note that most slowness issues are caused by external factors (e.g. slow antivirus, slow system drive where the Arduino libraries are placed). E.g. if you whitelisted the Arduino IDE in the antivirus, you would need to whitelist Visual Studio in the same place.

[Author]

Posts