Can a Windows DLL have a custom file extension and still work correctly with LoadLibraryExW?

Rohan Pande 515 Reputation points
2026-06-24T05:48:31.62+00:00

I'm working on a C++ project built with CMake where most of my application logic lives inside shared libraries, and the executable (.exe) is just a minimal launcher that loads them dynamically at runtime using ::LoadLibraryExW (). Essentially the exe is a thin bootstrap -- all the heavy lifting is in the DLLs.

I want to give these shared libraries a custom file extension (e.g. .abc or .xyz) instead of the standard .dll.

From documentation of ::LoadLibraryExW it says that The module can be a library module (a .dll file) or an executable module (an .exe file) but nowhere its been said its mandatory so in theory any extension should work.

I've also confirmed that in CMake this is straightforward using:

#CMake Added Line
set_target_properties(MyLib PROPERTIES SUFFIX ".xyz")

So my question is Does ::LoadLibraryExW() work reliably with any custom extension, or are there edge cases where Windows enforces .dll?

Windows development | Windows API - Win32
0 comments
Answer accepted by question author
Taki Ly (WICLOUD CORPORATION) 4,275 Reputation points Microsoft External Staff Moderator
2026-06-24T07:12:52.5233333+00:00

Hello @Rohan Pande ,

To see how the OS handles this scenario, I set up a minimal test environment. I compiled a shared library, explicitly assigned it a .xyz extension, and attempted to load it from a minimal launcher executable using ::LoadLibraryExW(L"mylib.xyz", NULL, 0).

User's image

My observation during this test was that the application successfully mapped the module into memory and executed exported functions without any issues, as you can see in the screenshot of my local run below:

User's image

This outcome suggests that the Windows loader does not strictly enforce the .dll extension for a module to be recognized and loaded correctly.

Reading through the official documentation, this behavior appears to align with how the underlying APIs are designed:

  • In the LoadLibraryExW documentation, the details regarding the lpLibFileName parameter indicate that the function appends the default .dll extension only if the file name extension is omitted entirely. This implies that .dll acts as a convenience fallback rather than a mandatory requirement.
  • Furthermore, according to the PE Format specification, Windows identifies a module's nature through internal binary structures. The PE loader checks for the IMAGE_FILE_DLL (0x2000) characteristic flag within the COFF File Header to confirm that an image is a dynamic-link library, rather than relying on the file name suffix at the memory-mapping level.

Regarding your question about edge cases, while the operating system APIs seem to natively support custom extensions, you might potentially run into scenarios where third-party antivirus software, endpoint protection, or AppLocker policies flag executable code that resides inside files with unrecognized extensions. Testing your launcher and custom libraries against common security tools might be a good idea to ensure they do not cause false positives in a production environment.

Hope this provides some helpful context for your project. If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation.

Thank you.

Was this answer helpful?

1 person found this answer helpful.

0 additional answers

Sort by: Most helpful
Most helpful Newest Oldest

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.