How to update windows explorer's shell extension without rebooting - windows

There is a windows explorer extension dll.
This dll can be update automatically if there is new one in our server.
I rename the origin dll and download the new dll.
But Windows Explorer never reload a new one.
So I kill the windows explorer and relaunch.
But this is looked very ugly.
And I don't want to recommend a user should reboot.
How can I tell Windows Explorer to reload a new one?

For those still looking for a quicker way, you can try and close all explorer.exe processes and restart one afterwards. This also updates all shell integrated dll's

DLLs are loaded by the program loader, so only at process boot time.
You can make a program that explicitely opens and uses a DLL, and add a command that will close it, reopen it, rebind everything. But you need support of the program for that, so you would need Explorer to support it, or to change its code.
So, with 99% certitude, you can't do what you want without restarting windows explorer. At all.

Related

What Microsoft service handles file explorer functions, like copy pasting, right click on a folder

I am using Windows 10 and whenever I try to copy paste some content in any folder, my system refreshes (reloaded) and file explorer window closed without executing the copy-pasting task. On right click on any folder, also refreshes the system and nothing happens.
To my knowledge, some Microsoft service is causing this issue, don't know which service. Any leads, please?
I tried to run the system on safe mode with basic services and it works fine. On the other hand, when I disable all the 3rd party services and restart the system with only Microsoft's services, the same issue again. that means there is some Microsft services which are causing the issue.
try to run Windows on safe mode, and enable one by one each service, spaced by tests, and if your poblem occur after enabling a service, I think you would find out wich service is causing your problem
And then, Google "(service name) problem copy paste Windows 10" and see if others have this problem
hope it help

Delete Opened File by Explorer

I create a shell extension (DLL) that work properly, But when using the Uninstaller to remove the program that DLL not removed becuase it opened by Windows Explorer & i must use TaskManager to first close Explorer.exe then run it again and delete manualy that file (Shell Extenstion Dll),
Now my qustion is, How to delete Shell Extestion files in the Uninstaller script? I use Nullsoft Scriptable Install System 2.46 (NSIS) to create Setup program.
There is no good way to uninstall shell extensions on Windows.
Your best option is to try to delete the .dll and fall back to a reboot: Delete /RebootOK "$InstDir\MyExt.dll".
Another alternative is to try to move the .dll to %temp%. This will not unload the extension but it will allow you to delete everything else and the extension will not load the next time the user logs in. (This will only work if it is on the same volume as %temp%?)
It is important to remember that any application that uses the Open/Save common dialog or internally uses SHGetFileInfo(), IShellFolder or IShellItem could have loaded your extension so just killing Explorer might not be enough.

the action can't be completed because the folder or a file in it is open in another program

When deleting a folder that contains a file that is in use, it is common to see the following Windows 7 message,
"The action can't be completed because the folder or a file in it is open in another program."
I commonly have 10-20 programs open, 30-40 folders open, etc. In short, I have many executables running and many windows explorers open.
Does anyone know a simple trick to determine which program is using the file?
Does anyone know a simple trick to determine which file is blocking the delete operation?
This information would be highly useful to display in the Windows 7 'folder in use' dialog, but it is missing.
Consequently I have to close many of my open applications and folders to complete the delete operation. This is annoying because I have to re-open them after deleting them.
Have you seen this other question or this one?
I use to run ProccessExplorer and Find for the blocked folder.
Closing the application Malwarebytes allowed me to delete what I needed to via Windows Explorer.

Correct way to restore Firefox preferences when Add-On uninstalled by external application

