Powertoys Process Explorer

[Lynn Hepler]

Onething that annoys me no end about Windows is the old sharing violation error. Often you can't identify what's holding it open. Usually it's just an editor or explorer just pointing to a relevant directory but sometimes I've had to resort to rebooting my machine.

I've had success with Sysinternals Process Explorer. With this, you can search to find what process(es) have a file open, and you can use it to close the handle(s) if you want. Of course, it is safer to close the whole process. Exercise caution and judgement.

Just be very careful with closing handles; it's even more dangerous than you'd think, because of handle recycling - if you close the file handle, and the program opens something else, that original file handle you closed may be reused for that "something else." And now guess what happens if the program continues, thinking it is working on the file (whose handle you closed), when in fact that file handle is now pointing to something else.

Suppose a search index service has a file open for indexing but hasgotten stuck temporarily and you want to delete the file, so you(unwisely) force the handle closed. The search index service opens itslog file in order to record some information, and the handle to thedeleted file is recycled as the handle to the log file. The stuckoperation finally completes, and the search index service finally getsaround to closing that handle it had open, but it ends up unwittinglyclosing the log file handle.

The search index service opens anotherfile, say a configuration file for writing so it can update somepersistent state. The handle for the log file gets recycled as thehandle for the configuration file. The search index service wants tolog some information, so it writes to its log file. Unfortunately, thelog file handle was closed and the handle reused for its configurationfile. The logged information goes into the configuration file,corrupting it.

Meanwhile, another handle you forced closed was reusedas a mutex handle, which is used to help prevent data from beingcorrupted. When the original file handle is closed, the mutex handleis closed and the protections against data corruption are lost. Thelonger the service runs, the more corrupted its indexes become.Eventually, somebody notices the index is returning incorrect results.And when you try to restart the service, it fails because itsconfiguration files have been corrupted.

You report the problem to thecompany that makes the search index service and they determine thatthe index has been corrupted, the log file has mysteriously stoppedlogging, and the configuration file was overwritten with garbage. Somepoor technician is assigned the hopeless task of figuring out why theservice corrupts its indexes and configuration files, unaware that thesource of the corruption is that you forced a handle closed.

Just to clarify, this is more likely to be a result of misbehaving 3rd party apps not using the CreateFile API call correctly than it is to be anything in Windows itself. Perhaps it's a consequence of the design of CreateFile, but done is done and we can't go back.

Now, if Explorer seems to be the culprit here, it may be the case that that's just on the surface, and that the true culprit is something that installs a shell extension that opens all files in a folder for it's own purposes but is either too gung-ho in doing so, or that doesn't clean up properly after itself. Symantec AV is something I've seen doing this before, and I wouldn't be surprised if other AV programs were also to blame. Source control plug-ins may also be at fault.

So not really an answer, but just some advice to not always blame Windows for what may be a badly written 3rd party program (something that can also happen on any other OS which has implicit file locking, but any unix based OS has shared access by default).

Otherwise, kill the desktop Explorer process and do what you want while it's gone. First start a copy of cmd.exe (you need a UI to do your intended cleanup). Make sure there are no non-desktop Explorers running. Then kill the last Explorer with, e.g., Task Manager. Do what you want in the command prompt. Finally, run Explorer from the command prompt, and it will become the desktop.

The above upvoted answers cover situations where a program process is holding the file handle open, which (fortunately) is most of the time - however in some cases (as is occurring on this system at the moment), the system itself holds a file handle open.

