Blocking legacy file system filter drivers

Starting in WindowsВ 10, version 1607, administrators and driver developers can use a registry setting to block legacy file system filter drivers. Legacy file system filter drivers are drivers that attach to the file system stack directly and don’t use Filter Manager. This topic describes the registry setting for blocking and unblocking legacy file system filter drivers. It also describes the event entered into the System event log when a legacy file system filter is blocked and how to check if the OS has legacy file system drivers running.

For optimal reliability and performance, use file system minifilter drivers with Filter Manager support instead of legacy file system filter drivers. To port your legacy driver to a minifilter driver, see Guidelines for Porting Legacy Filter Drivers.

How to block legacy drivers

Use the IoBlockLegacyFsFilters registry key to specify if the system blocks legacy file system filter drivers. When blocked, all legacy file system filter drivers are blocked from loading. For the registry changes to take effect, perform a system restart.

The registry key must be created under the following registry path:

The valid DWORD values for the IoBlockLegacyFsFilters key are as follows:

IoBlockLegacyFsFilters value	Description
1	Legacy file system filter drivers are blocked from loading or attaching to storage volumes.
0	Legacy file system filter drivers are not blocked. In this release, this is the default behavior.

This is what the key looks like in Registry Editor:

Example: when a legacy driver is blocked from loading

An Error event is logged to the System event log when a legacy file system filter driver is blocked from loading, as shown here:

Event property	Description
Log Name	System
Source	Microsoft-Windows-Kernel-IO
Date	12/29/2015 2:55:05 PM
Event ID	1205
Task Category	None
Level	Error
Keywords
User	CONTOSO\user
Computer	user.domain.corp.contoso.com
Description	Windows is configured to block legacy file system filters. Filter name: \Driver\sfilter

How to check if legacy drivers are running

If you’re unsure which filters are legacy file system filter drivers or want to make sure that they’re not running, you can perform the following:

1. Open an elevated Command Prompt by selecting and holding (or right-clicking) a cmd.exe icon and selecting Run as administrator.
2. Type: fltmc filters
3. Look for legacy drivers, they’re the ones with a Frame value of .

In this example, the legacy file system filter drivers, named AVLegacy and EncryptionLegacy, are marked with the Frame value. The file system driver named AVMiniFilter does not have the Frame value because it is a minifilter driver (it does not attach to the file system stack directly and uses Filter Manager).

If you see that legacy drivers are still running after you block legacy file system filter drivers, make sure you reboot the system after setting the IoBlockLegacyFsFilters registry key. The setting will not take effect until after a reboot.

If your system has legacy file system filter drivers, work with the respective ISVs to get the Minifilter version of the file system driver. For info about porting legacy file system filter drivers to minifilter drivers that use the Filter Manager model, see Guidelines for Porting Legacy Filter Drivers.

LockFile function (fileapi.h)

Locks the specified file for exclusive access by the calling process.

To specify additional options, for example creating a shared lock or for block-on-fail operation, use the LockFileEx function.

Syntax

Parameters

A handle to the file. The file handle must have been created with the GENERIC_READ or GENERIC_WRITE access right. For more information, see File Security and Access Rights.

The low-order 32 bits of the starting byte offset in the file where the lock should begin.

The high-order 32 bits of the starting byte offset in the file where the lock should begin.

The low-order 32 bits of the length of the byte range to be locked.

The high-order 32 bits of the length of the byte range to be locked.

Return value

If the function succeeds, the return value is nonzero (TRUE).

If the function fails, the return value is zero (FALSE). To get extended error information, call GetLastError.

Remarks

If the call to LockFile completes synchronously, a completion entry may not be queued when a completion port is associated with the file handle.

The UnlockFile function unlocks a file region locked by LockFile.

Locking a region of a file gives the threads of the locking process exclusive access to the specified region using this file handle. If the file handle is inherited by a process created by the locking process, the child process is not granted access to the locked region. If the locking process opens the file a second time, it cannot access the specified region through this second handle until it unlocks the region.

Locking a region of a file does not prevent reading from a mapped file view.

You can lock bytes that are beyond the end of the current file. This is useful to coordinate adding records to the end of a file.

Exclusive locks cannot overlap an existing locked region of a file. For more information, see LockFileEx.

