KiCad testing and debugging in VMs

As it does not seem to be mentioned a lot elsewhere, I’m reporting my experiences with running KiCad builds in a Windows 10 VM below. Your report on other host and guest systems may help new users set up an use a virtualization solution for isolated or cross-platform testing.

To share your experiences, you can use:
Host and Guest system
VM tools that work
VM tools with issues
KiCad debugging hints

as a template.

Host and Guest system

host: Windows 7 Professional SP1 64bit (6.1.7601)
guest: Windows 10 Professional (Build 9200)

For Win10, Winaero Tweaker is a good way to turn off most of the nuisance “features” and unsolicited data collection

VM tools that work

VMWare Player 15 (15.5.6 build-16341506) (free for non-commercial use)
VMWare Workstation 15 Pro (15.5.6 build-16341506) (provides snapshot creation before installing and uninstalling KiCad versions)

VM tools with issues

VirtualBox 5: OpenGL 2.1 requirement not satisfied
VirtualBox <= 6.1.10: crashes, Win10 rendering problems, OpenGL buffers upside-down, menus and dialogs not clickable
All of these don’t result in stable operation with 3D acceleration (all tested)

The problem with upside-down rendering is an issue reported several months ago and as of yet unsolved, so VirtualBox is currently not usable.
https://www.virtualbox.org/ticket/19237

qualification criteria (opinion)

This is definitely a best-effort topic, as you may well be exploring a combination of systems and problem presentations that hasn’t been covered on the KiCad forum or bug tracker.

  • make sure the machine is running with 3D acceleration enabled and no issues on the guest side. Guest tools / extensions need to be installed
  • A recent, stable release (5.1.6-1 as of this writing) needs to run with no issues. Please take a few minutes to make sure there are no immediate problems that can be ascribed to the virtualization itself
  • use additional tools (dxdiag, OpenGL Checker) if needed

KiCad debugging hints

Some problems are hard to reproduce and may be specific to your system. If you are already familiar with debugging using GDB or similar, nobody will stop stop you from giving debugging a shot. Developers can provide builds with debug symbols enabled, so you don’t need to be able to build KiCad to be able to debug it.

Additionally, MSFT offers tools like WinDBG in their platform SDKs.
Windows SDK for Win7 https://www.microsoft.com/en-us/download/details.aspx?id=8279
Windows SDK for Win10 https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk/

VirtualBox offers a WarpDrivePercentage parameter, which changes the machine clock, but not the execution speed. This might be used for timer events manipulation.


This seems to be of limited use though. Variable execution speed might be achieved by reducing thenumber of VM cores to 1 and running a process that uses up most of the CPU time.

using multiple KiCad versions side-by-side (Win7+)

the following example assumes two KiCad builds installed in different directories.

  • kicad test build in C:\Program Files\KiCad\
  • kicad nightly build in C:\Program Files\KiCad-nightly\

Windows likes to hide path information when opening files, so it is not clear which one of the executables sharing the same name is actually being used.
To circumvent this problem, extension specific “open with” items can be created by adding a set of entries to HKEY_CLASSES_ROOT (see .reg file, please open with a text editor and make sure the paths are appropriate before double-clicking to execute).

multiple_kicad_versions_context_menu.reg (4.2 KB)

my part of the story

Recently I’ve tried to contribute by reporting bugs in KiCad test builds and nightlies, but encountered some challenges:

  • observations, even if plausible (e.g. differential testing against versions shown to run on the target OS) are rejected when the OS is not officially supported
  • problems will be encountered when setting up a dedicated virtual machine for testing
  • the goalpost may be moved from “OS not supported” to “the problems observed are due to virtualization”

On the one hand, some aspects are unavoidable, like running into problems with newer VM tool releases on both host and guest sides. On the other hand, I would have wished for more clarity about the testing requirements.

Thus, I’d like to propose that we collect

  • combination matrix entries of the host and guest systems you’re using, listing name and revision of tools that are proven to work and some guidance regarding setup and use (e.g. platform-specific debug tools)
  • requirements for qualification of each VM
3 Likes

AFAIK MS debuggers don’t work with KiCad because it has been built with mingw.


IMO virtual machines are impossible to support officially. There are too many of them, too many platform combinations, too many possible things which can go wrong, and way too little developer time. Even with the now supported platforms unreasonably large part of development time goes to cross-platform support and problem solving.

If someone wants to dedicate their time supporting something and can make a commitment, then it will be supported.

Otherwise, collecting experiences, clarifying the situation and giving recommendations to users is certainly a good idea.

1 Like

I’m using virtualbox 6 (last version or close to last) on windows 10 host with variety of linux guests with no issues.
I suggest you think about moving away from unsupported windows 7, not because of kicad but because it’s abandonware.

1 Like

I propose dropping windows support entirely

2 Likes

