How do I find out which dlls an executable will load? - dll

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)

Related

VB.net .exe cannot be run from another computer. Missing assemblies for ClosedXML

I must put this program into production today, and I can't get it to run independently.
In the program, I have included NuGet package "Imports ClosedXML.Excel" and use it to create spreadsheets. When I build my executable, and try to run it from another computer, it cannot find the ClosedXML and Documentformat.OpenXml assemblies.
I checked in References that "Copy Local" was = True for ClosedXML and Documentformat.OpenXml, but it's not working. I found another website that mentioned Global Assembly Cache, and that if the dependency is in there, it will not be included in the Build .exe.
I am running Visual Studio Professional 2017. I am in over my head on this one, so if you have answer (and I hope you do), please try to provide it in elementary terms I can understand.
Sometimes issue is solved by individually adding application files inside the following menu
Go to Publish-->Application Files
Select Show all files
Under Publish Status
Set the files you need to Include [not include(auto)]

How to use ZeroBrane Studio IDE debugger when lua is compiled as c++

I have compiled Lua 5.3 as a 32 bit c++ DLL and exe. The DLL contains all the lua code except for lua.cpp and luac.cpp. The exe compiles lua.cpp and uses the DLL to run the lua interpreter. This works fine when running on its own from the command line. I wish to be able to run from the IDE using this DLL and exe.
If I replace /ZeroBraneStudio/bin/lua53.dll and lua53.exe with my own versions, I can run scripts (clicking the two green arrows). However, debugging does not work, giving the following error:
The procedure entry point luaL_addlstring could not be located in the dynamic link library lua53.dll.
I can see that this is happening because the debugger is making use of luasocket. \ZeroBraneStudio\bin\clibs53\socket\core.dll is dependent on lua53.dll, and is expecting it to contain lua compiled as c.
So, what is the correct solution to this - is it to compile luasocket as c++ as well?
(And, if so, does anybody have instructions/guidance for doing so? I have been unable to find anything on this.)
Thanks.
I'm not sure how exactly the DLL was compiled, but the error message likely indicates that the luaL_addlstring and other functions are not exported by it. If the symbols are exported correctly, you should be able to load luasocket and get the debugging working. See this thread for the related discussion.
Also, you don't need to replace lua53 library and executable, as you can configure the IDE to use your own copy of it using path.lua53 configuration setting as described in the documentation.
Okay, I was able to get it working. The solution was to compile luasocket as c++. I won't give full instructions on how to do this here, but some points to hopefully help anybody else with the same issue:
Got luasocket from here: https://github.com/diegonehab/luasocket
Renamed all *.c files to *.cpp
Renamed Lua52.props to Lua.props (I am using lua 5.3 but seems like it is compatible?)
Placed lua headers and lib in appropriate folders
Opened solution in Visual Studio 2012
Fixed up minor issues with project files, like the renaming of the files.
Added 'extern "C"' to declaration of luaopen_socket_core and luaopen_mime_core functions (necessary for lua to be able to load libraries).
Built solution
Copied new dlls into clibs53/socket and clibs53/mime folders.
I used Dependency Walker to help with this. If anybody wants further details in the future please leave a comment.

Changing the version information of ironpython .dll assembly

