Here are listed known problems which can arise during development. There are four groups of problems:

Please be aware of the fact, that WinGDB is a user interface product working with existing tools and can not solve problems inherent to these tools.

Underlying tools problems with known workarounds

Visual Studio 2019 update 16.1 or later - WinGDb menu is not present.

This is due to compatibility-breaking change in this version of Visual Studio. This can be solved by setting an option in Visual Studio settings, as described in this section of the manual.

GDB sometimes crashes when Autos Window is open.

If you experience a GDB crash, then please check whether standard Autos window is enabled. It doesn't have to be focused or even visible at the moment. The problem is that the Autos window in Visual Studio works by trial-and-error, generating incorrect expressions sometimes, which in turn crash the GDB. This is a bug in GDB, as it should simply report that the expression is incorrect and not crash. Workaround for now is just to disable the Autos window and restart session.

A workaround has been added in the version 1.2. If you still experience that problem, please contact us.

Problems with cross-probing remote build messages.

Visual Studio sometimes stops to open sources after double clicking on remote build message. This is rare condition. In such case restarting Visual Studio should help.

Embedded Linux: some breakpoints do not trigger or some shared libraries are not shown in Modules window.

We have experienced such problems and in all cases it was caused by differences between target and host files in sysroot or debugged application. All the binary files must be identical. Typical sources of that error are:

You can use auto-deploy feature available since WinGDB 1.5 to avoid the first problem.

MinGW: Can't debug, "no source available for current location" message shows up. Program is compiled with debug info.

This behaviour has been observed when Cygwin and MinGW were installed on the same machine and Cygwin debugger was used by mistake to debug MinGW-compiled program. Check "Default debugger path" in WinGDB/Preferences and your PATH environment variable.

After breaking running process, the program stops somewhere in some system function with unreadable call stack.

This problem occurs often on embedded Linux systems. It is most likely caused by lack of debugging symbols for system libraries and code optimizations enabled in these libraries. In such cases, GDB cannot correctly determine boundaries of stack frames and displays incorrect stack. WinGDB being a front-end to GDB, can not work around this on its own.

Possible workaronds:

Can't attach to a process under Ubuntu 10, Fedora 22 or newer.

Ubuntu 10 (and recently Fedora 22) comes by default with very restrictive security settings which disallow attaching to arbitrary processes (even owned by the same user). That means GDB will be unable to attach, regardless what front-end you are using. This is indicated by warnings similar to this one:

      ptrace: Operation not permitted.

You can turn it off by setting the ptrace_scope option to 0 in /etc/sysctl.d/10-ptrace.conf file under Ubuntu. You must have root privileges to edit this file. After editing, restart your system. You can find more information here.

Under Fedora, at least in version 22, there is no config file by default. You can create one, issuing the following command as root:

      echo kernel.yama.ptrace_scope=0 > /etc/sysctl.d/98-yama.conf

After editing, restart your system. You can find more information here.

File transfer to remote machine ocassionally fails when using Dropbear SSH server.

There is a packet size problem. WinGDB has a workaround for it. Go to WinGDB/Preferences/Network page and enable Limit SCP upload packet size option.

Network connection sometimes breaks after a period of time.

Remote machine may be configured to shutdown the connection after some time of inactivity. If you experience this, you may try using TCP keep-alive option as a workaround. Go to WinGDB/Preferences/Network page and set TCP keep-alive period value to some large number of miliseconds. For example, 60000 means that every minute a special packet will be sent to prevent the inactivity timeout.

Custom function name for 'stop in main()' does not support C++ functions.

'Stop in main()' feature is actually redundant and deprecated. A much better alternative is to create a function breakpoint in Visual Studio. You can put it on any function.

Underlying tools problems without known workarounds

GDB (esp. old versions) occasionally crashes.

