Anyone finding that 0.9.16 is crashing a bit more often than other versions?
I’d been able to leave 0.9.15 running for days / dozens of jobs - now, I am often getting ‘not responding’ and / or a crash message.
Doesn’t hurt the running job of course, but … just curious to see if it’s just me or …
LightBurn should not crash. Please provide any crash reports presented so we can track down and help with any issues that might arise. I know we ask the user, in the crash dialog, to send it along to us but I want to state it again here for others that may read this post.
I was trying to save a layer of settings to the library when this happened.
Again today.
Any thoughts?
Doing the same task, save to the library or something different?
When saving, are you saving to a remote, networked or cloud storage by chance? Which OS version?
Hi Rick-
The library is on a remote mapped network drive (in the same house / different computer).
This crash was:
- Ran a job
- had lunch
- turned off laser
Went to the store, came back, it was crashed.
John
Are you using the 64 or 32 bit version of LightBurn? The 64 bit version should give you a crash dump that’s internal / ours, not a generic Windows crash dialog.
Help does not have an “about” so I can’t screen shot it - but 64 bit.
I’m running 64 bit on Win7 ultimate.
Are you using a camera? This:
Looks like “YUV2” which is an image format used by video capture systems. It’s possible that the driver for whatever camera you have connected is at fault.
I have a lightburn camera installed, yes. Love it. Need to get it better focused, but yeah… !
Hi all,
Just jumping in on this thread - I’ve noticed more issues recently with Lightburn hanging, I believe since 0.9.16.
I tend to notice it during file operations (open/save), and it won’t crash per se - it tends to hang, and will eventually recover after a few minutes. It carries over into weirdness with explorer in general, in terms of opening folders, or attempting to open task manager.
Other applications running at the time continue to operate fine. As it’s not ‘crashing’, there’s no crash reports to offer unfortunately.
It’s a fairly intermittent thing, and I’ve not been able to deliberately replicate it. Windows 10 Pro x64, build 10.0.18363.
I have noticed instability in the latest version as well, specifically when saving files. It more seems like a hang in the handoff between lightburn & explorer. Latest build of Windows 10 & Lightburn 64-bit. Nothing crashes as both will eventually recover, but it takes a LONG time sometimes. I’m often not connected to my machine and am saving my project, then saving the file to my usb stick to take out to my workshop. If I do these two tasks too close together, I can repeatedly set off the hang and crash explorer as my whole desktop will disappear. Even after force closing Lightburn, the file save window will pop open again when I open it the next time which leads me to believe that it is a problem within Lightburn that is causing the issue.
As Scott has stated, since nothing is really crashing, there is no crash report to give us any insight into what is happening. It is just a massive hang. I’ll try to take a look at the processor, memory, and disk usage the next time it happens as I haven’t taken the time to look into this yet. I has just become enough of a pain to come looking for a solution here.
Thanks,
-Kyle
Just bumping this thread again - occasionally I’ll get a ‘this program is not responding’ dialog for LBFileDialog.exe (I think that’s the process). It doesn’t make a difference if I close that or not - once it’s hung, it sits there for 5 or 10 minutes before recovering.
Sorry I don’t have any further troubleshooting to offer - my only suggestion would be file operations in rapid succession, ie. close save file and immediately try to open another, might be a catalyst?
I find it’s happening on both my computers fairly regularly. It’s becoming unusable. Lightburn Dev’s PLEASE FIX THIS. It goes NOT Responding, you can’t kill it with task manager so I end up having to reboot.
As a matter of fact it’s happening right now as we speak.
Scott / Kevin, try this:
With LightBurn closed, open the LightBurn folder, then rename LBFileDialog.exe to LBFileDialog.exe.bak
This just makes it so LightBurn can’t find that to use it, so it will fall back to opening files with the internal file dialog instead of the launched one. The LBFileDialog thing exists because some people have software on their computers for displaying thumbnails, but written using a different version of the framework that LightBurn uses. When the file browser window pops up and tries to load one of those thumbnail generators, they try to use the framework LightBurn is running, instead of the proper version for them, and they crash, taking LightBurn down too.
I’m not sure why the external thing is being a problem, but I’ll take a look at the code and see if I can spot anything weird.
Edit: to be clear, I’ve never been able to reproduce this here. It’s been reported by a very small number of users, but I haven’t been able to figure out a cause. I’ve just added some code to the bit that launches the file dialog to make sure it actually worked, and didn’t fail, and if it does, it falls back to the old method, so that will hopefully help.
Kevin: if you see it happen again, try to remember if it happened when you went to Save / Import / Open, or if it just happened out of the blue.
I also had Lightburn (0.9.16) hanging a few times.
I was too impatient to wait until I got a not responding error message.
Next time it happens I will document wat I was doing. Hopefully it helps.
(64-bit Windows 10)
The problem happened when I was trying to export to SVG. I’ve also seen it happen when trying to save.
This particular Not responding was export to SVG.
Let me know if I can send something to you for investigation, logs, etc…
That all by itself is useful - it does sound like it’s that pop-up failing for some reason. I’ll go in there and add some output to the debug log so maybe I can figure out why it’s failing, but the changes I just made should help.
Thanks Oz. I’ve renamed the executable, so I’ll let you know if I see it again. It was happening semi-regularly enough (a couple of times per week) that it should be obvious one way or another.
As a data point after 11 days or so, not one crash since the file executable was renamed.