NVIDIA DCH Drivers

I discovered a workaround. Anyone who wants to remove Containers and have nvidia uwp control panel working needs to keep the bindflt.sys file and its registry entry. This is a driver that is removed when removing Containers but must be present for the new nvidia control panel to work. Although it can be disabled without problems.

Mount an untouched image and extract the following items:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\bindflt (Export this to a .reg)
\Windows\System32\drivers\bindflt.sys

Edit the .reg to look like below and import it, copy the file bindflt.sys to \Windows\System32\drivers

Restart if this is an online live system.

For 21H1 my .reg looks like this with the driver already disabled ("Start"=dword:00000004):

Code:
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\bindflt]
"DependOnService"=hex(7):46,00,6c,00,74,00,4d,00,67,00,72,00,00,00,00,00
"Description"="@%systemroot%\\system32\\drivers\\bindflt.sys,-101"
"DisplayName"="@%systemroot%\\system32\\drivers\\bindflt.sys,-100"
"ErrorControl"=dword:00000001
"Group"="FSFilter Top"
"ImagePath"=hex(2):5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,\
  74,00,5c,00,73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,64,00,72,\
  00,69,00,76,00,65,00,72,00,73,00,5c,00,62,00,69,00,6e,00,64,00,66,00,6c,00,\
  74,00,2e,00,73,00,79,00,73,00,00,00
"Start"=dword:00000004
"SupportedFeatures"=dword:00000007
"Type"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\bindflt\Instances]
"DefaultInstance"="bindflt Instance"

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\bindflt\Instances\bindflt Instance]
"Altitude"="409800"
"Flags"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\bindflt\Parameters]
"DebugOptions"=dword:00000000
 
This is very interesting topic as I plan to buy nvidia card in near future, and I am customizing Windows Pro N 1909.
I have removed Store and Containers feature, so I can't even install new nvidia control panel using Add-AppPackage (getting class not registered message). But, I tried to play around a bit, downloaded .appx file from adguard site, unzipped it, since looks like these are nothing but compressed archives. Looks like it can run from anywhere, which is even better, as unzipping to C:\Program Files\WindowsApps is not that straightforward (permission on that folder, which is hidden).

So this is what I got trying to run couple of these .exe files.
nvcplui.exe
1.jpg

NvGpuUtilization.exe
2.jpg

Rest of exe files (NvStTest.exe etc)
3.jpg

This is tested in VM, ofcourse. So if anyone is able to try it this way, would be really nice, until I got hold on some nvidia gpu.

Haven't tried workaround from AeonX with bindflt.sys as no point in that at the moment.

Oh, right, I wanted to try same approach for some other Windows Store app, so I've tried Tidal app, and looks like it works fine (though I do not have tidal account to try it).
4.jpg
 
No workaround needed with new version of NTLite :)

in changelog:
Components: ‘Bind Filter Driver’ split from Containers, needed for many things

Capture.PNG

Enabling Nvidia driver setup installer compatibility protects this component.
 
Or just use NVCP.exe from the last non-DHC driver. You can also do some research and add custom NVidia CP context menu to right-click (on desktop). Works perfectly without bindflt.sys driver, which is also known to be a vulnerability.
 
Or just use NVCP.exe from the last non-DHC driver. You can also do some research and add custom NVidia CP context menu to right-click (on desktop). Works perfectly without bindflt.sys driver, which is also known to be a vulnerability.
Yes, but why have this work if it is much easier to maintain the necessary component? This only takes up a few KB. You can disable this in Extra Services -> Windows Bind Filter Driver

In the future the old version of nvidia control panel may have compatibility issues using newer drivers or new features will not appear available in the app.
 
Bind Filter Driver is used by some system processes and virtualized apps.
For example, program wants to write to \FolderA\File, but Windows will redirect that request to \FolderB\FolderC\File

NVIDIA Control Panel is a weird example. Does it really need bindflt.sys?