GDB itself is not perfect and sometimes may crash. We introduced some mechanisms to detect it and display a warning message. However it's still very annoying since it breaks a session. In case you experience such situation, turn on logging in WinGDB preferences. If the crash occurs again, please send it to us along with a bug report. For old GDB versions however, be aware of the fact that fixing such a bug is probably impossible. We do not maintain GDB itself and its maintainers do not patch obsolete versions. Try using other GDB version if possible.

Embedded Linux: the follow fork mode does not work.

This is a problem in some versions of GDB. The GDB docs states that this feature is supported only on HP and GNU/Linux systems (kernel > 2.5.60). On our ARM toolchain (GDB 6.8.50) the "set follow-fork-mode child" command does nothing. The debugger still follows the parent. Unfortunately that means it also won't work in WinGDB.

Debugging with GDB 7.1 is very slow / temporarily freezing.

There is a serious performance bug introduced in GDB 7.1, described here. Please avoid using 7.1 unless the patch mentioned under the link is available to you. If possible, use other version (older or newer). There is no known workaround for this problem. The bug has been fixed in GDB 7.2 and later.

Dynamically loaded libraries are not refreshed correctly when using GDB versions older than 6.6.

The problem occurs if library (so or dll) is loaded with use of dlopen or LoadLibrary. It does not concern libraries linked at build stage.

There is no workaround at the moment. If possible, upgrade your GDB version to at least 6.8.

During build strange error messages appear, but the build succeeds.

When using some toolchains on Windows, you can sometimes see messages like this:

process_begin: CreateProcess(NULL, uname -o, ...) failed.

The build however succeeds. This is an indication of incomplete toolchain which does not provide uname utility, commonly used for platform detection. Makefiles generated by WinGDB use it. In cases we know, lack of this tool does not fail the build. We assume Windows platform in such case. As long as the build is not aborted, this message can be safely ignored.

GDB 7.3.x crashes or steps to incorrect line.

Release series 7.3.x has some new issues, including stepping problems (step over steps to incorrect line sometimes) and crashing when using Python visualizers. None of these problems occurs on 7.2.

One of the symptoms is Debugger stopped responding errors and messages like this in WinGDB session log:

        &"/build/buildd/gdb-7.3/gdb/utils.c:1446: internal-error: virtual memory exhausted:
           can't allocate 1435537552 bytes.\nA problem internal to GDB has been detected,\n
           further debugging may prove unreliable."

These crashes seem to be fixed in GDB 7.4. Also the stepping problem does not occur in GDB 7.5 (although it is still present in 7.4.x). Use at least 7.5 version if you experience any of these issues.

Strange warning appears in the process console.

The following warning is displayed:

        &"warning: GDB: Failed to set controlling terminal: Operation not permitted\n"

This warning is completely harmless and does not affect debugging at all. It should go to internal command stream used to communicate between WinGDB and GDB, but instead GDB displays it as if it were process output. This is obviously a bug in GDB, introduced in version 7.0.

Problem with saving options, visualizers, customs scripts or registered license files.

While not a problem with underlying debugger, these issues might be an outcome of wrongly set Windows permissions. This can happen especially when you run Visual Studio both in Administrator mode and without it. Files created in Administrator mode may differ in permissions from the ones created in user mode, and might not be accessible from the user mode. WinGDB has no control over that, as it depends on your system configuration.

If you experience issues mentioned in the title (e.g. your last settings from process launch are not saved), please find WinGDB directory inside ProgramData directory on your hard drive and review all file permissions. If current user account is not present on the permission lists with Full control rights, add the account. Another solution is to delete those files. WinGDB will recreate them, but you will lose your settings this way.

Also avoid mixing running Visual Studio as Administrator and normally, as the above problems may appear again. Old versions of WinGDB required VS to be run as Administrator, but since WinGDB 2.2 this is not needed any longer and not recommended.

WinGDB toolbar disappears under Visual Studio 2010

