Microsoft just broke some custom folder icons, and it's deliberate

If you installed the Windows 11 June update and noticed that a few of your carefully customized folder icons have reverted to plain yellow defaults, you are not imagining it, and you did not break anything. Microsoft made this happen on purpose, and the company has now confirmed the behavior on its blog.

The short version: Windows 11 will silently ignore custom folder icons and folder names defined through a desktop.ini file if that file came from a source Windows considers untrusted. Instead of honoring your customization, the system falls back to the default icon and name. No warning, no prompt, just a folder that looks like every other folder.

What desktop.ini actually does

To understand why this matters, it helps to know what desktop.ini is in the first place. It is a hidden configuration file that Windows has supported for decades. When you right-click a folder, open Properties, go to the Customize tab, and assign a custom icon, Windows writes those instructions into a desktop.ini file placed inside that folder. The file can set a custom icon path, a localized display name, an info tip, and a few other shell behaviors.

Because desktop.ini can point Explorer at an arbitrary icon resource and can change how a folder presents itself, it is also a small attack surface. A malicious desktop.ini could make a folder masquerade as something it is not, or point to a resource on a remote server. That is the thread Microsoft is pulling on here.

Why Microsoft changed the behavior

The June update adds a security hardening rule around how Explorer evaluates desktop.ini. If the file is judged to have come from an untrusted location, Windows refuses to apply its custom icon and name and reverts to defaults. Microsoft spells out three categories it now treats as untrusted:

• Files downloaded from the internet that carry the Mark-of-the-Web (MOTW), the metadata tag Windows attaches to anything pulled from a browser, email client, or other internet source.
• Files copied from certain remote locations, such as some WebDAV or HTTP-based shares.
• Files sitting on network paths that are not classified as intranet or trusted by your zone policy.

The common thread is provenance. Windows is essentially asking, "do I have a reason to believe this folder's customization instructions came from somewhere safe?" If the answer is no, it declines to follow them. For most people this only surfaces in narrow cases, like extracting a downloaded archive that shipped its own folder icons, or working off a network share that the zone policy treats as external.

Mark-of-the-Web, briefly

Mark-of-the-Web is the mechanism doing most of the work in the first category. When you download a file, Windows tags it with an alternate data stream called Zone.Identifier that records where it came from. This is the same tag responsible for the "this file came from the internet" warnings you see when opening downloaded documents, and it is what SmartScreen and Office's Protected View key off of. By extending MOTW awareness to desktop.ini, Microsoft is reusing existing plumbing rather than inventing a new trust signal.

The trade-off is the usual one for security hardening. The change closes a small spoofing and remote-resource vector, but it also catches legitimate use. Plenty of people distribute folders with custom icons inside ZIP files, and software installers sometimes lay down branded folders the same way. Those will now come up blank unless the source is trusted.

How to get your icons back

Microsoft offers three fixes, and which one you pick depends on your situation:

• Add the source to Trusted Sites. If the icons live on a specific internal server or web location, adding that origin to the Trusted Sites zone tells Windows the content is safe, and the customizations will apply again.
• Enable the "Allow the use of remote paths in file shortcut icons" policy. This Group Policy setting relaxes the restriction for remote-path icon resources, which is the relevant control if your icons are served from a network or remote path.
• Remove the Mark-of-the-Web tag. For a one-off downloaded file, the simplest fix is stripping MOTW. You can do this from the file's Properties dialog by checking the Unblock box, or with PowerShell using Unblock-File. Once the tag is gone, Windows treats the desktop.ini as local and trusted.

Each of these effectively tells Windows the same thing: this file's instructions are safe to follow.

The bigger pattern

This fits a steady direction Microsoft has been moving for years, gradually tightening how much it trusts content based on where it originated. We have seen the same logic applied to macros in Office, to scripts, and to downloaded executables through SmartScreen. Folder customization is a much smaller target, but the principle is identical. Provenance is becoming a first-class input to what Windows will and will not do automatically.

For the average user, the practical takeaway is simple. If your folder icons vanish after the June update, it is a feature, not a fault, and unblocking the offending desktop.ini or trusting its source brings them straight back. You can read Microsoft's own write-up on the change through the Windows IT Pro blog and review the Mark-of-the-Web documentation for the underlying mechanism. For the desktop.ini format itself, Microsoft maintains reference documentation describing every key it supports.