Windows Defender Controlled Folder Access is promising protection from ransomware, but implementation can put users in a panic.

Listen to this post:

The new feature, which is not enabled by default, is designed to block unfriendly applications from making changes to your files. Built-in applications can make changes, but programs downloaded surreptitiously or otherwise will be blocked from making changes, even for folders that the user running the program has permission to write to, like their Desktop or Documents folders.

Even if a user somehow knew this meant to add the app as an allowed app, would they find the exe?

This behavior of blocking software executing as a permitted user from writing to a user’s folders is critically necessary to block the damaging effects of cryptolocker and other ransomware. As the virus or malware would be running as the user, it would normally have write access to all the same files the user does: access it would use to encrypt and overwrite each one.

Instead, when a program tries to write to a protected folder it will receive access-denied and the user will see an Action Center notice.  The user can decide to mark the application as allowed — trusted to add or edit files in protected locations.

This feature sorely needs a “allow this app” button – and it needs to be effective the instant you click it.

Unfortunately this process is difficult at best and at times nearly impossible. Rather than provide a list of installed applications, the user must manually locate and whitelist an executable file. While I was able to find my Camtasia screen-recording software’s exe files, locating the executable for Paint.NET — what should already be a ‘trusted app’ since it came from the Microsoft (app) Store — proved much more difficult. Store apps in Windows are not installed into the normal Program Files folder in a straightforward way, but are instead in a trusted store with cryptic folder names that may not include the program’s actual name in it.

For example, the current version of Paint.NET from the Microsoft Store installs to C:\Program Files\WindowsApps\dotPDNLLC.paint.net_4.19.6484.0_x64__h55e3w7q8jbva\PaintDotNet.exe. And I forgot to mention: you cannot even open that folder until you edit the NTFS security permissions on it.

Once added as an trusted app, it must be restarted to be effective, which can leave the user stuck, desperately searching for some unprotected location to which they can write their data before closing the program.

And that’s not the worst part. It turns out that adding a trusted app is not effective immediately. To allow writing to protected locations, the app must be restarted. If the user has unsaved information – such as my desktop video recording in Camtasia Recorder – it can leave the user stuck in a logical paradox, desperately searching for some unprotected location to which they can write their data before closing the program [so they can restart it and … I guess … write more data].

You can add an allowed app, but you have to restart the app before it can write to the protected location-often leaving the user scrambling to find a location where they can save their work so they can close and restart the program.

If you fall into this situation where an app isn’t trusted but you need to write data before exiting the program, you’ll need to find a unprotected folder.  Most user documents folders are protected by default, and the root of the system drive and most subfolders are also protected.  However, in the current implementation there is one folder not protected by default: your user account’s profile folder, what *nix would call home.

This folder isn’t prominently surfaced anywhere in the operating system, so you can drill to it directly in the C:\Users folder, or put %userprofile% into any Run box or folder address bar to jump to the current user’s profile folder.

You can also get to it quickly from the left-most drop down menu in a folder’s address bar, or I added my user folder as a Start menu side shortcut too:

These frustrating user experiences are a real hindrance for now, and hopefully are addressed in future iterations. While the most persistent users may eventually have all their favorite common apps marked as trusted, getting to that point would be a painful process. For most users, these failures are a strong deterrent from a feature that would otherwise be powerful protection for the mounting victims to encryption ransom scams.