Forum Replies Created
-
Posts
-
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.
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:
- 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?
- If not, try working normally, and after about 1 hour of work, try sleeping/resuming. Does it trigger?
- 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.
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).
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.
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.
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.
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.
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
Hi,
This is to be expected. VisualGDB manages toolchains and BSPs by generating %LOCALAPPDATA%\VisualGDB\FindXXX.props files that have a structure like this:
- If (ID = ‘xxx’ and VERSION = ‘yyy’)
- Include <toolchain-specific .props file>
- If (…)
If you are running MSBuild from a different user account, the files will not be present in %LOCALAPPDATA%, and MSBuild will not load the correct toolchain properties.
The easiest workaround would be to simply run the Jenkins task from the same user account (in Jenkins parameters, or using runas). This will automatically pull toolchains, BSPs, licensing information, etc.
If you absolutely have to use another account, you would need to manually copy the .props files (and possibly, other files like the test frameworks). These files are located under %LOCALAPPDATA%\VisualGDB, so copying the entire directory could be a good starting point.
You can also configure VisualGDB to generate batch files for unattended building as shown here. This way, the projects can be built in the test environment without having to install VisualGDB there.
OK, thanks for your patience. The 6.1 release is out, so we are back to adding new features.
Currently, switching between the projects works out-of-the-box, as long as they are separate projects on the Visual Studio level (e.g. MSBuild, Legacy GNU Make). The GUI for switching is similar to the regular Visual Studio’s one:
It will not work for Advanced CMake projects where the same file would be reported by multiple targets within the same project. If you need support for this case, let us know and we will add a special check for this.
Hi,
No problem, we should be able to add a setting for this. We are currently running the final tests on the 6.1 release and will look into this soon after. We should be able to post an update in about a week.
No worries. BTW, the other STM32 packages passed the remaining tests and have been released as well.
We also caught a glitch in the CMake logic of v6.1 that would interfere with the default FreeRTOS port selection. It has been fixed in this build: VisualGDB-6.1.101.5501.msi
No problem and thanks for your patience.
We have just released an updated BSP for STM32H7RS. You can install it via the VisualGDB Package Manager as usual. We would also recommend updating to this VisualGDB build: VisualGDB-6.1.101.5500.msi. It’s the release candidate for v6.1 that has been tested with the new BSPs.
We also released updated ARM toolchain (GCC 15.2) and updated OpenOCD (regular + ST fork). Packages for the other STM32 families will be released tomorrow, after they pass the final test run.
No problem. In our experience the GNU demangler is a few GCC releases behind the GCC itself. So, there’s a good chance that it will work better with GCC 16.0 or 17.0. You can try checking c++filt whenever a new GCC release comes out, and if it works better, we can easily rebuild our demangler using the same gcc version.
Hi,
Sorry for the delay. There is no automatic way to update the project to an arbitrary GitHub version of the HAL. You can convert the project to a fully-custom one, and manually replace the relevant files, but it is not guaranteed to work and may require some manual adjustments.
Automatic one-click updates work for the HAL versions that have been tested by us and released as BSP packages. We are working on a major update to the STM32 BSP system that separates the BSPs for different device families (e.g. STM32H7 vs F4), resolving many glitches caused by slightly different versions of FreeRTOS, AzureRTOS, etc. between the device families. We were originally expecting to release the update yesterday, but there are still a few glitches left to fix on our side. Unless we discover anything completely unexpected, the BSPs should be ready to download in the next couple of days.
