I use Dependency Walker to open wintrust.dll on my Windows 10 and it takes around 40 seconds! When it is opened, I see very strange picture of recurring calls between KERNEL32.DLL and API-MS-WIN-CORE-PROCESSTHREADS-L1-1-1.DLL:
I suppose this is the source of the problem. When I try to open my own dll, that includes wintrust.dll on separate paths, it might take up to 10 minutes (!) to open.
Why is this happening?
Dependency Walker for Win64, v2.2.6
Windows 10 x64 Version 1709 (OS Build 16299.248)
wintrust.dll File version 10.0.16299.248
kernel32.dll File version 10.0.16299.15
api-ms-win-core-processthreads-l1-1-1.dll File version 10.0.10586.9
Don't use dependency walker. Here's one good alternative I'm aware of: Dependencies by Lucasg. Unlike dependency walker - it is aware of ApiSets and thus will not recurse indefinitely.
Related
I have built Game Music Emu from source to use with Love2d. (Note: I am not very familiar with C/C++.)
In lua I load the dll with FFI and on my computer it works great, but when I sent my friend the app for testing, his machine doesn't recognize the DLL.
I sent him the love2d binaries with the libgme DLL included to make sure he didn't just misplace the DLL file. So what he is running is the exact same thing I am running.
My code looks like this:
ffi.cdef[[ ... ]]
local gme = ffi.load("libgme")
This is the exact error my friend gets:
lovegme.lua:4: cannot load module 'libgme.dll': The specified module could not be found.
Depending on how libgme is compiled you may have some dependencies that are satisfied on your computer (for example, mingw libraries), but not satisfied on the other computer.
I'd try several things: (1) use the full filename in the load command, (2) use "profile" mode in dependency walker to check what is failing during DLL load, or (3) use the same dependency walker on your machine to see what other DLLs libgme may depend upon and include those in your package/installation as well.
I have 1 dll file which I try to load during the installation with UseDLL() in one of my installscripts.
this dll has 2 dlls it depends on. they both located on the same directory of the main dll.
When in build the installation with an older installshield - it find it's dependencies and works fine.
When I try to build it with IS2016, it fails because it doesn't find it's dependencies. (If I put these 2 dlls in SysWOW64 - it finds them and works fine).
What is the problem?
Thanks,
Dudi
It looks like InstallShield 2018 makes this easier through a new Enable/Disable flag called DLL_DIRECTORY_SUPPORTDIR. But in InstallShield 2016 there's a good chance you can add the following InstallScript code to find dependencies in SUPPORTDIR. If your DLLs are in a different directory, substitute that instead.
// Add prototype for SetDllDirectory(); this typically goes near the top of your script
prototype number kernel32.SetDllDirectoryW(wstring);
// Call it; this goes in a function called before your UseDLL call
SetDllDirectoryW(SUPPORTDIR);
Note that doing this removes some protection against DLL planting, so it is safest to do this only if you ensure the DLLs in question are either proactively resistant to such things, or if you vet and secure the directory in question. (I'm uncertain whether InstallShield does this for you.)
I'm trying to optimize the file size of my game, in particular the android build. I have optimized the assets and set the build stripping level to Use micro mscorlib. However, looking at the Editor.log reveals the DLLs still take up more than 50%:
Textures 2.7 mb 35.7%
Meshes 80.5 kb 1.0%
Animations 0.0 kb 0.0%
Sounds 0.8 kb 0.0%
Shaders 98.2 kb 1.3%
Other Assets 177.9 kb 2.3%
Levels 110.0 kb 1.4%
Scripts 447.4 kb 5.8%
Included DLLs 3.9 mb 52.2%
File headers 26.2 kb 0.3%
Complete size 7.5 mb 100.0%
3.9mb seemed a bit much, so I looked at which DLLs are actually added. I found this:
Mono dependencies included in the build
Dependency assembly - Mono.Security.dll
Dependency assembly - System.Core.dll
Dependency assembly - System.dll
Dependency assembly - mscorlib.dll
Dependency assembly - UnityEngine.UI.dll
Dependency assembly - UnityEngine.Networking.dll
Dependency assembly - UnityEngine.Analytics.dll
Dependency assembly - Assembly-CSharp.dll
Dependency assembly - Assembly-UnityScript-firstpass.dll
Dependency assembly - Assembly-UnityScript.dll
This looks like it can be improved quite a bit. I don't use UnitScript, so Assembly-UnityScript-firstpass.dll and Assembly-UnityScript.dll should be obsolete. Neither do I use Networking or Analytics, so these could be removed as well. Not sure what Mono.Security.dll does or whether UnityEngine.UI.dll is really necessarry.
So, knowing this, how can I get rid of these seemingly unnecessary DLLs?
There is another way of doing this:
Step 1: Right-click on the .apk file and Open it with WinRAR/ZIP
Step 2: Enter the assets folder, then enter bin\Data\Managed
Step 3: There you will find all the DLLs, just remove what you want (not that much :D)
Seems like there is not a direct way to do that. I just tried removing some dlls references on a test project and wasn't enough. Unity was including some of the removed libraries in the build anyway.
But, what if we make impossible to unity to find those elements? That approach worked.
Steps:
Remove references in Assembly-CSharp and Assembly-CSharp-firstpass
Follow the path and rename those removed dlls to something else, like filename.dd_old:
3.- Compile, Build, and see the results :)
Before:
Mono dependencies included in the build
Dependency assembly .....
Dependency assembly - UnityEngine.UI.dll
Dependency assembly - UnityEngine.Networking.dll
Dependency assembly - UnityEngine.SpatialTracking.dll
Dependency assembly .....
After:
Mono dependencies included in the build
Dependency assembly .....
Dependency assembly - UnityEngine.UI.dll
Dependency assembly - UnityEngine.SpatialTracking.dll
Dependency assembly .....
Test your game, I really don't know what can be wrong with this practice, and I mean, I really don't know what cannot go wrong with this practice :D
Rename the _old files to their original names for the next project, etc..
The Unity provides a feature to strip unused code, and therefore the dll, for you.
Follow the steps below:
Select the menu Edit->Project Settings.
In the Project Settings dialog box, select Player.
In the Player select Other Settings.
Scroll down until the Optimization section.
Change the option Managed Striping Level in the dropdown list.
This feature has many options and you can even link the specific assemblies using a link.xml file in the Assets folder.
I strongly suggest to read the Unity official documentation Managed Code Stripping for further information.
That's it. Hope it helps.
I had an app A for which I created an installer A1. This has been in use for many months.
We now realized that AI used to package some files - d1,d2,d3 which are not needed.
Therefore we removed them from our project and created an installer A2 which does not package the above mentioned unwanted files. (atleast thats what we expect)
Things are ok when I use this installer the usual way...but when I use this for a silent install, I get the following error:
Error 1334. The file d1 cannot be installed because the file cannot be found in cabinet file 'myMedia1.cab'. This could indicate a network error, an error reading from the CD-ROM, or a problem with this package.
I googled this and saw that people usually encounter this whn u release a patch or some installer release where some files are removed or moved around.
Apparently, msiexec tries to reference some cached version of these variables and since it still looks for the missing files in the new installer, install fails.
Is there a way to tackle this? - like some way to have msiexec use just the .msi file I provide in the input rather some cached version.
Thanks...
It sounds like you could receive this error if you haven't updated the PackageCode, ProductCode, or UpgradeCode for your A2 installer. If A1 is installed, and then A2 runs with the same PackageCode, ProductCode, and UpgradeCode the system thinks you are running the A1 installer again and will look for the cached A1 msi under C:\windows\installer.
For anyone else like me that is experiencing the same problem (Error 1334) when building a Setup project and didn't find any explanations or solutions, here's a thread that solved my problem:
https://www.itninja.com/question/1334-error-tried-just-about-everything-i-can-think-of-anyone-know-of-some-obscure-causes
Basically, the solution to the problem is to “touch” all the files referenced in the Setup project (that is, all the dependencies - DLLs and all else). You can find the list and path of all the files in the build output, on lines like these:
2> Copying file from "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\System.Threading.dll" to "C:\Path\To\Your\Project\bin\Debug\System.Threading.dll".
To “touch” the files, you may use this technique or you may use some third-party file manager like Total Commander. You'll just need to run as administrator / accept UAC warning, because some files are in system folders.
EDIT: in my case, the problem with the Setup project began after updating some NuGet packages used by the main project.
P.S.: although I'm not using WiX, but Microsoft Visual Studio Installer Projects, the symptom was the same, so I hope this answer will be helpful for someone.
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)