Klayout Won't Run After Upgrade to Windows 10

After upgrading a machine from Windows 7 -> 10, Klayout won't run.

I've tried to uninstall Klayout and reinstall it, no luck. I've tried to use Revo Uninstaller to do a deep remove of all the registry keys too. Still no luck.

I've used Procmon and can see that it starts for about one second then dies.

Any ideas on other things I can check? I'm not sure if/where any logs are stored that can help me figure this out.


  • I reinstalled Windows, and it works now.

  • I'm using Windows 10 on a variety of computers myself with no issues.


  • It might have to do with upgrades and the residues
    they may retain, from previous OS?

  • Well, KLayout comes with everything it needs (apart from some very basic system libs such as kernel32.dll). In the past the OpenSSL DLL was missing, but I fixed that. So it's not quite likely that this fails.

    However, custom macros may cause such a behavior as they might pull in other components.

    You can debug that by renaming KLayout's home folder to something else (this is c:/users/you/KLayout). This will disable all installed macros.

    Another reason for a fail may be a duplicate installation - this can happen if you install KLayout as admin and user - this will create two separate installations and it may screw up things. Again, I fixed a few problems related to that special case, so it's not very likely this is the reason here.


  • I had nearly the same problem under Windows7-x64, KLayout-64b was always crashing and I had to use KLayout-32.
    Today, I found out the problem : I had Ruby-x64 installed in stand-alone = it makes KLayout crashing. I removed it and KLayout-64 was working !
    Matthias : maybe a check is needed there ?


  • That's a bit weird - I have tried to reproduce the problem without success.

    Basically KLayout's installation should come with all the libraries required and does not make external references. This used to be a problem in some older versions, but that should have been solved.

    I can't entirely rule out that there are some DLLs being pulled in through secondary paths. As Windows DLL resolution AFAIK prefers "next to DLL" over PATH, this should not be an issue. But the whole topic is complex and there may be gap. The Python people have disabled PATH for Windows in version 3.8 and later. Maybe for that reason.


Sign In or Register to comment.