I had a problem installing my project on vista and 7 which I mentioned before here.
How to cope with Install error 1920 about winsxs merge modules in Vista and 7?
I see that post for a problem may be similar of mine, and there is a solutuion author tried.
comctl32.msm (Merge module) Fails on Vista
I want to replace my .dll files to winsxs folder in vista or 7 can I do that? If I can how?
Regards,
togikan
Related
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
I've had the pleasure of not having to work with InstallShield very much, so I appreciate the answer to this is will be extremely simple, or more than likely, there is not much I can do about it (unless I compile my own MSM package?), but with the MSM Merge Modules, I have selected to use Visual C++ 9.0 MFC (x86) WinSXS MSM, version only states as 9.0, but getting a "SideBySide" error to say the version for 9.0.21022.8 is not found when the end user is trying to run the product.
With having 4 different flavours of version 9 in my C:\Windows\winsxs folder, I presume its not using the desired one of the version above, but there is no way to validate this in the properties of what is selected in InstallShield.
How can I either specify the selected MSM module is to use the set version of the files that is within the 9.0.21022.8 folder, or where can I find a MSM I can download to install over the top in InstallShield?
Thanks.
I suppose those 4 merge modules would be :
ATL,
CRT,
MFC,
MFCLOC,
OpenMP.
May be the sxs error can be corrected if you install the x86 merge mods for a 32 bit installation
and install both x86 and x64 merge mods for a 64 bit installation.
I'm using Visual Studio 2010 to build a MSI consisting of several DLL files set to register using vsdrpCOMSelfReg. There are also several Windows services that are installed using custom actions. My target machine is running Windows 32bit embedded standard.
My previous development box ran Windows 7 64 bit and I could build and install this MSI with no problem. I recently changed over to Windows 8 Pro, and when I build the MSI using the exact same code base I get "failed to register" errors on my DLLs, which then causes the services to fail installing.
I have a "Privileged" launch condition in the MSI that passes for both versions, so it looks like the required permissions are there.
If I set the DLL files to "vsdrpCOM" I can successfully register after the fact using regsvr32, but my services can't install because they rely on those DLLs being registered to complete their own installation.
What am I missing? What changed with DLL registry beween Windows 7 and Windows 8?
The usual cause for this is missing dependencies. ComSelfReg requires your Dlls to load and run during the install. If you have included the VC++ runtime support as merge modules and they install in WinSxS then they are not available until after your selfreg code needs to run. The symptoms are exactly those you'd get when the VC++ runtime is being installed from merge modules and do not already exist on the system - failure during the install and success with regsvr32 after the install.
In general you should look at using a tool that doesn't require code to install services. All the major install tools populate the ServiceInstall and ServiceControl tables in the MSI file because MSI will install services just fine, but VS setups don't use them for some reason.
The problem was in the dependencies automatically pulled in when I added the DLL Project Outputs. One of the detected dependencies was IPHLPAPI.DLL, pulled from C:\Windows\System32. This DLL was then copied into the application directory. In my install of Windows 8 Pro, IPHLPAPI.DLL is version 6.2.9200.16420. In Windows 7, this file is version 6.1.7600.16385.
I'm guessing my assemblies were referencing the Windows 8 version since that was in the local directory, and this caused registration and/or runtime errors. I excluded IPHLPAPI.DLL from the installer and everything is now running correctly, referencing the file in System32.
What is the issue?
I am trying to install FxCop 10. To install that, Microsoft Windows SDK 7.1 is required. I installed the SDK. Now, to install FxCop, I have to run FxCopSetup.exe, which is supposed to be located in the folder %ProgramFiles%\Microsoft SDKs\Windows\v7.1\Bin\FxCop. But, that folder is missing.
What I did to try to fix it?
I searched the web to fix the issue, and I tried a couple of workarounds that were suggested in a few discussions including (1) not doing a full installation of the SDK and (2) uninstall SDK, reboot, re-install SDK and reboot.
Any help is greatly appreciated. Thanks!
Btw, I'm running Windows 7 (if that's relevant).
In my SDK install, there is an FXCop folder: C:\Program Files\Microsoft SDKs\Windows\v7.0A\FXCop. Is there an FxCop folder somewhere in you SDK install? Apparently it's been moved...
Alternately, I have the FxCop installer on my Dropbox: http://dl.dropbox.com/u/1311259/FxCopSetup-10.0.exe
It's in Program Files, not Program Files(x86). I realized this when running a repair on the windows sdk when I couldn't find the folder, and seeing where it was copying files.
It worked for me when I only selected the "Tools" option to install.
I have created an WIX installation package and when installed on WinXP an Error 2259 always appears.
How do I go about resolving this issue and how come it works on machines running WinVista and Win7?
Seems that my modification to the Visual C++ 8.0 CRT merge module wasn't liked. Basically what I did was edit the customaction names so that they are unique to prevent compile warnings.
This doesnt seem to be liked in WinXP