Using left-shift key for "clean boot"? What does this do?

A couple on months ago I had a bizarre problem where a piece of window was stuck over LB and would return every time I restarted LB, even after a PC reboot:

I was advised to hold down the left-shift key while restarting LB and that worked.

Last night LB 1.10.0.0 bricked. The laser status would change from “Ready” to “Disconnected” every time you tried to run a job, and stayed in Disconnect. Ruida 6445G on ethernet. Ping to IP# was fine. This is a makerspace with a lot of casual users, I don’t know how it got into this state.

I tried to reboot LB and the PC a dozen times, no luck, then I remembered the left-shift key thing. BOOM ALL FIXED. So that’s twice now we’ve had LB get stuck with some persistent, bizarre error that can only be fixed by holding down the left-shift during a restart. I’ve never seen this in any other software.

Ok, that’s great, the problem is fixed, we’re ok. But what is this left-shift thing doing? Because people are going to be asking me how I fixed it. As a makerspace, we’ve got a lot of users of varying skill levels and they used it unsupervised. If I mention this possible “fix”, it becomes like a viral rumor, users are going to be trying to fix ANY problem by doing this left-shift thing on their own and it won’t be logged or communicated to anyone. This might cause more problems/confusion, I just don’t know what the left-shift thing is doing.

What does the left-shift thing do to make it “clean boot”, exactly, and why isn’t it booting up clean like this all the time? What are the consequences of using the left shift key unnecessarily during restarts?

The left-shift key does nothing except ignore the stored window layout on startup, so it reverts to using the default layout in LightBurn. If you sometimes connect a second monitor to a laptop, and the LightBurn window was on the 2nd monitor, if you later run without the 2nd monitor, it could try to place the window where the monitor used to be, and cause issues, so the Shift key trick fixes that. It should have no effect at all on the connection to you laser, so that’s surprising to say the least.

Left Shift, in this case, seems to have had “Real Placebo Effect”!

1 Like

Yep this most definitely happened last night. I have never seen this before and updated LB to 1.10.0.0 Wed night so I bet it’s a prob with 1.10.0.0.

All the details I can think of:
It had bricked it. Laser status went to “disconnected” after the first attempt to do anything. Restarted LB, rebooted PC. Would begin with “Ready” but any attempt to use the laser went to “Disconnected” persists until restart but even though we could get the “Ready” state back it would just go “Disconnected” once we tried to run.
While Disconnected I tried to look at Machine Settings, it waited and went blank. Legit not able to talk to laser.
6445G was fine on the panel. I was power cycling it all this time, it didn’t change anything. It’s on ethernet and responds to pings. This tells me LB/Windows is having the trouble.
I closed the user’s job, restarted, and started from New job, drew a rectangle, cut as Line, normal speed/power no special features. Still Disconnected when trying to run.

Left-shift boot and it’s suddenly “fixed” and the Disconnected state did not reoccur.

I saw nothing “bad” about the job the user had. Looks like they have some text that was converted via Trace and cut in Line mode. After fixing, they brought their job back in and Disconnected did not reoccur. So I don’t think it was their job at all. They said it was stuck on Disconnected since they started using it. I don’t know what the prior user was doing, I’ll see if I can find who it was

What had bricked what, exactly?

The only part of the code path skipped when you hold Shift when launching is the window layout restore - I will never say something is impossible with software, but it is extremely unlikely that these things are related.

Unfortunately it doesn’t - Ruida’s network stack is weird, and likely handled by a chip that isn’t the main controller. I’ve had devices respond to pings that were otherwise completely bricked. (It’s kind of maddening when you’re trying to track down a connection issue)

Well, like I described- I try to debug forensically, and investigate step by step and record.

“Bricked”: We couldn’t get LB to talk to the Ruida at all and reports “Disconnected”. Tried scores of restarts/reboots on the PC. Ruida panel seemed fine and power cycling that changed nothing. State remained “Disconnected”. Rebooting and restarting LB initially changed to “Ready” but any attempt to send a job in any way did nothing and became a “Disconnected” state that persisted.

The left-shift-on-restart for LB suddenly made it work and the prob did not reoccur. I’m certain this was not a coincidence but “the fix”. Far too many attempts restart attempts, new job, etc that did nothing, then immediately after the left-shift restart it was working and stayed working.

Left shift on PC reboot causes the Windows system to close and re-set a bunch of temporary files in the Windows environment. That trick has helped with several different PCs in my world, particularly for those with multiple user accounts that do not get shut down completely.

Ah - that wouldn’t be a LightBurn thing then, but an OS thing, if that’s what he did.

Well, I’ve used Windows since it started, and installed all sorts of software. Never heard of the left-shift on startup thing ever before.

I tested, too. See I’ve gotten obnoxious cases where the VLC media player ends up outside the space of BOTH my monitors and not retrievable, and closing VLC or killing the process does not help. Its location is persistent, and you need a arcane sequence of operations to select it and use the strange “windows button” to retrieve it.

So, I moved VLC to an unusual location, closed it, and held left-shift while opening it from the Taskbar pin. No, it doesn’t reset the default location.