If LockFile cannot lock a region of a file, it returns zero immediately. It does not block. To issue a file lock request that will block until the lock is acquired, use LockFileEx without the LOCKFILE_FAIL_IMMEDIATELY flag.

If a process terminates with a portion of a file locked or closes a file that has outstanding locks, the locks are unlocked by the operating system. However, the time it takes for the operating system to unlock these locks depends upon available system resources. Therefore, it is recommended that your process explicitly unlock all files it has locked when it terminates. If this is not done, access to these files may be denied if the operating system has not yet unlocked them.

In WindowsВ 8 and Windows ServerВ 2012, this function is supported by the following technologies.

How to Identify which Windows Process is Locking a File or Folder

While attempting to delete, move, or rename a file or folder you get a Windows warning message; the Operating System refuses to complete the operation.

This article helps identifying the process that currently has a handle on the file or folder you are attempting a maintenance operation on.

Symptoms

When trying to delete, move, or rename a file you get a Windows system warning message:

• «Cannot delete file: Access is denied».
• «There has been a sharing violation».
• «The source or destination file may be in use».
• «The file is in use by another program or user».
• «Make sure the disk is not full or write-protected and that the file is not currently in use».

How to Solve the Issue

One of the easiest ways to handle locked files or folders is to use Microsoft Sysinternals Process Explorer.

Identify what program is using a file

Using Process Explorer there is a simple way to find the program:

1. Open Process Explorer
   • Running as administrator.
2. On the toolbar, find the gunsight icon on the right.
3. Drag the icon and drop it on the open file or folder that is locked.
4. The executable that is using the file will be highlighted in the Process Explorer main display list.

Identify which handle or DLL is using a file

1. Open Process Explorer
   • Running as administrator.
2. Enter the keyboard shortcut Ctrl+F.
   • Alternatively, click the “Find” menu and select “Find a Handle or DLL”.
3. A search dialog box will open.
4. Type in the name of the locked file or other file of interest.
   • Partial names are usually sufficient.
5. Click the button “Search”.
6. A list will be generated.
   • There may be a number of entries.

Release the lock on the file or folder

To release the lock on the file you are attempting the maintenance operation on, you will need to kill the appropriate process. An individual program or handle in the list provided by Process Explorer can be killed by:

1. Selecting the process/handle/program entry.
   
2. Pressing the delete key.

Proceed with care when deleting handles as this may generate erratic behavior and instabilities may occur.

How to explicitly lock a mounted file system?

How do i write to a physical drive in Windows 7?

I am trying to write to a physical disk (e.g. \\.\PhysicalDrive0 ) in Windows 7.

This question has been asked to death, but has never been answered. It is something that used to work in Windows XP, but Microsoft intentionally broke in Windows Vista. Microsoft provides hints about how to do it, but nobody has even been able to figure it out.

It used to work

In the olden days, writing to a physical disk was allowed (as long as you were an administrator). The method to do it was even documented in a Knowledge Base article:

To open a physical hard drive for direct disk access (raw I/O) in a Win32-based application, use a device name of the form

where N is 0, 1, 2, and so forth, representing each of the physical drives in the system.

You can open a physical or logical drive using the CreateFile() application programming interface (API) with these device names provided that you have the appropriate access rights to the drive (that is, you must be an administrator). You must use both the CreateFile() FILE_SHARE_READ and FILE_SHARE_WRITE flags to gain access to the drive.

All that changed in Windows Vista, when addition security restrictions were put in place.

How do you write to a physical disk?

Many people, and many answers, on many stackoverflow questions confuse:

• writing to a physical disk (e.g. \\.\PhysicalDrive0 ), and
• writing to a logical volume (e.g. \\.\C$ )

Blocking Direct Write Operations to Volumes and Disks

Write operations on a DASD (Direct access storage device) volume handle will succeed if:

• the file system is not mounted, or if
• The sectors being written to are the boot sectors.
• The sectors being written to reside outside file system space.
• The file system has been locked implicitly by requesting exclusive write access.
• The file system has been locked explicitly by sending down a lock/dismount request.
• The write request has been flagged by a kernel-mode driver that indicates that this check should be bypassed. The flag is called SL_FORCE_DIRECT_WRITE and it is in the IrpSp->flags field. This flag is checked by both the file system and storage drivers.

In my case i am asking about writing to a Physical, not a Logical one. Microsoft notes the new set of restrictions on writing to a physical disk handle:

