How Windows 10 Ransomware Protection interferes with application installs

Three times recently I have had install failures on Windows 10, and three times have fixed them by disabling one of its security features.


“Ransomware protection” does not know anything about ransomware as such, but simply blocks access to files and folders where you are likely to store documents and data. Ransomware works by encrypting your documents and demanding money (usually in the form of bitcoin) to unlock them. Therefore blocking access prevents it from working, or at least that is the idea.

I am all in favour of blocking ransomware, but unfortunately this feature may also break application installs. Worse, they tend to break in ways that do not make the problem obvious to the user.

I installed Docker for Windows, for example (actually just accepted a prompt to upgrade) and it hung on the Installing… dialog.

Another application complained about insufficient disk space.

The problem seems to be related to application shortcuts, which are created in protected folders such as the desktop. Even though the install is running with admin rights, it cannot write these files. What happens next depends on how well the installer handles unexpected outcomes. This is not really a fatal error, but may become so.

What is the solution?

The obvious answer is to turn off controlled folder access before running installers for desktop applications. You can turn it back on afterwards.

Microsoft may say that if we all use Store apps or the Desktop Bridge packager the problem will not occur. The issue is related to the Windows legacy of free-for-all installations and the way Microsoft has been trying for many years (with partial success) to bring it under control. Mobile operating systems tend to be better behaved because they were designed to be locked down and to isolate applications from one another and from the operating system.

2 thoughts on “How Windows 10 Ransomware Protection interferes with application installs”

  1. Any security product that blocks actions without telling the user immediately is not fit for purpose. If the blocked action really was malicious, the user MUST be told they are under attack so they can take appropriate actions and avoid things the security product might not detect. If it’s a false positive, the user MUST be told so they understand why something is breaking and is breaking it. As a software developer, more and more of our time and our users’ time is being wasted by this badly designed garbage, and it’s a real shame to see such a bad implementation of the idea become part of Windows itself (but also no surprise whatsoever, given the quality of Microsoft’s output in the last few years; the company seems to have been taken over by absolutely clueless people compared to the past).

  2. I’ve had a related, but different, issue where if I try to save a Notepad, WordPad or LibreOffice Writer file to the Desktop Controlled Folder Access (CFA) prevents the save until those programs are added to the list of programs that are allowed through CFA.

    Why Microsoft didn’t whitelist its own programs like Notepad and WordPad is beyond me. It’s definitely a badly designed and implemented security feature that requires a lot of babysitting. That’s presumably why CFA is off by default.

Comments are closed.