Can't run Dependencies.exe on Windows Server 2012 Standard x64

Unhandled Exception: System.BadImageFormatException: Could not load file or assembly 'ClrPhlib.dll' or one of its dependencies.  is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)
   at Dependencies.Program.Main(String[] args)

[lucasg]

Ok that was a fairly complicated bug to track down. What happened is, on Debug build Dependencies.exe failed to load the packaged msvcp140d.dll so -weirdly enough- the CLR loader folded back to MSVCR120_CLR0400.dll. The loader which managed to load ClrPhlib.dll, but crash whenever it attempted to jit a method from this module :

00007ff8`f71a1f09 : KERNELBASE!RaiseException+0x68
00007ff9`0237ced3 : MSVCR120_CLR0400!_CxxCallCatchBlock+0x169
00007ff8`f4ed75e8 : ntdll!RcConsolidateFrames+0x3
00007ff8`f4ed229f : clr!MethodDesc::MakeJitWorker+0x498
00007ff8`f4ed193b : clr!MethodDesc::DoPrestub+0x94c
00007ff8`f4ec46d5 : clr!PreStubWorker+0x3cc
00007ff8`f4ec6bb3 : clr!ThePreStub+0x55
00007ff8`f4ec6a70 : clr!CallDescrWorkerInternal+0x83
00007ff8`f4ec735d : clr!CallDescrWorkerWithHandler+0x4e
00007ff8`f4f1ec1c : clr!MethodDescCallSite::CallTargetWorker+0xf8
00007ff8`f4f1ee06 : clr!RunMain+0x1e7
00007ff8`f4f1ecfb : clr!Assembly::ExecuteMainMethod+0xb6
00007ff8`f4f1eaf4 : clr!SystemDomain::ExecuteMainMethod+0x57c
00007ff8`f4f1ea72 : clr!ExecuteEXE+0x3f
00007ff8`f4f1ef34 : clr!_CorExeMainInternal+0xb2
00007ff8`f7397b2d : clr!CallDescrWorkerInternal+0x83
00007ff8`f4ec735d : clr!CallDescrWorkerWithHandler+0x4e
00007ff8`f4f1ec1c : clr!MethodDescCallSite::CallTargetWorker+0xf8
00007ff8`f4f1ee06 : clr!RunMain+0x1e7
00007ff8`f4f1ecfb : clr!Assembly::ExecuteMainMethod+0xb6
00007ff8`f4f1eaf4 : clr!SystemDomain::ExecuteMainMethod+0x57c
00007ff8`f4f1ea72 : clr!ExecuteEXE+0x3f
00007ff8`f4f1ef34 : clr!_CorExeMainInternal+0xb2
00007ff8`f7397b2d : clr!CorExeMain+0x14
00007ff8`f7ecea5b : mscoreei!CorExeMain+0x112
00007ff9`021a168d : MSCOREE!CorExeMain_Exported+0xcb
00007ff9`02354629 : KERNEL32!BaseThreadInitThunk+0xd
00000000`00000000 : ntdll!RtlUserThreadStart+0x1d
00000000`00000000 : clr!CorExeMain+0x14
00007ff8`f7ecea5b : mscoreei!CorExeMain+0x112
00007ff9`021a168d : MSCOREE!CorExeMain_Exported+0xcb
00007ff9`02354629 : KERNEL32!BaseThreadInitThunk+0xd
00000000`00000000 : ntdll!RtlUserThreadStart+0x1d

My guess is MSVCR120_CLR0400 is a VisualStudio 2015 redistribuable while ClrPhlib.dll is built using VS2019, and I’ve hit a backward compatibility bug in CLR’s jitter. I did not bother to investigate further …

Why I couldn’t load msvcp140.dll while being present in the packaged release ? Well because of a typo : I exported the 32-bit version on 64-bit builds ! Commit b6c3ce1ec42b81513a202eb5eac77ae8b5ff2f5d fix this issue.

As you said here https://github.com/lucasg/Dependencies/issues/85#issuecomment-526645459, Release builds rely on api-ms-win-crt dlls (also known as “Universal CRT”). Commit 1d15d6e0b90e19d8953fdbbf5f577ec214f2ae3e package also the ucrt in release builds.

I’ve tested it on a Windows Server 2012 R2 stock VM with only .NET Framework 4.6.2, but I appreciate you confirm the fix on your end before closing this issue.

Build artifacts can be downloaded here : https://ci.appveyor.com/project/lucasg/dependencies/builds/27104909

[lucasg]

Thanks for the info, I’ll look into it as well as your PR for apisets parsing @ww898

P.S. On my opinion, using managed C++ library was not good idea because a lot of compatibility issues.

Well you know what they say, hindsight is 20/20 … One day I will rewrite the whole PE parsing in C# (Forshaw already wrote on for NtApiDotNet) and finally get rid of this C++/CLI monstruosity.