Write operations on a disk handle will succeed if:

• The sectors being written to do not fall within a file system.
• The sectors being written to fall within a mounted file system that is locked explicitly.
• The sectors being written to fall within a file system that is not mounted or the volume has no file system.

• My sectors being written do fall within a file system —> fail
• My sectors being written do fall within mounted, unlocked, file system —> fail
• My sectors being written do fall within a file system that is mounted, and in inside a logical volume that has a file system.

The hints on how to make it work revolve around:

• unmounting a file system
• locking a file system

But the question is how do you unmount a file system? How do you lock a file system?

What are you doing now?

I am able to read all physical sectors of a disk; that is no problem. The problem is when i want to write to a physical sector of the disk.

The current code i have is, in pseudo-code:

i can open the physical disk for GENERIC_READ + GENERIC_WRITE access

it doesn’t fail until the actual WriteFile , which fails with:

How to do what Microsoft says

Microsoft said that my write would fail, and they were right. They said that i need to explicitly lock the file system:

Write operations on a disk handle will succeed if:

• The sectors being written to fall within a mounted file system that is locked explicitly.

Except i don’t know how to do that.

I know i probably have to use DeviceIoControl and one of the IOCTLS to «lock» a volume. But that presents three challenges:

• figuring out which volume(s) are on the physical disk selected
• figuring out which IOCTL to use
• figuring out how to unlock the locked volumes

Ignoring those problems, i blindly tried the LockFile API. Just before calling WriteFile :

Windows 2008 R2 — Kernel (System Process PID=4) is locking files and folders

Windows 2008 R2 — Kernel (System Process PID=4) is locking files and folders for a long time. For example when deleting a file, the file may remain locked for 1 minute or more and only after that be deleted. On another occasions I encountered files or folders I could not delete. ProcMon showed that the System Process was holding a handle to those resources for a couple of minutes and then released them None of the resources I mentioned were system resources, only files and folders installed be me and handled by my applications.

8 Answers 8

As Dani has already mentioned in the comment:

It’s a bug in Windows 7 and likely in Windows Server 2008 (possibly 64bit versions only). It surfaces when you disable Application Experience service.

Re-enabling this service has fixed this problem for me.

A bit more info here as to why it’s causing a problem.

List of other SO questions which seem to be related:

Files accessed through a share will be locked by the system process (PID 4).

Try opening compmgmt.msc -> System Tools -> Shared Folders -> Open Files to see if the locked file is listed there

See also the sysinternals forum for a way to replicate this.
Not all applications lock files when they are opened, Excel however does.

In my case, it was fixed by a simple command in the command line:

I hope that helps.

Hope this helps others.

open windows run and lauch mmc.exe

File -> Add or Remove Snap-ins —> Shared Folders —> localcomputer

Select Open Files scroll down to the directory or file and right click to close.

You can also get the username that has the lock and go to sessions and right click —> close session.

In my case it was MacOS 10.13 holding file locks open. https://support.apple.com/en-us/HT208209

I had this issue when trying to rename a folder. I had to stop the server service while performing the rename. Just restarting didn’t help, as the system process re-locked the folder as soon as the server service restarted.

Make this and resolve the problem:

Go to Services and activate Application Experience.

Tried all these.

Even copying the file, deleting the original, renaming copy to original name (all on server) would immediately tell me the user had it locked.

used Unlocker to clear the file locks. Copied the file OFF THE SERVER to a desktop. Deleted the original file off the server. Changed the filename of the copy on the desktop. Renamed it back to the original name on the desktop. Put the file back into the original location ON THE SERVER.

Had this issue just now whilst trying to replicate data to a new file server (both source & destination servers running Windows 2008 R2).

PID 4 was found locking the file (using procexp as above), but Application Experience has never been installed on either server & the file was not shown in the list of open files.

Fortunately we use scheduled shadow copies on this server (to enable users to self-serve most file recoveries). I just used the Previous Versions option (available through Properties of the containing folder), selected the most recent copy of the file & copied it to somewhere else, then deleted and replaced the problem file.

You might need to delete the containing folder to delete the file — which could be a problem if lots of files in use obviously (this wasn’t an issue for me given this was the only file in the folder).

For a one-off issue like I had (single locked file for the whole server drive), this worked without any disruption to the server or users.