No, but they rewrote it as a UWP app and has to follow the rules. You can sideload UWP apps w/o the Store. I think users are overreacting to Store, and removing too many features they don't understand. This breaks poor apps like Control Panel.

If you don't want Store, remove the default apps but leave AppInstaller (one-click install in File Explorer), VCLibs, UI.Xaml, .NET libraries.
Now all future apps like Control Panel work out of the box, including from the NVIDIA installer.
 
NVIDIA Control Panel of the DCH drivers is identical to the Standard drivers but "ported" to UWP. The interface and its use are identical. So I think it's unnecessary to use the standard driver's nvidia control panel. This is a different case from Intel, Realtek control panels and other devices that have the interface adapted following the model of UWP apps.

If you don't want Store, remove the default apps but leave AppInstaller (one-click install in File Explorer), VCLibs, UI.Xaml, .NET libraries.
Now all future apps like Control Panel work out of the box, including from the NVIDIA installer.
I remove this as I'm pretty sure I don't need UWP apps. I prefer to use win32 native applications.
 
NVIDIA Control Panel of the DCH drivers is identical to the Standard drivers but "ported" to UWP. The interface and its use are identical. So I think it's unnecessary to use the standard driver's nvidia control panel. This is a different case from Intel, Realtek control panels and other devices that have the interface adapted following the model of UWP apps.


I remove this as I'm pretty sure I don't need UWP apps. I prefer to use win32 native applications.
NVidia officially stopped releasing non-DCH drivers, so if you want a working nvidia control panel, you need UWP support.
Last WHQL Nvidia driver was 472.12.

However, Hyper-V and VBS are NOT required for UWP support; UI.xaml is indeed required, UAC and UAC virtualization is required, but not Hyper-V or VBS
 
Your point is correct, Hyper-V & VBS are not required for UWP execution.

The problem is DLL dependencies don't always follow the strict lines created by component packages. nuhi's challenge is to determine if NTLite needs to restore a handful of DLL's or registry keys to repair the broken features.

In the Linux model, packages have openly declared dependencies which can be checked. Windows internals does not, sometimes it's trial & error because it's undocumented for outsiders.
 
Yes it is really advisable to keep bindflt, used by many things (preview of this when we tested with Nuhi) :)

Agreed. Bind Filter Driver is a critical component, required by many Windows features (including UWP apps).
There's really no legitimate reason for removing it unless you wanted to break things.
 
Agreed. Bind Filter Driver is a critical component, required by many Windows features (including UWP apps).
There's really no legitimate reason for removing it unless you wanted to break things.
If its critical i wonder how much resources it uses and how spectacularly windows fails if it is disabled.
 
If its critical i wonder how much resources it uses and how spectacularly windows fails if it is disabled.

Filters are kernel drivers, which can be stacked on top of each other in numbered layers. Developers can write new filters which plug in and intercept file and device I/O calls. When processes open/read/write files or devices, their requests get passed down the stack.

Each filter takes a turn and decides if they're interested in answering that request, and performing another action. If the filter's not interested, then the request keeps passing down the stack until it reaches the root driver handling I/O.

There's minimal overhead as the request gets handed off. When a filter does get involved, it's doing extra work as intended.

https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/filter-manager-concepts
filter-manager-architecture-2.gif


What happens in this diagram?

FSFilter Activity Monitor - File Explorer will update the folder view based on detected activity.
FSFilter Anti-Virus - Windows Defender does real-time checking of new files.
FSFilter Replication - Mirroring a file to another location.
FSFilter Compression - NTFS compression
FSFilter Encryption - BitLocker
-> Actual H/W driver that does writing to disk.

When filters stop working, specific Windows features won't do their jobs.
Want another example? DISM depends on Windows Overlay Filter (WOF) to read WIM files.

I hope you get the point. Never remove the filter, instead remove the features/services which do the actual work.
 
Back
Top