I have written an application suite on Windows which amongst other things installs a Firefox add-on which once run modifies the Firefox network preferences by interfacing with nsIPrefService.
The extension itself resides in a folder under Program Files along with other parts of the application which work together with each other.
Since the application consists of a number of components, the correct way to uninstall it is via the Control Panel or via an uninstall shortcut I provide for the users.
I have no control over whether Firefox will be running or not when the user chooses to uninstall (possibly I could try to detect if it's running in the uninstaller and request the user close it to continue).
Since the purposes of the uninstaller is to remove all traces of the program from the end-users system i.e:
all the files under the Program Files folder, including the extension components
remove the add-on from Firefox (by removing the registry key under HKEY_CURRENT_USER\Software\Mozilla\Firefox\Extensions, causing the add-on to unregister on next Firefox restart)
remove application specific registry keys
Then after uninstall there isn't any of my code left on the users system capable of restoring the network preferences to what they were before the component was installed. This results in end-users not being able to browse the web and being very frustrated!
The only way I can figure out how to do this at the moment is to have my component write to the window's registry the location of the users profile folder - which I can do with my add-on:
Components.classes["#mozilla.org/file/directory_service;1"]
.getService(Components.interfaces.nsIProperties).get("ProfD",
Components.interfaces.nsIFile).path
And then have my uninstaller modify the prefs.js file in that location directly. But this will only work if I can guarantee Firefox isn't running during uninstall (since prefs.js is re-written on FF close)
To me this is not an elegant solution:
It seems not to be future proof since it is dependent on the format and symbols used prefs.js which may change in future FF releases.
Firefox has a nasty habbit of not always closing properlly (sometimes other installed add-ons prevent it from completely unloading from memory. This would break my uninstaller).
This wouldn't work (without elaborate modification) if the user has multiple FF profiles setup all using my add-on.
Is there a better or "standard" way to achieve this simple task?
Did you try to package defaults files (defaults/preferences/myprefs.js) in your extension? I didn't check if it works for overriding Firefox-wide defaults, but it should.
Can't the uninstaller "insist" that Firefox be closed? eg,
check if FireFox is open
if open, inform user "FF must be closed, or cancel uninstall" ok/cancel
loop
I've had several installers do this to me. Not unistallers, though, that I can remember.
Also, this doesn't future-proof the solution, nor deal with profiles.

Releasing Windows file share locks

This problem crops up every now and then at work. Our build machine can have it's files accessed via a normal windows file share. If someone browses a folder remotely on the machine, and leaves the window open overnight, then the build fails (as it has done now). The explorer window left opened points at one of the sub folders in the source tree. The build deletes the source, and does a clean checkout before building. The delete is failing.
Right now, I'd like to get the build to work. I'm logged in from home, and I'd rather not reboot the build machine. I'm unable to get hold of the person whose machine is looking and the files, and I can't remotely reboot their machine.
When a windows share has a lock, the locking process is System, so I don't think I can kill it, as with normal locks.
Does anyone know a way to release the lock on a shared folder without having to reboot the machine?
If you are admin on the server sharing the file over the network, you can use the Windows in-built feature:
Start → My Computer → Right-click → Manage gets you to the Computer
Management console
In the left nav, navigate to Systems Tools → Shared Folders
You can view Shares, Sessions & Open Files here. This allows you to find out who has opened which files from which workstations.
Right-click on an item in the list to be able to remove the file lock.
Hope this helps.
Found a solution.
Find the process using Process Explorer:
Download and extract procexp.exe
In Process Explorer use the "Find Handle or DLL..." command from the "Find" menu
Enter in the name of the directory which is having trouble deleting
A list of open files which match that name should be shown. Take some guesses and find which one is failing to be deleted. If the file is locked by a windows share, the process holding the file will be System
Note down the directory which was left open
Download and install the Unlocker (Warning: Link removed, as it contains malware)
Install Unlocker, disabling the option for Explorer extensions and other junk
Unlock the directory
Open up a cmd window, and navigate to C:\Program Files\Unlocker
From the cmd window, run Unlocker.exe "the-path-to-the-locked-folder"
A dialog will pop up confirming the lock release. Use the unlock button to unlock the file
Now the directory should be unlocked, and can now be deleted.
Try Process Hacker:
https://wj32.org/processhacker/
Process hacker is like Process Explorer on steroids.
To find the offending process, press CTRL+F or click the "Find Handles of DLLs" button and search for the file name.
Once you find the file in the find handles dialog, you can simply right click the file there and choose "close". (at least for v2.39.124)
Older versions had a "terminator" option in the context menu of the process.
Right click on the offending process --> Miscellaneous --> Terminator --> Select termination techniques. Note that some are possibly dangerous and may have unintended consequences.
I've had similar problems, and none of these suggestions I've seen above look suitable for automated overnight builds (as the original poster implied) because they all require manual effort to hunt down and kill the locks.
The only method I've tried that seems to work reliably is to remove the share itself, make the build, then add the share back. Here's one way of removing the share automatically:
D:\Projects>net share Projects /DELETE /Y
Users have open files on Projects. Continuing the operation will force the files closed.
Projects was deleted successfully.
(NOTE: Creating the share again automatically can be a pain if the privilege groups you need to give it are messy.)
The way i do it is by using both OpenFiles.exe and Handle.exe
You can run them in any order and you will have your resource fully unlocked.
OpenFiles: to disconnect File Sharing sessions
Handle.exe: to release any open handles (don't try to close handles belonging to pid4, since that's the system process)
You can automate this by using powershell, batch, or any language of your choice.
Another option is, starting from Windows Vista, to use the Windows tool built into the system:
monitor resources: perfmon.exe /res
Extracted from: Http://www.sysadmit.com/2017/06/windows-how-to-know-that-process-has-open-a-file.html

Resources