What’s happening here is simply that Windows Explorer on Windows 11 is a 64-bit process. Because of that, it can only load 64-bit DLLs. A 32-bit DLL, even if it’s properly registered in the registry, is invisible to Explorer. That’s why your extension looks like it’s set up correctly, the registry entries are there, ShellExView lists it, and your 32-bit test program can create the COM object without any trouble. But when Explorer itself tries to find and load the overlay, it skips over your DLL because it doesn’t match its own bitness.

This also explains why you can see other overlay DLLs (that are 64-bit) when debugging Explorer, but not your own. And it explains why your context menu extension worked in 32-bit form under MSIX packaging: in that case, Windows provides some compatibility shims for context menu handlers, but that mechanism doesn’t apply to icon overlays. Icon overlays must match the bitness of Explorer itself.

So the bottom line is that there’s nothing wrong with your registration steps or your implementation. The problem is that you built it as 32-bit, and Explorer won’t load it. The fix is to build and register a 64-bit version of your overlay extension.

If you want your application to support both 32-bit and 64-bit versions of Windows, you’ll need to ship two builds of your DLL: one compiled as 32-bit and one as 64-bit. Then your installer can check which kind of Windows the user is running and register the correct one.