I compiled a .dll file in ironpython, by using the following code:
import clr
clr.CompileModules('C:/example.dll', 'C:/example.py')
It essentially compiles the .py file to .dll.
The only problem with this is that it creates a file with no information about the Company, Language, File Version etc. In fact the File Version is always: 0.0.0.0.
I was wondering if there is a way to at least alter the File Version (change it to something other than 0.0.0.0). I googled and found a similar topic in here on stackoverflow.
I tried three methods:
1) One with Visual Studio (File->Open-> find .dll, Edit->Add Resource->Version click New. In the new Version tab, change FILEVERSION and PRODUCTVERSION)
2) Another one by using the Change version 2012 application
3) And third one by using: Simple Version Resource Tool for Windows 1.0.10
None of them worked.
For some reason looks like the structure of the .dll assembly created with ironpython is different than the .NET one created with VB or C#.
Does anyone know how to change the File Version from 0.0.0.0 to something else?
Thank you.
You can use the pyc.py file packaged into IronPython to compile your file into a .dll file. The file is located in the directory IronPython 2.7\Tools\Scripts.
If we open pyc.py for editing, you'll see the different things it can do.
pyc: The Command-Line Python Compiler
Usage: ipy.exe pyc.py [options] file [file ...]
Options:
/out:output_file Output file name (default is main_file.<extenstion>)
/target:dll Compile only into dll. Default
/target:exe Generate console executable stub for startup in addition to dll.
/target:winexe Generate windows executable stub for startup in addition to dll.
#<file> Specifies a response file to be parsed for input files and command line options (one per line)
/file_version:<version> Set the file/assembly version
/? /h This message
EXE/WinEXE specific options:
/main:main_file.py Main file of the project (module to be executed first)
/platform:x86 Compile for x86 only
/platform:x64 Compile for x64 only
/embed Embeds the generated DLL as a resource into the executable which is loaded at runtime
/standalone Embeds the IronPython assemblies into the stub executable.
/mta Set MTAThreadAttribute on Main instead of STAThreadAttribute, only valid for /target:winexe
/file_info_product:<name> Set product name in executable meta information
/file_info_product_version:<version> Set product version in executable meta information
/file_info_company:<name> Set company name in executable meta information
/file_info_copyright:<info> Set copyright information in executable meta information
/file_info_trademark:<info> Set trademark information in executable meta information
Example:
ipy.exe pyc.py /main:Program.py Form.py /target:winexe
One thing that I personally like to do is move pyc.py from the Scripts folder to the IronPython folder along with my python file as well.
Assuming you also do this, you would open command prompt as administrator and navigate to the IronPython folder.
cd "Program Files (x86)\IronPython 2.7"
Then you would want to compile your python file as a .dll and set the file version using pyc.py. To do that, you're going to want to type in:
ipy.exe pyc.py /main:example.py /target:dll /file_version:0.0.0.1
If you want to add a company name, and other items as well, you simply have to pass those option to the pyc.py script.
ipy.exe pyc.py /main:Program.py Form.py /target:winexe /file_info_company:Company

Racket error Failure: can not load the DLL

I send a Racket executable(in a distribution package) to a few friends and they get the error:"Failure: can not load the DLL". On my computer it runs without problems. It's using the rsound package.
Yes, good point. Currently, rsound is hard-coded to look in the collection path for the DLL. That won't work for programs compiled into executables. I've just updated rsound to tell it to look in "standard locations" as well for Windows and Mac.
Try this: Using the DrRacket package manager, update your copy of portaudio. When you're done, it should be at version "b9403a6dfbfb5eadf824ed91731ec141bf363677".
After this, it should be possible to pass along the executable file and run it, as long as the two required dll's are in the same directory as the executable. These two dll's are:
portaudio.dll
callbacks.dll
For windows, you'll find both of these in a subdirectory of the portaudio package. Finding these is going to be a teensy bit of a hassle on Windows; I believe these get installed in your user directory\RoamingData\\portaudio\lib\win32\x86_84\3m\ . If the target computer is a 32-bit machine, you'd substitute 'i386' for 'x86_64' in that path.
I know that Windows can make it quite hard to find the files you're looking for; let me know if you have any trouble.
Whew!

How to find out which DLLs another EXE/DLL depend on via dynamic runtime loading?

I've tried Dependency Walker, but when I run the exe in profile, Dependency Walker froze.
Process Explorer shows all DLLs loaded by application.
Loaded dll in an exe are located in the Data Directory-Import Table section.
Loading the executable in studPE and looking at the "functions" tab will give you the list of dlls.
You could also load the program in OllyDbg and press Alt+E (or menu view->executable modules) to see a list of dll's