Plugin won't scan because api-ms-win-crt-runtime-l1-1-0.dll is mising

Audio Plugins
1

I build my Windows plugins with VS2015. Some users on Windows 7 and 8 are reporting my plugins won’t scan because api-ms-win-crt-runtime-l1-1-0.dll is missing. I added the VS2015 redistributable to my installer. I set my platform toolset to v140_xp and still the plugins won’t load. What really odd, my app, built with similar settings will launch just fine.

Is users run Windows update to install Universal CRT then the plugins will run, but I’d rather not rely on users being up to date with their windows updates.

2

Switched to static runtime and that fixes it, but would like to avoid this as it makes each plugin larger.

3

In general linking the static runtime into an arbitrary DLL is pretty dangerous - unless

  • you’re sure the host executable is using exactly the same static runtime (generally only the case if it’s also your own executable)

  • you’re extremely careful about what you pass between the host executable and don’t include anything which requires memory allocations (std::string, for example)

otherwise you may run into some pretty difficult to debug memory problems later on.

However, thankfully, the interfaces to all the plug-in formats only rely on plain old data types, so bullet point number two saves us in this case and we’re free to use the static CRT if we wish.

I’m afraid I’m not sure why the dll isn’t being found. There are various reports on the web of people complaining that the VS2015 redistributable itself fails to install if a machine hasn’t received some more recent Windows updates, so that may be the culprit. This doesn’t explain why your standalone app works though…

One thing I can suggest is to use Process Explorer

to watch what your standalone app is doing.

4

I ran into the same kind of errors when trying to build a dll with MSVC 2015 that could run on windows XP. MSVC2015 has a new way of loading dlls that isn’t even available on XP and probably was missing from the win7 & 8 machines that didn’t work.

The solution was static runtime, the _XP toolset and lastly adding a compiler flag “/Zc:threadSafeInit-”. This flag forces MSVC to use the old (non-threadsafe) method to load dlls which works on machines without the new loading mechanism.

Using the static runtime IMHO works just fine for plugins and saves a lot of hassle with people not having the latest runtimes installed.