PCBNew crashes when closing on work laptop

Hi,

I use KiCad on Windows at home, but I’m currently on location for work so I thought I’d do some work on projects using my work laptop. If I launch PCBNew from KiCAD and then close PCBNew, about a second or two after it closes, I get a dialog saying KiCad is going to crash. And then it does. The dialog just says KiCad has stopped working.

image ![image|458x215]

If I launch PCBNew directly without using the KiCad launcher, then it crashes but complains with the following:

Can’t write buffer ‘fp-info-cache’ to disk
Failed to create a temporary file name (error 5: access is denied)

If a launch it directly but as an administrator, then it closes without a problem. Thinking this was the solution, I tried starting KiCad as an admin, but when I close PCBNew it still crashes KiCad.

I have an admin account, so I then tried setting the permissions on the “fp-info-cache” file in the “bin” directory so that even regular users have full read/write privileges, but it still crashes.

Any thoughts on anything else to try? I’m assuming the problem is related to whatever restrictions, etc the IT department enforces on the machine. I previously ran 4.07 on this same machine without any problems.

I guess I can reinstall KiCad in the “Documents” directory since I know I have full read/write privileges to everything there, but that feels kludgy.


Application: kicad
Version: (5.1.2)-1, release build
Libraries:
wxWidgets 3.0.4
libcurl/7.61.1 OpenSSL/1.1.1 (WinSSL) zlib/1.2.11 brotli/1.0.6 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) nghttp2/1.34.0
Platform: Windows 7 (build 7601, Service Pack 1), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.68.0
OpenCASCADE Community Edition: 6.9.1
Curl: 7.61.1
Compiler: GCC 8.2.0 with C++ ABI 1013
Build settings:
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_PYTHON3=OFF
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_USE_OCC=OFF
KICAD_SPICE=ON

There should be a fp-info-cache file in every project directory. These should be under /Users/yourname/…
Until recently, you could misconfigure the project path to be something other than the project directory

Perhaps you’ve tried to put your project files in a directory that Windows is trying to protect. That often causes programs to misbehave. Make sure your project files are in a user-writable location and not under the applications directory.

1 Like

Rene_Poschl,

I was hoping someone here might have encountered something like this and had something tangible to try. I’ll try and file a bug report, but somehow it seems like an issue that will be below the bottom of the pile in importance.

davidsrsb,

Yes, i do have an fp-info-cache in each project directory which is under my “Documents” folder, under “users/my account name/”. The one in the project I am working on is 2.7MB. Not sure what to do with the information about it being possible in the past to misconfigure the path.

RRPollack,

As mentioned just above this, the project is under my account’s “Documents” directory, and I absolutely have access to that, especially since I’m in the administrators group on my machine.

@FredP

I would consider trying a V5 nightly build.

Do so at your own educated risk level.

I have a library problem!

This is just a User Forum, and my suggestion may be horribly wrong to fix your problem.

1 Like

That is milestoned V6, so won’t be fixed in V5.1.x

What do you mean? I don’t think fixing crashes are milestoned to a next stable release :slight_smile:

I would guess it is added to v6 as it is low priority and they still want to make sure it is fixed at that release at the latest.

With my question I meant “what is added”. There were several problems indentified in this thread. The OP bypassed the “can’t write buffer” problem but KiCad still crashed. Crashes should never happen whatever the circumstances, they are always critical and fixed ASAP, that’s the policy if I have understood correctly. A warning isn’t critical.

I think everything after you pointing to the bug report was meant specifically in reference to that one bug.


We still have no idea about the original report (which is why my original “make a bug report” answer might be still the only way to go)

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.