[support]

Hi,

It can be a glitch related to first installing an early preview of VS2026, and then upgrading it to the latest stable one. VisualGDB installer finds the latest MSBuild version with a non-empty Platforms subdirectory, and copies its platform files alongside the default platforms. This normally matches the Visual Studio’s default mechanism for finding the platform files.

It is difficult to say why it would look for the files in a different location this time, but copying/symlinking the VisualGDB platform to a different MSBuild version should work just fine.

If anyone else encounters the same problem, feel free to post here, and we will investigate it further.

[support]

Hi,

This means that the MSBuild files are missing from the VS installation. You can confirm it by trying to create a regular Win32 C++ project (non-VisualGDB) – it should be either missing, or would run into the same problem.

Installing Visual C++ project support via the VS installer should fix it. You can also use CMake-based projects instead, as they do not rely on MSBuild.

[support]

Thanks for sharing this.

[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

[Author]

Posts