[support]

Good to know it works. If you encounter any further issues, please feel free to create another thread.

[support]

This error looks like you are using some special characters or variables in the linker script path and VisualGDB fails to resolve them (it would need to resolve the linker path in order to insert the memory definitions in it). We have added more detailed error message for this error in the following build: VisualGDB-5.4.110.3230.msi

[support]

Hi,

No problem. The file name case for breakpoint setting comes from Visual Studio itself and would normally match the actual case of the path. Please try right-clicking on the tab header for the file in the VS editor and select “Copy Full Path”. Then check if the path seen by VS has the correct case. If yes, please double-check that you have not accidentally specified incorrect case via VisualGDB Project Properties -> Path Mapping.

If the path shown by VS doesn’t match the actual case of the file, it could have been cached somewhere on the VS level. Normally deleting the .vs directory and reopening the project should solve this (please ensure you are not specifying incorrect case via VS command line or anywhere in the VS project creation GUI).

If this doesn’t help, please let us know and we will provide further diagnostic instructions.

[support]

No problem. We have managed to reproduce the problem. It was not caused by using the older apt-get syntax (it is still fully supported and VisualKernel keeps it for backward compatibility with older distros), but was instead caused by a change in the versioning tag format of the kernel symbols for recent Ubuntu builds (the symbol file version is 25.26~18.04.1 instead of just 25.26). We have updated the version matching rules in the following build: VisualKernel-3.1.0.2230.msi

[support]

Thanks for the detailed description. We have pinpointed the problem and fixed it in this build: VisualGDB-5.4.110.3228.msi

[support]

Sorry, our regular product license only includes email and forum support. If you are interested in screen sharing support, please contact our sales to get a quote.

Based on the description you provided, gdb (the low-level debugger that is a part of the toolchain) fails to evaluate the variable shown on the screenshot. This could be caused by a bug in gdb or some configuration issues. We would advise enabling gdb logging as shown on this page and confirming that gdb never replies to the -var-create command. If this is the case, please try using a different version of gdb, or avoid evaluating the variable that triggers the gdb bug.

[support]

Hi,

Please try referencing the Fast Semihosting framework on the Embedded Frameworks page of VisualGDB Project Properties.

We have just updated our semihosting tutorial to show it on the latest VisualGDB version.

[support]

Hi,

This looks like another instance of this issue. Please follow the instructions in another thread to obtain another diagnostic log and we should be able to fix it.

[support]

Thanks for the log file. It looks like some combination of settings is preventing VisualGDB from showing some of the tool windows before updating its state.

We have added more diagnostic logging to this build: VisualGDB-5.4.110.3226.msi

Please try reproducing the problem with it and send us the updated log from the VisualGDB Diagnostics Console.

[support]

Hi,

The Additional Memories page should normally work, so most likely you are using some combination of settings that triggers a bug on our side. If you could reproduce this on a “LEDBlink” project created from scratch and send us the related files (ensure you clean the project before packing it), we should be able to release a hotfix for this promptly.

[support]

Hi,

Sorry about that, it looks like a known issue of the Windows installer triggered by broken dependencies between products.

As a workaround, please try running the following tool from Microsoft that can automatically repair the installation database: https://support.microsoft.com/en-us/help/17588/fix-problems-that-block-programs-from-being-installed-or-removed

[support]

The Visual Watch and Live Variables windows are still using the older WinForms technology (other windows have been converted to WPF) and hence they indeed may look distorted on the high-DPI displays. We are planning to convert them to WPF in the next major VisualGDB release. That said, it should not affect any functionality, i.e. simply double-click underneath the header and start entering variable name. The watch item will be created as expected despite the incorrectly looking header.

[support]

Thanks, this looks like something GUI-related (the actual error is “Invoke/BeginInvoke cannot be called” shown on the screenshot).

Please try using View->Other Windows->VisualGDB Diagnostics Console to narrow this down. I.e. enable debug logging, reproduce the problem and share the diagnostic output from the diagnostic console.

[support]

Please ensure your project is built with semihosting support via VisualGDB Project Properties -> Embedded Project Properties -> Implementations for syscalls -> With Semihosting.

[support]

Hi,

This is a limitation of the WinForms grid used by the Live Variables control. The Expression column will automatically fit the space remaining after all other columns. Please try resizing the other columns instead and the Expression column will get automatically adjusted.

[Author]

Posts