System.Exception: VisualGDB Host is not initialized properly

[Timo]

When opening existing projects from my company, i always get the following message in my output log:

error: Designtime build failed for project ‘<path to project>’, configuration ‘Debug|VisualGDB’. IntelliSense might be unavailable.
Set environment variable TRACEDESIGNTIME=true and restart Visual Studio to investigate.

Likewise, every time i switch configurations, i get flooded with dozens of

error : Designtime build failed for project ‘<path to project>’ configuration ‘Release|VisualGDB’. IntelliSense might be unavailable.
Set environment variable TRACEDESIGNTIME = true and restart Visual Studio to investigate.

A fresh new project does not seem to have this problem.

If i set the variable mentioned, the log file created ends with this error:

Assembly loaded during TaskRun (Sysprogs.Build.Tasks.ResolveGNUIncludeDirectories): Microsoft.GeneratedCode, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null (location: , MVID: ad2b3579-2626-4ec2-9313-39e0b1670340, AppDomain: [Default])
VisualGDBCore version: 6.1.103.5547
System.Exception
System.Exception: VisualGDB Host is not initialized properly
at bd4.c()
at bd4.d(ProjectSettingsFileInfo b, Boolean a)
at VisualGDB.MSBuild.BuildHelper..ctor(String vgdbSettingsFile, String projectNameOrFile, IDELevelProjectInfoForBuilding info, ISimpleFormattedBuildLogLineSink rawSink, MSBuildActionType type, EventWaitHandle abortEvent)
at Sysprogs.Build.Tasks.ResolveGNUIncludeDirectories.Execute()
trace=[bd4.c:107, bd4.d:0, VisualGDB.MSBuild.BuildHelper..ctor:39, Sysprogs.Build.Tasks.ResolveGNUIncludeDirectories.Execute:295]
C:\Program Files (x86)\Sysprogs\VisualGDB\MSBuild\SysprogsPlatform.targets(239,2): error : VisualGDB Host is not initialized properly
Done executing task “ResolveGNUIncludeDirectories” — FAILED.

I have attached one such log file.

The project compiles  just fine. VC++ intellisense does not seem to work, though the clang one does.

Any pointers on what i can try next?

Attachments:

You must be logged in to view attached files.

[support]

Hi,

This could happen if the project was manually edited with some custom targets or build rules, overriding the default VisualGDB target order.

The first step to diagnose it would be to create a new project from scratch and check if it works fine. If yes, you would need to analyze the differences between the 2 projects, open them side-by-side, and try narrowing this down to a specific setting or a custom target.

[Timo]

I have been able to reproduce it on newly created empty projects.

It seems to happen every time when a solution contains a visualgdb project in a subfolder of the .sln file, as opposed to the default location of putting it next to the sln.

It happens to me with multiple types (i tried a linux and an embedded STM project), with multiple different build systems (tried MSBuild and Cmake).

It also leaves a VcxprojReader.exe instance in the process list that does not exit after i close Visual Studio and seems to have some file open, preventing deletion of the folder until you kill it manually.

Im on VisualGDB version 6.1R3 (build 5547) and Visual Studio Professional 2022 Version 17.14.18 (October 2025) and Visual Studio Professional 2022 Version 17.14.40 (i updated after noticing my VS was older than my VisualGDB build, but the bug persisted in the new version).

Since this is a company wide project over which i do not have complete control, changing project structure is unfortunately not an option. Would be thrilled if there are other things i could try, otherwise i will have to learn to live with it i guess.

[support]

Thanks for the update.

This could be related to the order in which the tasks are loaded. You can try this build [VisualGDB-6.2.0.5625.msi], we added an extra check there.

That said, MSBuild projects with the VS IntelliSense engine is considered a legacy setup, so we won’t be doing major changes there. For new projects, we recommend Advanced CMake.

If you are not using Clang IntelliSense due to particular limitations (e.g. indexing the entire project when navigating to definition), we are working on a few optimizations to that. If you have a particular scenario that is slow, we can look into optimizing it. It also works way faster when running directly on Linux or Mac using our cross-platform CodeVROOM shell (e.g. see this tutorial), as a lot of its performance bottlenecks come from the Windows limitations when dealing with multiple small files.

[Timo]

Thank you for the build. Unfortunately, it made the problem significantly worse; now, when opening a project with the error, i get one popup error message reading

—————————
Error
—————————
The calling thread must be STA, because many UI components require this.
—————————
OK
—————————

For every affected project in the solution (thats 3 popus at once in our company project), and then visual studio hangs indefinitely on the Loading Project dialog, so i never even get to open the project (even the cancel button does not work).

Of course i would much prefer to use VS IntelliSense over Clang IntelliSense if at all possible;

for once because, as you mentioned, clangs navigate to definition indexes the entire project (which takes about 10 seconds), and does so every time you change even a single letter in the project, which makes it practically unusable while editing code and literally slower than just scrolling there yourself if you only use it once,

but also because clang intellisense seems actively hostile towards templates; there is no autocomplete (whereas intellisense offers autocomplete for types of your choosing or automatically when you use concepts), and in fact actively hinders you from just writing template <typename T> by autocompleting the T to a random known identifier for some reason.

That being said, the error mentioned also happens with cmake projects using clang intellisense. While, in this case, it does not actively prevent anything from working, it still floods the output in error messages, and it still leaves behind instances of vcxprojreader.exe that have to be killed with a task manager if you want to for example to a git checkout afterwards. Not a deal breaker, but something i would like to solve it possible.

[support]

Sorry about that. The integration with the regular VC++ IntelliSense is rather complicated. VS simultaneously runs several tasks from different contexts (some from within Visual Studio process, others from MSBuild.exe), and there are many corner cases, one of which was not handled properly.

We have fixed this one in this build: VisualGDB-6.2.0.5626.msi. If it still doesn’t work, please let us know, and we will provide instructions for narrowing it down.

Also, many thanks for the IntelliSense feedback! The reindexing should normally only happen when a commonly used header (e.g. pch file) changes, however in many projects these files change unintentionally when updating build numbers (or are outright generated during build). We are working on an update that will allow detecting and blacklisting such files, and also choose between aggressive indexing and fast token-based search, similar to what VS does. We will also look into the template completion and post an update here in a couple of weeks.

[Timo]

I have tried the new build and am happy to report that the issue has mostly been resolved.

• The first time i opened the project, i got the same STA error message and hanging IDE, but every other time afterwards it opened fine, including after another uninstall and reinstall to provoke the error. I’ll chalk that up to some leftover temp files from the old version.
• The error appears to be fixed completely. I was unable to reproduce it in this version among any of my company projects or the multiple test projects i made. VS Intellisense also works properly again in all cases i tried.
• the VcxprojReader.exe instances are mostly fixed, but every now and then, they do still stick around after closing VS and prevent file movement as they used to. From my cursory tests, it seems relatively rare (a good dozen of openings/closings before it shows up), and i see no pattern in when it happens either. I have had it happen and not happen in all of my affected company and test projects. Considering i have trouble reproducing it even when im trying, i’d say the odds of it ever being noticed in actual usage are slim to none, so im happy as is, but if you want to investigate further, i will also assist to the best of my abilities.

Thanks for your quick support and build, greatly appreciate it 👍

[Author]

Posts