I had a plugin where on specifically for x64 release windows I had arch:AVX turned on, for some reason. This resulted in plugins not being loaded on setups with older cpu’s. No crashes however, and no debug breakpoints ever hit. Obviously I couldn’t reproduce anything on my own machine, so I had to get out of my way to acquire an older one.
I discovered that if you have fatal hardware or software exceptions during DLL initilization & load (ie., before any of “your” code ever runs), the loading process will crash and silently fail, resulting in the plugin not being “discovered”. In this case it was a hardware illegal instruction exception from the cpu. Not all code debuggers break on this, so I had to bring out assembly debuggers like OllyDBG.
In reality, every host can easily see it and do initiate the loading process, however the debug reporting on plugin loading errors from hosts are virtually non-existant.
Tips for Windows:
You can place a messagebox in the plugin creation code to get a chance to attach the debugger before any bad code runs (and in general verify the plugin creater code runs). Since Windows DLLs doesn’t carry metadata like on OS X, every host has to load and open every candidate DLL recursively so if your breakpoint still isn’t hit, either your exporting is wrong, mangled or missing or your architechture is wrong - or the DLLs dependencies are missing (commonly, making release builds with dynamically binded CRT dlls). There are other exceptional cases like my case above.
On OS X there are so many possible issues due to all the metadata, resources and executable formats that usually creating a project from scratch/forking something that works seems to take less time.