Don’t get me wrong, I love LB, this isn’t bashing them. This software effort is amazing. Something’s unusual here we need to sort out and I don’t think it’s a Windows thing.

My “bottom line” is that we have a nonprofit makerspace with about 100 active users of the lasers, running LB. And they’re going to be running LB. You won’t catch me b*tching “well if such-and-such isn’t addressed right now, I’m going elsewhere!” like an entitled technobrat.

My thing is, when LB bricks like that, there’s about 5 appointments per day that would be cancelled. That’s not any money out of my pocket, hey I don’t get paid. But I’m committed to making sure we have reliable high quality laser service.

LB is the best software to do that. But that kind of bricking- you can restart/reboot/cycle power all day and it won’t fix anything- got my attention real fast. Literally no one else here would have known to try the arcane left-shift trick. Probably anyone else would have tried for a few days and then reinstalled LB, which would probably work.

So I just want to get to the bottom of that one, or at least settle on what the left-shift does so I can make a note that it’s a good thing to try. Thing is, once I say that, people are going to be trying it every time they have something unexpected happen because they’ve got the Fill setting wrong.

Eh, ok, that was rambling. I love LB’s work here! Bugs are always going to happen. Just want to know how to ensure we’re staying online.

I’d love to know what’s happened as well, but without a repro case of some kind, that’s going to be tricky. If you can figure out a way to make it reproduce, I’d be very interested - Like I said, I’ll never claim it’s impossible - software is complicated black magic with all kinds of weird inter-dependencies, so I know better - but I genuinely can’t think of anything that the “bypass placing the windows” code would do that could have an effect on the connection with the laser.

Yeah I messaged the user scheduled earlier about it hoping for info we could use to reproduce it, but no luck.
I’m pretty certain it couldn’t have been resolved by any normal means- tried them. It would have to be that left-shift weirdness- definite cause/effect- reinstalling, or manually deleting files. Spend a long time attempting all the normal stuff and it didn’t help.

Calling @berainlb you seem to have special knowledge here

I’ve observed this thread and have been trying to come up with a scenario that would explain any of this. I haven’t been able to and haven’t seen this issue myself. The available data doesn’t lead to anything conclusive.

If we assume that launching LightBurn with shift key does what’s it’s supposed to do and resets to default window layout then I’m thinking these 2 corollaries should be true:

  1. Using Window->Reset to default layout should also resolve the same problem scenario. This would be interesting to test
  2. The root problem was caused somehow in the layout of windows in LightBurn. I’m wondering if somehow something was being drawn off-screen that required attention but was not visible. Or if perhaps the user plugged in an extra monitor or possibly a graphics tablet with screen. I can’t think of a specific scenario where a screen layout could cause what you saw, however, and still be resolvable by resetting the layout.

I have observed LB does create “zombie” processes, and I see others have reported this as well. I, and others, have seen high machine CPU loading going on even after closing LB, and the PC is used for nothing else.
When I went to update to 1.1.0.0, the installer said “these 2 instances of LB need to be closed to do an update, would you like to close them automatically?” OK, LB was closed at that point. I said “yes” and it hung indefinitely trying to close them. I could not find any LB process on Task Manager- VERY odd. I opened the other Admin account, it had not been used since the last reboot and hadn’t opened LB. So, somehow, zombie LB processes somehow.

Was this of consequence? No. I did a clean reboot and the installer worked. I didn’t even bring it up as something to fix as an LB prob, that is a minor hitch any competent Windows user should be able to deal with quickly. But it is unusual and I’ve rarely seen it with anything but LB.

I have never seen a user bring a graphics tablet, and I would expect that to have been asked on our membership Discourse. I do know one person who creates their artwork with a graphics tablet, but I have hung out with him for hours while he’s cutting and he never brought his tablet here. I can ask.

I haven’t seen LB create zombie processes so much as there are times where I’ve seen LB processes get into a lock state. I assume this is caused by a file contention with another foreign process, possibly a race condition.

One thing to be aware of is that LB will also fork some processes named “COM Surrogate”. They may be the ones that needed to be shut down for the installation to continue.

Wouldn’t the “COM Surrogate” go away when rebooted? The issue with updating cited 2 mystery instances of “lightburn.exe” that didn’t occur on Task Manager but at least went away with rebooting.

But the prob with “Disconnected” did not go away with repeated PC rebooting, which is… weird. I seem to recall a plethora of low-level generic processes appearing on Task Manager, which may have been “COM Surrogate”. I will be on the lookout for these. They may in fact by building up, which would be a problem we can reproduce and thus fix

Yes.

I didn’t realize it had called out the processes by name.

One thing to keep in mind is that it’s not only LightBurn that uses COM Surrogate. Any program that uses the same approach as LightBurn for this would generate a COM Surrogate process. In other words, don’t necessarily assume that all COM Surrogates listed are owned by LightBurn.

FTR - the LEFT SHIFT as I described is used on REBOOT or POWER OFF on the PC to clean out troublesome temporary files. If most likely does not apply to your issues - but it could not possibly hurt to try it.

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