Windows 10 64-bit, VS2019 16.11.9
I have a C++ (native only) project which builds and executes on my development system, but on other Windows 10 systems, requires DLLs libiomp5md.dll and vcruntime140.dll to run. On other Windows 7 systems, it fails to run because api-ms-win-core-path-l1-1-0.dll is missing.
How can I determine specifically which function calls in my project are causing the requirements for vcruntime140.dll and api-ms-win-core-path-l1-1-0.dll?
I understand that api-ms-win-core-path-l1-1-0.dll is not a file, but a kind of link that Windows uses to locate the actual DLLs required, so I need to find a way to supply or point to these DLLs to allow execution on Windows 7.
Here is the output from dumpbin /dependents:
File Type: EXECUTABLE IMAGE
Image has the following dependencies:
UxTheme.dll
libiomp5md.dll
api-ms-win-core-path-l1-1-0.dll
KERNEL32.dll
USER32.dll
GDI32.dll
WINSPOOL.DRV
ADVAPI32.dll
SHELL32.dll
COMCTL32.dll
SHLWAPI.dll
ole32.dll
OLEAUT32.dll
oledlg.dll
gdiplus.dll
OLEACC.dll
IMM32.dll
WINMM.dll
VERSION.dll
imagehlp.dll
MSIMG32.dll
Related
I am working with SDL2 and its add-on libraries SDL2_image and SDL2_ttf, using Visual Studio 2017. The libraries, and the .dll files that come with them, are in another folder (C:\SDL2.0\lib\x86), which is in the system path.
When I run, it fails, with this error message:
The procedure entry point InterlockedCompareExchange#12 could not be located in the dynamic link library C:\SDL2.0\lib\x86\SDL2.ttf.dll.
I can fix this by putting libfreetype-6.dll, which comes with SDL2_ttf, in the same folder as the .vcxproj file; or in the Debug folder. I can also fix it by putting the .dll into c:\windows\SysWOW64. But I want to distribute my code, and I don't want to put that file in each folder or require users to have admin access (to access c:\windows\SysWOW64); I want Windows to find it in the PATH, as it does with the other .dll files it's using here.
A few things I tried as I looked around the web for solution (to no effect):
Recompiling libfreetype-6.dll
Downloading the latest versions of all associated libraries
Rearranging the .lib files in Project Properties, Linker, Input, Additional Dependencies. Admittedly I may not have tried all possible arrangements as there are several dependencies
regsvr32 libfreetype-6.dll. This led to a different error message:
The module "libfreetype-6.dll" may not be compatible with the version of Windows that you're running. Check if the module is compatible with an x86 (32-bit) or x64 (64-bit) version of regsvr32.exe.
I saw here that maybe I should use the version of regsvr32 in the system32 folder; when I do that, I get
The module "libfreetype-6.dll" was loaded but the entry-point DllRegisterServer was not found. Make sure that "libfreetype-6.dll" is a valid DLL or OCX file and then try again.
So: is there a way to get the program to find libfreetype-6.dll in another folder in the PATH, and eliminate the error message about the procedure entry point?
The program I'm testing on now is from the TrueType tutorial from the LazyFoo website (source).
I am running Embarcadero RAD Studio 10.1 Berlin Update 2 on Windows 10.
My IDE environment worked fine yesterday. I compiled and build successfully using the IDE. My normal operation before running and debugging my project is to compile a couple libraries and then build my executable. Once that is done, then I'll run the executable to check out the functionality and debug etc.
This morning I compiled my libraries, as I always do, and I received the following error:
[bcc32 Error] dstring.h(17): E2209 Unable to open include file 'System.Internal.StrHlpr.hpp'
Full parser context
File.cpp(2): #include c:\program files (x86)\embarcadero\studio\18.0\include\windows\vcl\vcl.h
vcl.h(10): #include c:\program files (x86)\embarcadero\studio\18.0\include\windows\vcl\basepch0.h
basepch0.h(62): #include c:\program files (x86)\embarcadero\studio\18.0\include\windows\rtl\System.hpp
System.hpp(1599): #include c:\program files (x86)\embarcadero\studio\18.0\include\windows\rtl\sysclass.h
sysclass.h(46): #include c:\program files (x86)\embarcadero\studio\18.0\include\windows\rtl\dstring.h
I have ensured no pending changes exist in my local source and versioning.
I have tried cleaning, recompiling, and rebuilding.
My computer did run a Windows Update this morning. The following two were installed:
Cumulative Update for Windows 10 Version 1607 for x64-based Systems (KB4015438)
Update for Microsoft Outlook 2013 (KB3141495) 32-Bit Edition
I also checked out the files at the following referenced path: C:\Program Files (x86)\Embarcadero\Studio\18.0\include\windows\rtl
The file dates don't appear to suggest any changes were made recently to these files located withinn the rltl folder.
I have also tried restarting my computer.
What would cause something like this to happen and how would I go about resolving this?
System.Internal.StrHlpr.hpp is included in runtime library files when initially installing RAD Studio Berlin 10.1 Update 2.
By running the RAD Studio installer again and clicking repair installation during the process, this missing file is recovered and can again be found in the rtl folder: C:\Program Files (x86)\Embarcadero\Studio\18.0\include\windows\rtl\ allowing for successful compiling and building.
I have a baffling one: A call to GetSetting from within my VB.Net (v4.5.2) Windows Forms app results in a "Configuration System Failed to Initialize" error--but only when the .exe and the .exe.config are moved to their deployment folder in C:\Program Files (x86)\MySubfolder. As soon as I drag the same two files out to the desktop (or anywhere else) it runs without error. (And for that matter, the development copy runs as well).
What could be causing this, and what steps can I take to troubleshoot?
I'm attempting to build a project using MSBuild (v4.0) on a 64-bit machine. For some reason, MSBuild is attempting to load a 32-bit extension, and I cannot figure out why. I've reduced the problem to the smallest set in order to demonstrate the issue.
Using the following MSBuild project file:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
<Target Name="test">
<Message Text="bin path: $(MSBuildBinPath)" />
<Message Text="extensions path: $(MSBuildExtensionsPath)" />
<Message Text="extensions path (x86): $(MSBuildExtensionsPath32)" />
<Message Text="extensions path (x64): $(MSBuildExtensionsPath64)" />
</Target>
</Project>
I get this output:
Microsoft (R) Build Engine Version 4.0.30319.1
[Microsoft .NET Framework, Version 4.0.30319.1]
Copyright (C) Microsoft Corporation 2007. All rights reserved.
Build started 8/27/2010 9:56:35 AM.
Project "D:\5\test.proj" on node 1 (default targets).
test:
bin path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319
extensions path: C:\Program Files (x86)\MSBuild
extensions path (x86): C:\Program Files (x86)\MSBuild
extensions path (x64): C:\Program Files\MSBuild
Done Building Project "D:\5\test.proj" (default targets).
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:00.03
MSBuild obviously knows about the 32bit and 64bit extensions path, and from the binary path it seems clear that I'm running the 64-bit MSBuild.exe, but for some reason it believes that extensions should be loaded from Program Files (x86) instead of Program Files. This is causing me trouble, as I have an extension that I need loaded, that MUST be loaded correctly in a 32bit/64bit process, and it will not load (MSBuild is attempting to load the 32bit version in a 64bit process).
Why?
I filed a bug on Microsoft Connect, and it was closed as "By Design", with this explanation:
You're exactly right -- this has changed, and strictly speaking, it's wrong now. However, this was a conscious decision. The reason it was changed was that very many extensions (such as .targets files) installed by other products are only installed in the 32 bit program files location. They did not anticipate 64 bit scenarios, but generally would work just fine in 64 bit MSBuild. When a user runs 64 bit MSBuild, which is quite common now because it's the default for Team Build 2010, MSBuildExtensionsPath would have in the past resolved to the 64 bit Program Files as you expect. However this meant that all those .targets files were not longer found and the build failed. It was not practical to get all those products to fix their setup authoring, especially since it had already shipped to customers. So we made the change to make MSBuildExetnsionsPath always point to the 32 bit location. Almost nobody seems to really want the 64 bit location, and those people can change to MSBuildExtensionsPath64. It was really a question of the least bad option here.
I accept the evidence, but I disagree with the conclusion. I believe that authors of broken installers deserve to have their extensions not work on 64-bit machines.
If I have a Windows executable, how can I find out which dlls it will load?
I'm just talking about which ones that will be loaded statically, not ones it might load dynamically with something like LoadLibrary.
dumpbin is a tool that comes with VC++.
To see what DLLs a program will import:
Open Visual Studio
Menu Item Tools | Visual Studio Command prompt
cd to folder containing executable
dumpbin /dependents whatever.exe
Dump of file whatever.exe
File Type: EXECUTABLE IMAGE
Image has the following dependencies:
AIOUSB.DLL
sqlite3.dll
wxmsw293u_core_vc_custom.dll
wxbase293u_vc_custom.dll
KERNEL32.dll
ole32.dll
OLEAUT32.dll
MSVCP90.dll
MSVCR90.dll
To see what functions (and DLLs) it will import, use
C:\> dumpbin /imports whatever.exe
There are utilities that will do this for you.
In the past I've used the MS tool (depends.exe) that came with (I think) VB.:
VS2010
VS2012
VS2013
VS2015
Current
and there's this as well:
http://dependencywalker.com/
and probably others as well.
Open the command prompt and then type below command
tasklist /m /fi "imagename eq netbeans.exe"
Type instead netbeans.exe whatever name your exe file name.
Dependency Walker can help you determine which .dll will be loaded.
Just go to the command prompt and type tasklist /m, you will see the list of dll files used by specific program.
Solution for Microsoft .Net:
foreach (AssemblyName a in Assembly.ReflectionOnlyLoadFrom("SAMPLE.EXE").GetReferencedAssemblies())
{
MessageBox.Show(a.Name);
}
There is a handy tool called NDepend that will give you all DLL dependencies.
progfr is simple and useful:
[http://members.fortunecity.com/michaelmoser/tip11.htm]
Dependencies - An open-source modern Dependency Walker shows which DLLs a Windows executable will load and it works well in modern Windows 10.
It is a little less powerful than Dependency Walker, but the latter may or may not work in Windows 10 as it was last updated in 2006. (Newer versions of Dependency Walker were bundled with some versions of Windows Development Kit for Windows 10, but not any more.)
Process Explorer
Comes with SysInternals Suite
https://learn.microsoft.com/en-us/sysinternals/downloads/sysinternals-suite
Benefits: allows to explore the process that is already running (I have not found a was to attach the dependency walker to the existing process)