Controlled Folder Access Blocked problem in Windows Defender

Hi Nsmth,

In this thread, on march 25, GreginMich gave excellent advice regarding this

problem. You should go back and read his post.

I don't understand why so many are having a problem with Controlled Folder

Access. GreginMich offers an approach, that should address just about any

problem that there could be with this feature.

However, getting the path for the App that you want to allow, is sometimes

truncated in the notification on the taskbar. That may be contributing to the

difficulty that some are experiencing. The full path for an App that is flagged

by controlled folder access can be found in the Event Viewer.

Open the Event Viewer, and navigate to Windows Defender "Operational.

"Applications and Service Logs" >Microsoft >Windows >Windows Defender

>Operational.   Scan the log for Event ID 1123 or 1127. If the log is too big

to see either of these right away, you can click on "Create Custom View" on

the right side of the screen. Click "All Event IDs" and enter 1123,1127. Click OK

and also click OK on the next screen. You should see just these IDs now.

Right click on the line for one, and click "Event Properties". In the Properties

screen, you will find the full path displayed. If you have several different Apps

that are being blocked, repeat this action on the other entries, and find their

path as well. Use the paths to allow their processes to pass through Controlled

Folders Access, as you have done before. 

Regards,  Glen

To me, Microsoft's current implementation of CFA is so user-unfriendly that it's essentially unusable by the vast majority of consumers.

One simple solution: Just give us a prompt that "Application X is trying to write File Y to Controlled Folder Z."  Then present me with two buttons and a checkbox. The two buttons are "Allow" or "Deny" and the checkbox is "Remember this answer for each time that Application X attempts to write to Controlled Folder Z". 

As it's currently implemented, it's insanity for users to have to remember to turn off CFA at just the right moment and then remember to turn it back on.  And if we forget to turn it off before the infraction, we're only notified AFTER the write fails and we have no way of easily allowing the write to succeed.  Even if we were to comb through our logs (more insanity) we're only given the option of adding an exception AFTER the write has failed.  Are we supposed to add the exception and then go back and retrace our steps in the hope that the original write is attempted again?  Especially when it was likely an app or driver install--are we supposed to reinstall the app/driver?  That re-installation could create a whole new set of problems.

Another simple solution is for Microsoft to allow the write to happen, but to a Quarantined folder, and then alert users that we can optionally and easily right-click on the file in the Quarantine folder and have it moved to the originally intended Controlled Folder.  This solution is not mutually-exclusive with the first solution above, i.e. both solutions would be of value independently and with or without the other solution.

"In short, it's your trashy outdated software that's making it impossible for Microsoft to easily protect you from ransomware, so either get rid of them or live with it."

Included in that trashy outdated software is the latest release of Visual Studio 2017, IISExpress, and many other Microsoft tools. It seems like Defender could at least check the app's certificate before blocking it.

"In short, it's your trashy outdated software that's making it impossible for Microsoft to easily protect you from ransomware, so either get rid of them or live with it."

Included in that trashy outdated software is the latest release of Visual Studio 2017, IISExpress, and many other Microsoft tools. It seems like Defender could at least check the app's certificate before blocking it.

Replys of this kind are not helping anyone.  Why are you even on a Microsoft site if this is what you think of their software?

I was replying to Rob Koch's vitriolic post. See the quotes? Why am I here? Because as a Microsoft stack developer I have better things to do than debug why MSFT's dev tools suddenly stop working with a Windows 10 update.

The stated solution to this problem is to just disable a security feature. Does that seem right to anyone?