I have tried to install some Linux distros on a couple of different VMs on Windows 10. But alas they didn’t work too well. The machine is only lenovo T430, so no surpise. Linux on Linux PC works much better, but on that 15 years old dual core with 8GB mem there aren’t enough resources, either.

If I ever get 8 cores with 16GB I will certainly try Linux distros on some VM.

I’m not asking for perfection, I’m asking for testability. There are unknowns no matter if KiCad runs natively or in a VM, so across a set of users the VM observation should be just as valid (and in addition, in my case I could reproduce the issue in the native and both virtualized scenarios, even irrespective of OpenGL issues).
From a user perspective I’m by now convinced that both sides will have a net benefit, as users can do more testing and playing without breaking their productive installation, Side-by-side installation may be a non-issue under most Linux distributions, but that doesn’t hold for Windows installations.

If you can recommend a particular distro I’d be interested in giving it a go with VMWare 15.5. Were the issues with running / debugging or compiling in a VM?

Why? I have kicad 4, 5 and nightly installed on my windows pc and they work fine.

reductio ad absurdum: might as well give up on it entirely.

that was not explained to me on the bug tracker, my guess is that configurations might interfere, and the uninstall may not be clean.

Probably because it’s a pro user topic or maybe your discussion took place before nightly had it’s config directory separated. Currently it’s very easy to have both nightly and latest stable installed, they don’t interfere. Kicad 4 and 5 together is a bit tricky but reasons to have kicad 4 are few and usually because of specific needs.

1 Like

It’s probably more fair to look at the feature freeze milestone, at least the slope is the correct direction :slight_smile:

At this point in time the 6.0.0-rc1 milestone is mostly the place we put stuff that we think can be done after feature freeze, so it will not go down very quickly.

1 Like

All good efforts are given in Elon time :slight_smile: some delays may be expected.
I think one of the key factors of KiCad’s success is its diverse user base. I mean, wxWidgets has taken quite a toll on the KiCad progress, but ultimately progress is being made, despite the neysayers who’d prefer to exclude as many users as possible, ideally only supporting Linux and distributing the source. I guess there the concept of “users” got lost along the way. I’m just tired of the cynicism.

Please note that our official policy on supporting distribution versions is that the distribution needs to be supported by its developer. It is not reasonable to ask a small team of volunteers to support operating systems that have been abandoned by their own companies.

We do offer professional support (paid) for users who want/need to use older or esoteric operating systems.

1 Like

Not to mention holds back progress by supporting a decade old OS and not being able to support newer OS features. There’s quite some shiny Windows 8+ APIs I really want to implement. I already snuck in a Windows 7+ (no XP) feature awhile back :wink:

KiCad definitely doesn’t work on XP due to not even our fault. MSYS2 and cygwin broke the compatibility for us (they were being held back without the newer APIs) :smiley:

And developers running Windows 7 at this point in time is a massive security risk and vulnerability to the project. It’s an unpatched insecure OS.


OSS has always been about the user and their freedom to build their own sand castle from source. It’s never been about having the developer beholden to demands of users. Developers certainly do care about issues and fixing them, but there’s a line in the sand in regard to what and how much can be supported on a volunteer basis and their own personal interests.

This is where the market for commerical support comes for OSS like Seth offers :wink: You now pay someone to make helping you their personal interest.

I’m tempted to go KiCad Pro, if only to create an incentive to read past the first paragraph :slight_smile:
I’ve now restructured the initial post because this thread is about helping identify bugs with the platforms that are explicitly supported irrespective of the host system, and doing so in a manner that does not invalidate the findings and the user efforts.

I still stand by statement that the initial observation under Win7 SP1 64bit is valid and can only hope that you appreciate the extra effort I put into confirming this observation setting up a Win10 VM - and making sure it runs without causing additional question marks (like OpenGL bugs).

Perhaps you could now comment on what does constitute a usable test environment. I’ve tried to outline criteria above, but I’m looking for baseline requirements and some consensus on the method of testing in VMs itself (obviously including OS-X and selected Linux distros, so not limited to Windows versions).

1 Like

I guess we shall note that “We” as in “KiPro / KiCad Services Corporation” which is not a super set of all contributors using their spare time :slight_smile:

I think this was fixed upstream for MSYS2 again a bit later. Or we are not talking about the same thing.

1 Like

It seems the test builds and nightlies still overlap. Currently having 5.99.0-2286-g30eef410a installed, so more uninstalling and re-installing, I guess :slight_smile:

image

It overwrites only the previous installation in the selected location. Just take care that you select different directories for 5.1 and 5.99.

The installer is responsible for the Windows start menu shortcuts, too, but unfortunately they don’t work well with two installations. Details can be found in Running several KiCad versions on the same Windows machine.

KiCad itself takes care of the configuration location.

1 Like

Thanks for the hint. What’s more, I’ve noticed that Windows does not handle file associations properly, as it takes the application filename only. So having multiple kicad.exe variants is bad mojo.