Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

LoadLibrary fails with error 4250: This operation is only valid in the context of an app container

Ask Question

LoadLibrary("my.dll") returns fine when building my project in VS 2013 with v120_xp toolset. But on VS 2017 with v141_xp toolset (Platform is 7.1) it returns NULL and error code 4250. I made sure to do a clean build both times.

I'm not able to step into LoadLibrary (F11).

After executing that line ProcessMonitor shows FILE LOCKED WITH ONLY READERS on CreateFileMapping and NAME NOT FOUND on HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\PreferExternalManifest on RegQueryValue, but otherwise all SUCCESS

dumpbin /headers is same for both versions of my.dll

Dependency Walker has errors like a circular dependency, unresolved export etc. but the 2013 version that works appears to have the same errors. With VS 2017 my.dll has additional dependency UCRTBased.dll, vcruntime140d.dll.

my.dll is statically linked against Boost 1.64 & TBB but both those were built without any windows store or universal options. I'm using windows 10 and cmake 3.8. There are no changes to the cmake files that generate the VS solution.

Here is the dependency walker profile:

LoadLibraryA("my.dll") called from "d:\myproject\x64\debug\my.EXE" at address 0x00007FF7FCED1DA2.
Loaded "d:\myproject\x64\debug\my.DLL" at address 0x00007FFA49D40000.  Successfully hooked module.
Loaded "d:\myproject\x64\debug\abc.DLL" at address 0x00007FFA45190000.  Successfully hooked module.
Loaded "c:\windows\system32\OLEAUT32.DLL" at address 0x00007FFA839F0000.  Successfully hooked module.
Loaded "c:\windows\system32\MSVCP_WIN.DLL" at address 0x00007FFA83010000.  Successfully hooked module.
Loaded "c:\windows\system32\OLE32.DLL" at address 0x00007FFA83750000.  Successfully hooked module.
Loaded "d:\myproject\x64\debug\def.DLL" at address 0x00007FFA67FD0000.  Successfully hooked module.
Loaded "d:\myproject\x64\debug\TBB_DEBUG.DLL" at address 0x00007FFA62BE0000.  Successfully hooked module.
Unloaded "d:\myproject\x64\debug\abc.DLL" at address 0x00007FFA45190000.
Unloaded "d:\myproject\x64\debug\TBB_DEBUG.DLL" at address 0x00007FFA62BE0000.
Unloaded "c:\windows\system32\MSVCP_WIN.DLL" at address 0x00007FFA83010000.
Unloaded "c:\windows\system32\OLEAUT32.DLL" at address 0x00007FFA839F0000.
Unloaded "c:\windows\system32\OLE32.DLL" at address 0x00007FFA83750000.
Unloaded "d:\myproject\x64\debug\def.DLL" at address 0x00007FFA67FD0000.
Unloaded "d:\myproject\x64\debug\my.DLL" at address 0x00007FFA49D40000.
LoadLibraryA("my.dll") returned NULL. Error: This operation is only valid in the context of an app container (4250).
                Forget Dependency Walker. It hasn't been updated in ages, and completely fails to address the refactored system modules introduced in Windows 7. It's output is often misleading. Instead, show the code you are using, and how you determine the error code.
– IInspectable
                Dec 13, 2017 at 18:41
                Yes it's the right directory. I can see transitive load library calls in processmonitor and log messages in the output window. It isn't reaching the DllMain breakpoint in my.dll.
– satish b
                Dec 12, 2017 at 7:30
        Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.