Bug: Unexpected File Explorer

Hellbovine

Well-Known Member
Update: August 23rd, 2023 (Unresolved)

Summary: File Explorer will randomly appear while using NTLite, but it should not do this.

MORE INFORMATION
OS: Unmodified Windows 10 ISO, version 21H2, build 19044.1288
NTLite: version 2.3.9.9020, default settings

Load a live Windows into NTLite, go to Settings > Windows Update > Automatic driver update mode > Never > Process > it will immediately display File Explorer in a new window, but it should not do this.
 
Last edited:
Not sure if this is a bug, or an intended feature that I don't understand:

Super easy to replicate, just load the deployed/live Windows into NTLite, then go to Settings > Windows Update > Automatic driver update mode > Never

Process it and then it will immediately load File Explorer and make it the active screen for some reason. I'm not sure what I'm supposed to be looking at in File Explorer, why is it appearing? It does this same thing on other options too.
That is by design.

Started happening some years ago, when a process holds NTLite from doing what it does (clean up, in most situations), NTLite kills explorer.exe and re-launch it because exploring mounted folders locked that folder from being removed (cleaned up) and closing windows explorer didn't 'unlock' the folders.

I have used another file manager which causes the same situation, NTLite won't close the file explorer but restart explorer.exe and finishes all ok.
 
It definitely is not intended in the scenario I presented, since all I did was simply have NTLite add a single registry key to the live Windows, and there's all sorts of registry manipulation tools out there that do not have this issue, such as using a .reg file to install a key from the desktop. I understand Kasual's explanation, but I don't see why NTLite struggles and needs to restart explorer.exe when other methods don't have this issue.

It's still technically a bug, even if intended because it's objectively not necessary to make File Explorer appear. Just because the workaround is intended (restart explorer), does not mean that the core issue isn't a bug. I would like to hear from Nuhi on this one because it's clearly been a problem for a while, and the steps I provided to reproduce it could not be simpler, it's literally the easiest and least technical tweak in NTLite.
 
Last edited:
I doubt NTLite is struggling, it runs as admin or TI, so it can do whatever it wants. It just refreshes explorer for you to see the changes maybe. I don't get it why its such a big deal breaker for you. It just restarts and opens explorer exe one more time...
 
Last edited:
It's still technically a bug then, because something is clearly not working as intended, and everyone in this thread agrees to that concept. Just because the workaround is intended (restart explorer), does not mean that the core issue isn't a bug.
Windows Explorer locking files or folders for no reason is a Windows design, not NTLite, restarting Explorer.exe solved too many reports about NTLite freezing at the end of the process or on cache clean up.
I also asked nuhi to removed but I think that now I have a better suggestion: show a popup asking to refresh explorer with a checkbok "Don´t ask again" and explanation about what will do and what would happen later if that checkbox is checked.
 
There is no "file lock". NTLite is just checking for exclusive file access by searching for open file handles. You get the same error with CMD or another console app sitting inside one of the temp folders. It's to guarantee file consistency, so you're not updating files when processing starts.
 
Back
Top