Feuerfest

Yesterday I learned something which left in quite a bit of shock.

I have noticed that it takes a considerable amount of time (like 30 seconds) for the video to start playing when I watch movies stored on my NAS from my Windows 10 gaming PC. And stupid me was really searching for any error in my network, my NAS, etc. As VLC worked fine for years. Never ever would I have suspected that Microsoft's corporate policy is likely to blame.

Huh? What?

Why VLC suddenly takes 30 seconds to start (and no it is NOT VLC's fault)

VLC isn't one big monolithic .exe file. It's built almost entirely out of plugins for codecs, demuxers, I/O modules all loaded dynamically at runtime. After all one reason for the popularity of VLC is the vast support for any imaginable media file format. Parsing every single plugin binary on every startup would be slow, so VLC keeps an index of them in a file called plugins.dat. Read the index, load what you need, done in milliseconds.

That's the theory. In practice it means plugins.dat is a single point of failure. If something gets between VLC and that file VLC can't read its index. And what could get into the way? Well.. Maybe.. Microsoft Defender flagging it, scanning it, locking it during a background check. That kind of things. No index means VLC falls back to manually scanning the entire plugin directory from scratch. That's your 30 second hang, right there, every time Defender decides to interfere again. Great! Anti-Viruses make us so secure, right?

This also explains the classic pattern some people report: First launch of the day is agonizingly slow, then it's instant for the rest of the session. Once the cache scan clears and VLC gets its index back, it stays fine until Defender flags it again on some later background pass.

Why the story got messy and I suspect an evil actor to be at play

VideoLAN pinned this on a Defender bug introduced in a Windows 11 update, and pushed vlc-cache-gen.exe (regenerates the plugin cache) as the fix. Fair enough. Except their own bug tracker tells a slightly different story. At least one reporter said regenerating plugins.dat did nothing, but dropping in a known-good cache file did fix it, even though a plugins.dat already existed on disk. That's not "missing cache," that's "Defender interfering with an existing, valid cache." Different failure mode, same symptom.

So both camps in the bug tracker were right for their own case. Some machines just need a cache rebuild. Others have Defender actively poisoning a perfectly fine cache. Either way, Defender is the common denominator.

I however find it suspecting that immediately some people in the Internet used this to start defamatory campaigns against OpenSource software. Claiming "A bug like this should never exist" or "Why VLC needs a plugin-cache at all". Which both are pretty stupid arguments in my view. Anti-Virus scanners are known to be one of the main sources for pain in regards to software stability. The whole AV industry is just a big mess. I've seen enough bad AV-Kernel modules on Linux machines. And if you search for "Anti-Virus scanner bricks Windows PCs" plenty of results will show up. So yeah..

What made me realise something other might be going on is this: One person even claimed he now uses the Microsoft Media Player. Wow! That piece of garbage which can't play many commonly used formats? And lacks so many features VLC has?

Bold claim!

Let's just say I notice this pattern regularly towards OpenSource software. If you can't attack the quality of the software itself.. Go create an artificial fault and use that as base argument for your critic.. Yeah..

And it's not that Microsoft hasn't shown this nasty pattern of force-pushing their services and software onto their users. Even against their will! Even when the users explicitly disabled - or even removed - a feature Microsoft just deliberately enables it again at the next opportunity..

The actual fix I use

Regenerating the cache or reinstalling VLC treats the symptom. It WILL come back the next time Defender scans the folder again. If you want it to actually stay fixed, exclude the VLC folder from Defender scanning:

Windows Security → Virus & threat protection → Manage settings → Exclusions → Add an exclusion → Folder: C:\Program Files\VideoLAN\VLC

Or via PowerShell, if you're scripting this:

Add-MpPreference -ExclusionPath "C:\Program Files\VideoLAN\VLC"

Sadly I trust the VLC project more, than Microsoft fixing this bug...