0xc000007b load-time error with OpenCL library on Windows

I am writing client-server aplication which exchange OpenCL functions and execute them on server. However I can not link OpenCL properly. Program compiles but on run shows 0xc000007b error.

1. I am using Visual Studio 15 2017
2. Whole solution is build for x64
3. Every dependency is x64 and before linking OpenCL worked flawlessly.
4. I am using Intel SDK platform(newest).
5. IMPORTANT, as long as I am including cl.h header, link with CMake, and don't use any OpenCL function, everything works.
6. I am using cmake for building but at this point(I've really tried everything) any solution will please me, even changing properties in VS manually.

I know that error code 0xc000007b is caused by loading x32 dlls into x64 project, however I don't think it is an issue here.

Main CMake:

find_package(OpenCL REQUIRED)

# include directories
include_directories(${OpenCL_INCLUDE_DIRS})
message(STATUS "opencl_include: " ${OpenCL_INCLUDE_DIRS})

# link libraries
link_directories(${OpenCL_LIBRARIES})
message(STATUS "opencl_lib: " ${OpenCL_LIBRARIES})

Server CMake:

add_executable(server ${SRC_HEADERS} ${SRC})

target_link_libraries(server
  ${OpenCL_LIBRARY}
)

CMake output:

opencl_include: C:/Intel/OpenCL/sdk/include
opencl_lib: C:/Intel/OpenCL/sdk/lib/x64/OpenCL.lib

In Build/bin/Debug catalog OpenCL.dll is created properly. I have tried coppying files into source directory, linking it by hand in cmake and setting properties in Visual Studio instead of cmake. Still same issue.

I've shortened code to show only important parts, if I've missed anything relevant let me know, I will include it into my question.

EDIT:

I've also tried to link x86 OpenCL.lib version, in that case there is a compile error:

unresolved external symbols

There could be several reasons for the error, but to start troubleshooting, you can verify the following:

1) Whether you actually built a 64-bit DLL and not a 32-bit DLL, and

2) Windows itself is actually loading your 64-bit DLL at runtime, and not a 32-bit DLL that happens to have the same file name as the 64-bit DLL.

For 1), you can use dumpbin, or a utility such as Dependency Walker to verify that the DLL being build is 64 bit.

If after applying step 1), you have verified that the DLL is 64-bit, step 2) is the next thing to verify. Since you mentioned in the comments that you have verified the DLL being built is 64-bit, then you should try step 2).

For step 2), when Windows attempts to load a DLL at runtime, the first name that Windows encounters that matches the DLL file name will be loaded, regardless if it is the right DLL or not in terms of bitness level. The issue comes when there are 2 (or more) DLL's with the same exact name, but have differing "bitness" levels, i.e. 32-bit or 64-bit than the application.

If you're running a 64-bit application and Windows tries to load a 32-bit DLL, then you will get the 0xc0000007b error -- the same vice-versa, where loading a 64-bit DLL into a 32-bit application causes the same issue to occur.

This link describes the search logic that Windows uses when loading DLL's. Make sure that Windows is not inadvertently picking up a DLL that matches the name, but not the same application bit-level.

For most non-trivial situations, this error will be one where the incorrect DLL is found on the system path and thus Windows attempts to load it. But as the link suggests, there are other scenarios that would cause Windows to pick a DLL (too numerous to mention, so look at the posted link).

Unfortunately this is how Windows works, so be careful when you have both 32 and 64-bit versions of a DLL with the same name, and the potential for one or the other to get loaded by Windows is a possibility.