I have a problem with my.xll addin when it loads on my clients PC.
It crashes Excel at startup (possible because of missing dependent dlls).
I know it is possible to use dependency walker in profile mode to find out what dlls are loaded when the .exe runs.
When I try that dependency walker hangs when profiling Excel, and I can’t find out why.
In a command window I ran this:
C:\Program Files (x86)\Windows Kits\8.1\Tools\x86>start /wait depends.exe /c /f:1 /pb /pp:1 /pg:1 /oc:d:\temp\Log.txt "C:\Program Files (x86)\Microsoft Office\Office14\excel.exe"
But it hangs.
I am using dependency walker version 2.2.9600 x86, Windows 8.1 x86, office 2010 x86
I also tried to setup a VM machine with a clean install of win 8.1 and Office 2010 but XL does not crash on that machine when I load the .xll.
I works on another machine Windows 10 x64, office 2013 x64 and dependency walker x64. I can profile Excel.
Note: I ended up using Sysinternals Process Explorer instead. A bit more complicated but works.
I'm currently on Windows 10 build 1809, and depends.exe hangs for every dll I try it with. The depends home page says "Dependency Walker runs on Windows 95, 98, Me, NT, 2000, XP, 2003, Vista, 7, and 8" so I guess it's not supported.
Try Dependencies - An open-source modern Dependency Walker, it works fine for me.
Reconfigure module search order. Try to disable all except KnownDLLs and application directory and then open file to check.
Dependency walker builds very large list of subdependencies and GUI elements hangs on this operation :(
Microsoft has very slowly been adding modularization, versioning, and indirection to Windows OS API libraries.1 This effort started in Windows 7, but only in recent builds of Windows 10 has this initiative hit some of the core win32/kernel libraries that essentially all traditional Windows binaries link to and use.
Naïve dependency walkers will create a graph combinatorial explosion for themselves they try render the complete dependency graph without some extra logic to short-circuit this layer of indirection, or limit the depth of the graph search to be on-demand at a certain depth. If your program is relatively simple, depends.exe will eventually wake up and render the dependency graph for you, but it may take a few hours.
I don't know if the author of depends.exe intends to ever update it, but in the meantime, as Andrew pointed out in his answer, the lucasg/Dependencies project on GitHub seems to not suffer from the same problem.
Also see this SO post: Dependency Walker: missing dlls
Related
I have an old legacy VB6 application that uses the free ChilkatXML ActiveX DLL extensively. I recently installed this application on a customer's PC – running 64 Bit Win7 (which it usually runs okay on) – and the XML document saving functions are failing. At first it was even failing to open existing documents, but I ran the full Chilkat installer – as it's a free component – and that part at least appears to be fixed.
The customer admitted the PC previously had a virus on it, so I'm thinking there may be some residual OS damage the clean up operation has missed. I've opened the DLL in Dependency Walker, which reported an error with the SYSNTFY.DLL module not being found – although I've checked and that DLL does exist in their System32 folder. I've tried copying the 32Bit version of that dll from my system into their sysWOW64 folder but that didn't work either – not that I realistically expected it to.
So, any ideas on what I need to do to fix this problem please?
I developped a vb6 program then I build an installation wizard with visual studio interdev.
I used "dependency walker" and "process explorer" to find out the missing DLLs but there is always a problem with :
IESHIMS.DLL
WER.DLL
MPR.DLL
These dlls shown by dependency walker.
And when installing the program on another machine I have these error messages :
uxtheme.dll failed to register
msdatsrc.tlb failed to register etc..
PS : no problem on a machine where visual studio is installed.
Any Idea to fix this issue?
Thanks
Dependency Walker is not an appropriate tool to troubleshoot VB6 dependencies. It works well enough for DLLs written in C or C++ that use implicit dependencies. Although it hasn't kept up with the times and has trouble with DLLs that are stored in the Windows side-by-side cache or are delay loaded. Delay loading is what generates the warnings on ieshims.dll et al.
VB6 uses COM, which loads DLLs dynamically with LoadLibrary(). You'll never see such a dependency back in Depends unless you use the Profile option. Such DLLs are found back through the registry, the reason you needed to write an installer and tinker with regsvr32.exe.
You have to be pretty careful when writing installers like that, VB6 is old and can depend on operating system components that have been updated many times since 1998. Like uxtheme.dll, an important operating system DLL that implements visual styles. Having your installer overwrite the existing one on the user's machine is, well, disastrous. Although it is probably protected by Windows through its File System Protection feature, something that got added as a counter-measure against broken installers.
Giving proper advice is here difficult beyond "do no harm". A commercial installer like InstallShield or Wise (which I liked back then) is the best way to avoid shooting off the customer's leg. Fairly sure they still support VB6 installs. Microsoft makes a pre-cooked installer available for VB6 that installs all the core vb6 runtime components. You can download it here.
You should ALWAYS double check and verify any dependancies that you think your application needs.
All the files you mentioned are system DLLs and MUST NOT be distributed.
For a VB6 application you need the basic runtimes, and any DLLs you explicitly reference/use if and only if you have permission from the authors of those DLLs and instructions on the correct procedure and location for installing them.
For the standard Microsoft provided OCX files, these normally just need to be copied to the system32 folder and registered.
See redist.txt in the root of your Visual Studio installation for more details.
So we've got this 32-bit software package that is installed on both Win XP and Win 7 machines.
The current issue that I'm looking at is that when installing part of the package, registry values are written to add an executable in the package to the windows context menu. These registry values are part of a wix fragment that is generated by heat from a dll that is part of the process (ie. a dll of the executable).
The problem is that while it works on windows xp embedded, on windows 7, not only does the application NOT show up in the context menu, it also breaks something so that the "New Folder" option is removed from all context menus. Uninstalling the application doesn't work, but it can be fixed by adding the registry settings from this site: http://social.technet.microsoft.com/Forums/en-IE/w7itprogeneral/thread/97de8a2a-12f2-4381-a409-a78f4ae551cf
Of course when you install a new build, then it gets wiped away again, and as developers, sometimes we're installing and uninstalling 5-6 builds a day. I've confirmed that it is those particular registry settings by removing them from the installer and building and installing it, and the "New Folder" option happily stays where it is.
So my question is: is there a problem with heat generating valid registry values to write for a 32-bit application/dll to be added to the context menu on windows 7? (for complete disclosure, I'm using win7 64-bit, but we've had the same issue on win7 32-bit, but we haven't tried vista)
Heat simply captures the registry keys written during the DllRegisterServer() call. If you are not getting the registry keys you expect, then look at the DllRegisterServer() code to see what it is doing. Also, you may find it more useful to capture the registry keys once, verify they are correct then not use heat.exe any longer.
That's my preferred approach.
I'm getting an 'AccessViolationException' 'Attempted to read or write protected memory' when calling a method in an x86 dll when running on an x64 platform (Windows 7). Everything works great on x86 platforms.
I've read many, many posts about similar problems but haven't been able to get my code to work.
I'm in the process of trying to make our old x86 app work happily on Windows 7 (x64) and Server 2008 R2 (x64). The app is an assortment of VB6 , VB.Net, C#, MicroFocus COBOL and C++. (We couldn't think of any other languages to throw in at the time). The DotNet code was originally written in Visual Studio 2003 for DotNet 1.1. I've ported the code up to Visual Studio 2010 and DotNet 4.0. I've set the target for all the projects to x86. When I call into un-managed 32 bit dll's I get the above error.
Our InstallShield setup routine is installing the x86 dll's into C:\Windows\sysWOW64 instead of C:\Windows\System32. This behavior seems correct. The dll's are some COBOL object code and runtime components linked together into a 'C Style' dll. I don't think the problem has to do with COBOL or the linking process as I also ported up a sample app from Code Project with a VB.Net WinForms app that calls a simple C++ dll, all targeted to x86. I get the same error there. I've also tried building a C++ command line app to call the dll. The Load Library succeeds. GetProcAddress succeeds. Calling the function pointer for the particular method fails. Our VB6 apps can call the dll's just fine when running on Windows 7 x64. I've also tried turning off UAC and setting the requestedExecutionLevel in the manifest to the highestAvailable. I've tried running as administrator.
Seems like this should work, but not sure what to try next. Any ideas?
On x64 .net programs will be run as 64-bit programs and cannot call 32bit-dlls.
Try compiling the application with target x86 instead of "Any Target". You can also force the
target of the built .exe with the .Net CorFlags.exe utility to run in 32bit-mode.
Of course your program will then run in the 32bit environment, especially it will only have a maximum of 2gb of RAM.
Good news,
We investigated DEP as a possible cause of the problem as we saw that even our VB6 code will fail when DEP is turned on. We noticed that the VB.Net code was failing in the same way as VB6 when DEP was on. Apparently our COBOL dll's do something that DEP isn't happy with. Unfortunately the DotNet assemblies don't seem to respect the operating system DEP setting, so you have to turn off DEP with using editbin.exe:
editbin.exe /nxnocompat:no
I still have to test it on our full application, but it looks like we have a solution!
I'm building an ActiveX control installer in VS2008 which uses both the CRT and MFC merge modules to install. When my control tries to register on Windows 7 it fails.
Dependency Walker says I'm missing the mfc90u.dll, msvcr90.dll and msvcp90.dll dependencies when trying to register my control and the install fails. Are the merge modules supposed to take care of this? My output OCX is being registered with the vsdrpCOMSelfReg option. From what I am reading on other forums, this might not be the best method, what should I try at this point?
Install works fine on Windows XP.
Update 4/8/2010:
Changed to vsdrpCOM and the install gets through (no surprise), however, msvcr90.dll isn't being found afterwards. I thought this was handled by the merge module for CRT (microsoft_vc90_crt_x86.msm)? On Windows XP, Dependency Walker finds it in Windows/System32, not in the SxS folder like I expected. On Windows 7 it just doesn't find it at all. Should I be putting the msvcr90.dll into Windows/System32 myself? It doesn't seem like it.
Update 4/20/2010:
Well it seems as though Dependency Walker finds msvcr90.dll at the top level dependency of the control itself, although msvcp90.dll and mfc90u.dll both have implicit/forwarded dependencies on msvcr90.dll as well and those couldn't be resolved in the Dependency Walker. The control, however, registers fine and runs loading those libraries. Is this something that can be ignored?
The two modules you need are:
- Microsoft_VC90_MFC_x86.msm
- Microsoft_VC90_CRT_x86.msm
For a 64-bit app you should be using
- Microsoft_VC90_MFC_x86_64.msm
- Microsoft_VC90_CRT_x86_64.msm
Unfortunately self-registration causes a lot of problems, what you should do is add the required registry entries manually into the setup project. (The 'heat' tool from WiX provides a really easy way to capture this information, although if you wrote the DLL you should know the required entries already). The real problem with self-registration is that if it fails, then the setup dies. The most obvious problem is that if your DLL requires additional modules to successfully complete self-registration and they're being installed at the same time you can't guarantee that the system will find them present for self-registration to complete.