Yep, and there’s way too many of them. I forgot the most frequently used ones — shell extensions. Every time you embed a shell by calling GetOpenFileName/GetSaveFileName/ShBrowseForFolder/etc. you’re loading not just shell32.dll but also a bunch of third-party DLLs who adding their custom context menu entries, or rendering preview thumbnails for their file types, or similar. Technically, every such DLL can do whatever it pleases with your process, with both code and data.

> the signed/checksumed dlls where typically vender dlls or our custom dlls that touched business logic and had to be resistant to injection.

That’s better than nothing, but too many ways to workaround, still. I’m afraid the level of security you want is impossible for consumer-targeted software. Only possible sometimes in enterprise environments, where you can use legal/political methods to solve most of these issues: deny end users from being administrators of the computers they’re using, use group policies to restrict which software they may install, use other group policies to configure Windows security to be way more annoying but slightly more secure, stuff like that.