WinGDB remembers its state during Visual Studio runs. However, under Visual Studio 2010 the toolbar disappears without any reason (sometimes you can even see it "blinking" for a brief moment). We did not encounter such behavior in any other Visual Studio version, therefore it is considered as a bug in Visual Studio 2010. Generally it is recommended to avoid Visual Studio 2010 due to numerous bugs and slowness. Use a newer (or older) version if possible.

A temporary workaround is to reenable WinGDB toolbar in the Customize dialog.

WinGDB known bugs and limitations

A problem with loading the Add-In under Windows Vista or Windows 7 with UAC enabled and Visual Studio not being run as an Administrator.

Install recent version of WinGDB (2.2 or later). Older versions used to require that VS had to be run as an Administrator, but newer version don't do it anymore. On the other hand, if your version is 2.2 or later, then it is a bug and contacting our support ( is recommended.

Remote process console has some refreshing problems.

Sometimes the console is painted incorrectly. Also it does not yet support full set of VT100 commands, therefore it doesn't pass the vttest suite.

Some problems with console refreshing observed on Windows XP turned out to be related to font display problem with particular font used in the console. This occurs for unclear reasons and restarting Windows makes the problem disappear.

Remote process console does not echo user input.

In Unix terminals, echoing the input is optional. Some clients need it, while for some it would be undesirable (e.g. curses programs). WinGDB supports optional local echo mode. When it is not active, the input is correctly served and passed to debugged process, although is not visible in process console window. When local echo is activated, the input is additionally echoed into the window. You can enable local echo mode by clicking a button on the toolbar above the process console window.

Visualizers currently work only on remote sessions, not MinGW/Cygwin/Embedded.

This problem will be addressed on WinGDB side in future version. However, to use Visualizers you must have a Python-enabled GDB, and unfortunately most of currently available GDB versions for Windows does not support Python yet.

WinGDB toolbar is not customizable.

It has been reported that customizations added to WinGDB toolbar are not remembered after closing Visual Studio. This is a minor bug which will be addressed in some future release. Note that this issue is completely different than the problem with disappearing toolbar under VS 2010. These two are unrelated. THe customization problem does not depend on particular VS version.

A temporary workaround is just avoid using toolbar customization - it is not considered a critical WinGDB feature. You can access all WinGDB functions from menus.

In some rare cases WinGDB can't be installed to a Windows system or is not installed properly.

Sometimes we got reports about installation problems. Those are rare (just a couple of reports each year) but inevitable due to Windows systems' complexity and amount of circumstances and settings that can break compatibility. An example are various Group Policy settings, which in extreme cases can block software installation or functioning entirely. Please do not alter Group Policy or other Windows security settings unless you really know what you are doing.

Other causes may include misbehaving third party software, incorrectly configured antivirus, and in very rare cases -- hardware problems. Especially faulty SSD drives can cause all sorts of weird behavior, as they give errors in access to particular files.

If you encounter problems during installation of WinGDB, please first ensure that you are using the latest version available from our website. Then perform the following diagnostic procedure:

msiexec /i WinGDB-latest_trial.msi /lvx* wingdb.log

Doing so will allow us to find a solution to the issue. Bear in mind that we do not have access to your system and no idea what are values of various settings, third party software and possible other properties of your system which can affect operation. Please attach the msiexec log and every information you might think to be relevant. This will help to find the solution quickly.

WinGDB non-bugs

webOS support has not been updated for a long time.

Unfortunately webOS is not supported anymore by its vendor and the future of the system is currently unclear. We also do not have any registered customer who develops applications for webOS. Possibly (if commercially feasible) we will resume webOS support and update it to recent version of the system.

I have manipulated the clock on my computer to cheat the 30-day trial timer. Now I get error messages from WinGDB (or crashes sometimes).

In general, messing with system clock can lead to various unpredictable results. Do not do this. If you need more time for evaluation, just write us and we'll make extended eval key for you. Also, if you find WinGDB useful, please consider purchasing it. We are an independent software vendor from Central Europe. By purchasing a license, you support further development of WinGDB, IntegraStudio, VSScript and perhaps other quality tools in the future.