On 4/21/2015 9:22 PM, Benjamin Kaduk wrote: > Interestingly, google results for the > API-MS-WIN-APPMODEL-RUNTIME-L1-1-0.DLL search brings up a stackoverflow > page claiming that the tool is a bit out of date and reports false > positives for these libraries > (http://stackoverflow.com/questions/17023419/win-7-64-bit-dll-problems) :(
Don't believe everything you read on stackoverflow :-) Depends.exe does not load libraries using the same search paths that would be used by an application. Application search paths can be altered due to manifests, LoadLibraryEx() options, etc. It is therefore possible for gssapi32.dll to load perfectly fine for one process and not for another. It is also quite possible that the KFW DLLs do not have the proper manifests to ensure that the dependencies are found. One approach you can use to identify which DLL is not being located and how it is being search for is to use SysInternals Process Monitor. Set the filter to be the name of the process that is going to fail to load gssapi32.dll. After the failure occurs search from the end of the trace to find the last DLL before the process exits that cannot be found. If you install Debugging Tools for Windows and configure Process Monitor to use it, Process Monitor will capture stack traces for each event and you can use that to identify whether the failure is due to the linker or a LoadLibrary API call. Process Monitor will also show which DLL is being loaded. Since KFW is not built as an assembly there is no guarantee that the correct DLLs are being loaded. It is possible that non-KFW DLLs with the same file names are interfering. There are commercial applications that ship forked copies of KFW DLLs. The ones that come to mind are SSH, FTP and Calendar applications. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos