Windows 10: Unified Write Filter Overlay Full

Hi,While trying the unified write filter feature on Windows 11 IoT Enterprise LTSC, my overlays is getting full very quickly and restarting within 10 minutes. My goal is to use the write protect feature for my drive, and allow it to run 24/7 unattended. The overlay getting full to the point it auto restart is an issue for my intended application. My understanding is that even the exclusion list is written to the overlay, this makes the overlay space filled event faster for my application.Question:Is there a way to auto clear the overlay so that it stops the auto restart when full, if not what

:)

 

Unified Write Filter (Win10LTSB) not working

Hi all

I'm currently trying to migrate from Windows Embedded Standard 7 SP1 (WES7) to Windows 10 LTSB (long term servicing branch). I'm having a major problem with the write protection layer in Win10 LTSB that I'm hoping someone can help with (I think it is a bug
but perhaps I'm doing something wrong).

Note that I have tried both Windows 10 LTSB 2015 and Windows 10 LTSB 2016. I have applied all Windows updates and the Unified Write Filter feature is enabled.

Question 1:

In WES7, the write protection was known as File Based Write Filter (FBWF). I used this to lock down the operating system but allow write access to a data folder on the same disk volume as my application collects and buffers data in real time - ready to be
copied across the network at a later time. This worked fine.

In Win10LTSB, I can't get the write protection (known as Unified Write Filter - UWF) working reliably. I've set up the UWF to protect the C: drive as I did with WES7. I've also set it up to exclude a folder from the write protection layer (lets call it C:\Excluded).
When I create files/data in this folder, they are correctly stored on the disk (as the folder is excluded from the write protection layer) and are still present after a reboot - as they should be. So far, this all works correctly.

The problem is that as files are being stored correctly in this folder, the size of the RAM (or disk) overlay reduces by the same amount. After a few minutes of successfully storing data in this excluded folder, the write protection overlay fills up and
the PC grinds to a halt.

In WES7, files created in an excluded folder did not affect the size of the overlay at all - which is correct. In Win10LTSB, files created in the excluded folder cause the size of the available overlay (RAM or disk) to reduce to the point where the PC will
fall over.

Does anyone have any experience in this area? Have I done something wrong or is this a bug? As it stands, I won't be able to migrate from WES7 to Win10LTSB for my product until this is resolved as I need to collect data dynamically into a folder that is
excluded from the write protection layer.

Question 2:

With WES7, I was able to see which files had been diverted to the RAM overlay using the command \Fbfwmgr.exe /overlaydetail

This permitted me to find out which files were consuming the RAM overlay and add those filenames/locations to the exclusion list as necessary. I can't find any way of looking at the files/folders that are currently consuming the RAM/disk overlay of the Win10LTSB
unified write filter.

Can anyone help?

 

what if overlay exceeds limit in Unified Write Filter(UWF)

I have read about unified write filter. The main working is that overlay is created which write the data on it instead of writing it on volume. Now i am facing a scenario that my overlay size is suppose 1024K and i write 1G data on the protected volume which is more than the overlay size. It gives errors in event log and all the things it should do. On reboot, it vanishes all the written data despite of low size and error messages.

Thanks in advance.

 

what if overlay exceeds limit in Unified Write Filter(UWF)

I recommend start reading here: Unified Write Filter (UWF) feature (unified-write-filter)

The overlay can be in memory or on disk (a hidden file called uwfswap.sys).

It has a predefined size and don't autoadjust or something. If its full, all write requests to the protected volume are blocked, which can lead to apps and also windows hang. Too, a rebbot can take very long time, because windows writes much stuff at shutdown. This can be circumvented by using the Reboot method from UWF itself.