I am building an application using Microsoft Visual C++ 2005. After a major update of libraries, I am getting the following entry in my manifest file:
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC80.DebugCRT" version="8.0.50727.4053" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
However, when I look use the Dependency Walker on the resulting executable, I don't see MSVC80D.DLL in the list at all, which is a bit surprising to me.
I've also tried setting the linker to "verbose" mode, to see if it would tell me where the dependency indicated in the manifest is coming from. Alas, the information there doesn't shed any light on the problem.
I've also gone through all the libraries I'm linking to see if any of them use the debug CRT. As near as I can tell, none of them do.
How can I determine what library is causing this issue? When I distribute the executable as it is, I get a side-by-side error, presumably because of this entry in the auto-generated manifest.
Thanks so much for any help you can offer... After a few days of trying to figure out what's going on, I'm starting to get really frustrated with the problem.
I think I've found the solution to my problem. I decided to build a small test app, then add the libraries I'm using one at a time. Using this method, I isolated one library in particular that seemed to be causing the problem. I'm certain the library didn't show debug dependencies using dumpbin, but, on the other hand, I have been able to eliminate the unwanted manifest line by rebuilding that library.
Related
I have been trying to resolve .dll dependencies for the executable file with Dependency Walker. Currently, I am getting missing .dlls in the following form:
API-MS-WIN-XXX
EXT-MS-WIN-XXX
For example:
API-MS-WIN-APPMODEL-IDENTITY-L1-2-0.DLL
API-MS-WIN-APPMODEL-RUNTIME-INTERNAL-L1-1-0.DLL
API-MS-WIN-BASE-UTIL-L1-1-0.DLL
API-MS-WIN-CORE-APIQUERY-L1-1-0.DLL
EXT-MS-WIN-RTCORE-NTUSER-SYSCOLORS-L1-1-0.DLL
Does anybody have any ideas on how to resolve these?
Any help will be greatly appreciated!
Additional info: I compiled the executable using Visual Studio 2013. The most interesting thing is that I did not receive any errors during compilation. However, I cannot run it due to missing dependencies. I also attached a screenshot of dependency walker:
Update 1: As an attempt to solve the problem I tried to add the path for the libraries that VS used during compilation to the $PATH environment variable without any luck (Dependency Walker still shows unresolved dependencies).
These are API-sets - essentially, an extra level of call indirection introduced gradually since windows 7. Dependency walker development seemingly halted long before that, and it can't handle API sets properly.
So these are all false alarms and nothing to worry about. You're not missing anything.
Also see On API-MS-WIN-XXXXX.DLL, and Other Dependency Walker Glitches.
Edit: Only in Oct 2017 did someone finally try to fill this gap. Meet Dependencies by lucasg. I've only briefly fiddled with it until now, but it handles API sets well and is at least very worthy of attention.
In addition to what #Ofek Shilon said, I usually ignore following dlls that dependency_walker identified as missing when I try to find missing dlls for my program. You will see that your program runs fine when dependency_walker says these dlls are missing.
API-MS-WIN-*.dll
EXT-MS-WIN-*.dll
IESHIMS.dll
EMCLIENT.dll
DEVICELOCKHELPERS.dll
You can search for dlls other than the ones above to resolve your problem.
Dependencies program helped me find a missing DLL in no time. It is open source and available here: https://github.com/lucasg/Dependencies
I also ignore:
EFSCORE.DLL
WPAXHOLDER.DLL
i have written a Win32/net DLL, it works fine under Win XP, Win7 and 8 but under Win 8.1 it fails.
Dependency Walker says: API-MS-WIN-CORE-KERNEL32-PRIVATE-L1-1-1.DLL not found
(user32.dll will call them)
Google means, MS changed some System-DLLs in 8.1 (and ignored compatibility), so that many programs have the same problem.
Full list with "file not found":
API-MS-WIN-CORE-KERNEL32-PRIVATE-L1-1-1.DLL
API-MS-WIN-CORE-PRIVATEPROFILE-L1-1-1.DLL
MSVCR120.DLL
API-MS-WIN-CORE-SHUTDOWN-L1-1-1.DLL
API-MS-WIN-SERVICE-PRIVATE-L1-1-1.DLL
EXT-MS-WIN-NTUSER-UICONTEXT-EXT-L1-1-0.DLL
IESHIMS.DLL
Does someone have a idea how to fix this?
Dependency Walker's static analysis is not to be relied upon. The fact that Dependency Walker reports issues with those DLLs based on its static analysis does not mean that this is indeed your problem. It is normal for perfectly fine executables to report problems as you describe under static analysis, and yet execute perfectly well.
Right now I'm looking at Dependency Walker's assessment of my application and I see the exact same list of supposedly problematic files as you do. But the application runs perfectly well. Simply put, you are looking at a false positive.
Microsoft has certainly not ignored compatibility when upgrading operating systems. On the contrary, it goes to extraordinary lengths to maintain good compatibility.
If you want to use Dependency Walker to debug dependency problems with native DLLs, then you really need to use it in dynamic mode, using the Profile menu. This will tell you which dependency fails to load at runtime, if indeed that is your problem. But depending on exactly where the balance is between managed and unmanaged, it may be that Dependency Walker is not the right tool for the job.
And your problem may not be an issue with native dependencies. The first step is for you to diagnose exactly what the problem is. That's beyond the scope of this question because we don't have any details of the errors that you encounter.
The Crystal libraries referenced by our winform app cause errors in Code Analysis:
Warning 1 CA0060 : The indirectly-referenced assembly
'BusinessObjects.Licensing.KeycodeDecoder, Version=13.0.2000.0,
Culture=neutral, PublicKeyToken=692fbea5521e1304' could not be found.
This assembly is not required for analysis, however, analysis results
could be incomplete. This assembly was referenced by: C:\Program
Files\SAP BusinessObjects\Crystal Reports for .NET Framework
4.0\Common\SAP BusinessObjects Enterprise XI 4.0\win32_x86\dotnet\CrystalDecisions.CrystalReports.Engine.dll.
In a few different threads, SAP "support" has acknowledged that this is a problem on their end (http://scn.sap.com/thread/2153539), though they are quick to point out it doesn't impact their product directly, so fixing it is of low-priority. It's been assigned reference number ADAPT01629826, but it still seems up-in-the-air as to when they'll actually fix the issue on their end.
This is a Code Analysis Application Warning (http://msdn.microsoft.com/en-us/library/ms245349.aspx), rather than a normal Code Analysis Warning.
Because of that, Visual Studio doesn't provide the usual "Suppress Message(s)" context menu. I'm hoping there's a way to use GlobalSuppressions or something similar, but could use some help...
Even if SAP is right about the bad assembly reference not having a functional impact on their product, it still bothers me. Like the original poster, I don't want any errors/warnings from Code Analysis.
I'm sure others have run into this -- or at least something similar. How did you handle it? Is there a way to exclude this specific warning from Code Analysis, so it no longer shows?
While I don't like hard-coding exclusions, it seems like a more reliable solution than waiting around for SAP to actually push out a fix.
There is no way to suppress these without wrapping fxcpcmd or overwriting the code analysis targets to intercept the output and ignore the warning.
I need to add a dependency on a specific version of GDIPlus. This is the version of GDI+ that i want:
I want to be sure that I'm using this version for a specific compatibility reason.
I've added an assembly manifest to my executable, defining my dependancy on the version of GdiPlus:
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32" name="Microsoft.Windows.GdiPlus"
pubicKeyToken="6595b64144ccf1df"
version="5.1.3102.2180" processorArchitecture="x86"
language="*" />
</dependentAssembly>
</dependency>
Except when I run my application, Windows' fusion loader gives me some other version of gdiplus.dll from the Side-by-Side folder, which I can see in Process Explorer:
It's giving me version 5.02.6002.18005, rather than 5.1.3102.2180.
So the question is: How do I take a dependency on a specific version of a Windows dll?
Your "problem", such that it is, is that there is a policy file installed that specifies that requests for 5.1.3102.2180 can be redirected to 5.02.6002.18005
This is, usually, a good thing. it lets applications specify the version they were built against in their manifest, but when critical security fixes are introduced, the OS can redirect apps to compatible versions.
So, whats going to happen here is, your app is going to link against GDI+ 5.1 on any PC that has only 5.1 installed. but any PCs with the 5.2 GDI+, you will be redirected to that.
If you do have an honest to goodness reason why you want to use 5.1, even when 5.2 is available... I think you can use an application config file to manage that.
Create a file called, yourapp.exe.config - if the module in your app thats importing GDI+ is a dll, then it would be thedll.dll.2.config
I am unsure how to structure the bindingRedirect however. i.e. given the policy files redirection, im not sure if you need to redirect the old version back to itself, or the new version back to the old version. or what. some trial and error might be required.
The data in the .config file looks almost exactly like the data in the manifest file. Something like this (which mimics almost exactly the contents of the policy file installed in winsxs thats doing the redirection you dont want).
<configuration>
<windows>
<assemblyBinding xmlns=...>
<dependentAssembly name="GdiPlus...>
<bindingRedirect oldVersion="5.1.x.x" newVersion="5.1.x.x"/>
To make the choice of "oldVersion" easier, it supports a range syntax. so
oldVersion="5.0.0.0-5.3.0.0"
would be a simple way to ensure that a whole range of GdiPlus versions get redirected to a specific version.
Alright, after doing a ton of research and trying almost every managed CPP Redist I can find as well as trying to copy my DLLs locally to the executing directory of the app I cannot figure out what dependencies i'm missing for this mixed mode library.
Basically I have a large C# application and I'm trying to use a mixed mode library I made. On the development machine it works perfect (of course) but deployed when the library needs to be loaded for use it exceptions out because of missing CRT dependencies (I assume).
I have used dependency walker to check all the DLLs referenced and ensured they exist on the deployment machine with no luck, I'm wondering if maybe it's some dependencies that need to be registered that I am missing, but i can't figure out what.
I get the following exception when code tries to instantiate a class from the mixed mode library.
Exception Detail:
System.IO.FileLoadException: Could not
load file or assembly 'USADSI.MAPI,
Version=1.0.3174.25238,
Culture=neutral, PublicKeyToken=null'
or one of its dependencies. This
application has failed to start
because the application configuration
is incorrect. Reinstalling the
application may fix this problem.
(Exception from HRESULT: 0x800736B1)
I am compiling the library using VS2008 SP1 with /clr:oldSyntax specified.
The intermediate manifest looks like this:
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level='asInvoker' uiAccess='false' />
</requestedPrivileges>
</security>
</trustInfo>
<dependency>
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.VC90.CRT' version='9.0.21022.8' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
</dependentAssembly>
</dependency>
</assembly>
I can provide any more information as needed, unfortunately i'm not well versed in making mixed mode libraries so this has thrown me off.
If anyone can offer any advice I would greatly appreciate it!
Did you deploy the CRT libraries on the target machine? Long shot: since you have a dependency on 32-bit code, you should set Target Platform in the Build property tab to x86.
EDIT: trouble-shoot side-by-side resolving problems with the Sxstrace.exe utility, available on Vista.
Typically I've found that the pragma comment style manifest decleration's to be much more error free, from a developer maintenence and an over all build action perspective. The XML manifest's are natoriously snafu.
The fimiluarity with how the linker operates and the usual compilation of C code and the fact that you simply tak this in, onto one of your source files, keeps everything a bit feeling more "together";
#pragma comment(linker, \
"\"/manifestdependency:type='Win32' "\
"name='Microsoft.Windows.Common-Controls' "\
"version='6.0.0.0' "\
"processorArchitecture='*' "\
"publicKeyToken='6595b64144ccf1df' "\
"language='*'\"")
I had a similar problem the first time I deployed a VS 2005 app on a target machine -- had to bring over the MSVCRT80 DLL. Are you saying you already have the 2008 VS runtime library there?
ETA: Also, dumb question, but are you sure you have both the CRT Runtime (linked to above) and the .NET Runtime, with the same version you compiled against (probably 3.5)? You probably already know this (especially considering your score) but they're 2 different things.
I found a solution that seems to work although I don't like it very much.
I had to copy the folders:
Microsoft.VC90.CRT & Microsoft.VC90.MFC
From: Program Files\Microsoft Visual Studio 9.0\VC\redist\x86
Into the deployed application directory, I just can't figure out why this seems to work and the redistributables did nothing.
EDIT: Looking at the manifest I probably don't need to copy the MFC directory
Best way to solve this problem is to download process monitor which is free from:
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
Add a filter to watch only your process and it will show you all file access the process tries. This will show you exactly which dll it can't find.
I always use this when faced with the same problem - if only microsoft filled in the filename in the thrown exception it would all be easier.