You can identify this situation by following the instructions to find the file handle holding process with process explorer above, and noting that the process name is listed as 'system', or by following the the instructions using resource monitor and noting that no image is shown having a filehandle open on your file of interest (Although obviously something does as you can't edit/delete etc the file).

I got turned on to the Free Extended Task Manager a while ago by Jeremy Zawodny's blog, and it's great for tracking down further info on processes too. +1 for Process Explorer as above, too, especially for killing processes that the standard Task Manager won't end.

There is a tool FILEMON and shows open files and handles. Its hard to keep up with its display if you watch it live, it does so quickly. But you can stop it from displaying live and you can watch all file open/write activity. Now owned by Microsoft but originally by Sysinternals

I have set up my first Windows 11 system. And here the Windows 11 task bar sometimes completely disappears. Completely = there is no grey line at the desktop bottom, and nothing happens if I move the mouse pointer there. Ctrl+Esc still works and pops up the App start panel. But no task bar.

This is independent from the task bar "auto hide" setting. It always keeps disappearing in random intervals of hours or mintues. Sometimes it will come back a few minutes later, sometimes not. Sometimes opening an explorer window by Win+E will make it reappear, sometimes not. Sometimes running taskmgr via Win+R will make it reappear, sometimes not.

I am a developer and used to program own workarounds on Windows UI quirks. If there is a solution like "send some WM_xxx message to the explorer process" or "run the program XY" to restore the task bar, I might be able to implement a workaround.

Got a number of Endpoint security 8.1 boxes on which I've loaded the KB6119 HIPS policy. Since I had a script that starts Internet explorer, I made a new policy to append a rule that allows wscript.exe to start C:\Program Files\internet explorer\iexplore.exe (note especially how the underlined part is written). For the record, the script is named script.cmd and contains:

This worked on a couple of systems. However, I was receiving HIPS alerts from other systems. Upon closer inspection the problem was that in the scripts used in those systems, I had written script.cmd with different casing in the words internet explorer, ie:

It seems that the HIPS rule differentiates between these two cases, although it shouldn't (as far as I know, Windows file system names are case insensitive, therefore the first rule should match the 2nd case as well.

The scenario is this: we have a Checkpoint VPN software that does not run well under Windows 10. In order to be able to actually utilize it successfully, a user has to start internet explorer as an admin.

This is problematic as you can understand, since this opens a full can of worms. So we've been instructed to follow this approach: install powertoys and create two scripts. One that launches internet explorer named script.cmd:

Also note that this elevate process not only changes IE permissions but appears to also start it. Existing Eset anti-ransomware rules will not monitor any process startup activity from elevate.exe. HIPS rules are not global in nature. For example; they will monitor IE startup from cmd.exe. They will monitor elevate,exe startup from cmd.exe. If elevate.exe is allowed to start by cmd.exe, anything that elevate.exe starts will be allowed to run. A separate HIPS rule needs to be created to monitor elevate.exe process startup.

Investigation of the properties of the process will show that Notepad is running with SYSTEM level privileges. This is because the child process (notepad.exe) will obtain the privileges of the parent process (lsass.exe).

Executing the binary on the target system will create a new process (iexplore.exe) that will have as a parent the explorer.exe. The shellcode will executed in the memory space of the Internet Explorer process by using the user-mode asynchronous procedure call.

Reviewing the process properties will validate that the parent process is explorer.exe. This proof of concept implements a stealthier process injection method to hide the shellcode inside a process and since explorer and Internet Explorer are valid Microsoft system processes will blend in with the environment bypassing the endpoint detection and response product.

The tool requires the path of the injected process, the path of the shellcode, the parent process name, the file format of the payload and the process injection technique. Executing the following command will inject the shellcode into a new process (calc.exe) using as a parent explorer.exe.

The tool also supports process injection with asynchronous procedure call. Execution of the shellcode will occur before the entry point of the main thread of the targeted process for a more stealthier approach.

There are a variety of approaches that could be used in order to evade detection of EDR products that investigate parent/child relationships. For example VBScript can invoke other system resources to execute malware such as WMI, COM or scheduled tasks. Therefore the parent process will not be WINWORD for example but a process of the Windows operating system.

Scheduled tasks are often used as a persistence method since it allows red teams to execute their trade-craft at a specific date or time. However it could be used as well for parent PID spoofing since a scheduled task can be created directly from a vbscript. The following code will register a new scheduled task that will trigger the execution of a payload after 30 seconds.

3a8082e126