IIS 7.5+ 64bit having trouble loading C++ CLR dlls RRS feed

  • Question

  • My team recently upgraded from VS2008 to VS2015. Our project is a combination of C# SDK layers and C++ core libraries that work in mixed mode CLR and direct unmanaged references/pinvoke.

    VS2015 compilations for desktop executables work just fine with managed and unmanaged versions across multiple environments. However, when we use the same .NET drivers and C++ libraries in IIS/bin the web server is unable to load any C++ dll that is compiled with CLR. This is within VS2015 and outside of it on both our development and production box. We can set any C++ driver into managed CLR and we see the failed result:

    Error Could not load file or assembly 'ConfigAuth.DLL' or one of its dependencies. The specified module could not be found.

    The file is clearly found, the PATH variable triple checked. We've run process monitors to find the dll file loading issue and can't seem to find anything that gives a clue as to what is missing. We've had issues in the past with missing redistributable packages and have read that some combinations fail. We've uninstalled and reinstalled these packages, but maybe we are doing it in the wrong sequence/combination?

    Development Box / Configuration:

    Windows 7, 64bit environment

    The following VS C++ Redistributable Packages are installed on the box: 2012,2013,2015 (both x86/64 for each)

    SxS merge modules for 2012-2015 are installed

    All files compile to Win32/x86 platform

    .NET 4.5 is used to compile the ASP.NET WCF Service build as well as all C# managed dlls

    .NET 4.0 is the mscorlib used to compile the C++ CLR

    IIS 7.5+ 64bit having trouble loading C++ libraries compiled using 2015 toolkit on VS2015.

    IIS app pool supports 32 bit assemblies

    IIS app pool has all directory and windows access rights set to access the file

    PATH variable has been set and tested against other files that load just fine as non CLR

    Thursday, September 7, 2017 11:01 PM

All replies

  • Hi kguller,

    Thank you for posting here.

    According to your question is more related to IIS, you could post a new thread in IIS forum for suitable support.

    The CLR Forum discuss and ask questions about .NET Framework Base Classes (BCL) such as Collections, I/O, Regigistry, Globalization, Reflection. Also discuss all the other Microsoft libraries that are built on or extend the .NET Framework, including Managed Extensibility Framework (MEF), Charting Controls, CardSpace, Windows Identity Foundation (WIF), Point of Sale (POS), Transactions. 

    Best Regards,


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact

    Monday, September 11, 2017 6:38 AM
  • Thanks, I've posted this on IIS:
    Tuesday, September 12, 2017 4:05 AM
  • Hello, the IIS forum tried to send me back to this forum.  So, I followed up with some questions there that I'd like to post here to avoid the run around.

    From IIS POST

    All those settings have been triple checked and we have run the same build successfully when we compiled in VS2008.  I agree it should be a C++ issue lacking some sort of assembly, but these files work and compile just fine until they are used in IIS.  Desktop Application entry point versions with the exact same libraries work without any issue.  We actually started in the C++ forum and they sent us here.

    I have also compiled a basic DLL without any dependencies on other libraries in VS2015 and it fails to load into IIS as well, but can be integrated managed or unmanaged into a desktop application.  I can also load that same DLL unmanaged into IIS without an issue.  But as soon as I switch it to managed and it has the CLR it fails in IIS.  The project is set to 4.0 and the CLR version that VS2015 builds the DLL for is 4.0.  It seems like this is a bug in IIS or I'm missing a specific runtime support lib, and I'd like to know what exactly MS needs to run this basic configuration.  I have the VC++ redistributables installed as documented in this post, is there anything else?

    Tuesday, September 12, 2017 1:52 PM
  • @kguller,

    Yep I agree it may related to a setting issue and I would think this is either related to your website setting or iis setting. Anyway, I think we still need to check where your project is trying to load this file.

    See a related case from this SO thread:

    One answer from there is helpful for your issue:

    "ProcMon saved me.

    The path was my problem too. It seems that IIS is creating a shadow copy of each managed dll in C:\Windows\System32\inetsrv folder. But this in not the case for unmanaged code. When it has to load an unmanaged dll, it search the environmental path and not the bin directory of the application in IIS. "

    It does not mean that you have the same problem but we need to use either ProcMon and Dependency Walker to help us check where your app is trying to find the dll and how IIS deployed your dll. In that way maybe we can find out why your project does not know where is the location of the dll.

    As you've already used the tool. Can you check it again and filter your ProcMon log?

    Best regards,


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact

    • Edited by Barry Wang Wednesday, September 20, 2017 6:30 AM
    Wednesday, September 20, 2017 6:29 AM
  • Barry, thank you, your reply was extremely helpful in clarifying where the problem may be.  I fully agree that something like the shadow copy is happening from the article you provided or a location/path issue of some sort.  I ran procman while attempting to compile in VS, which is also failing to load our Managed DLL named WriteAMark.dll.  It is pointing to the correct path to query the file @ C:\git\\2dmi\WebAPI\bin\WriteAMark.dll

    , but after that I'm not sure if it is actually creating shadow copies.  I do see files being created in the "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\975f2368\62a15bbb\assembly\dl3\55a74e83\d0a17be0_5e8ad301\__AssemblyInfo__.ini"  folder, but I'm not sure if those assembly Guids are references to my drivers.

    • Edited by kguller Tuesday, April 24, 2018 11:10 PM
    Tuesday, April 24, 2018 11:07 PM