none
Dependency Walker shows different modules loaded than Process Explorer

    Question

  • We have a problem migrating to Windows 7 whereby our company library sas.dll is shared, but Windows 7 has added its own sas.dll which is being chosen instead of ours (ours has nothing to do with Windows').  We have quite a few apps that use this DLL, so I don't want to copy it into each app's local installation folder - maintenance headache.  If that were the case, it'd be easier just to choose a different DLL name.  The apps using our sas.dll do not call LoadLibrary, so the .local file can't be used either.  I tried pursuing SxS by using the app.manifest file and turned our  sas.dll into an assembly with a version, and added an app manifest to the applications that use it, specifying a dependency on it.  

    Now, Dependency Walker shows MY sas.dll being loaded.  But when I actually run the app and look at it with Process Explorer, Windows' sas.dll has been loaded and the application fails because it doesn't contain my methods.  

    Has anyone seen this before or have any ideas for a resolution?  I have looked at the module load order with windbg, it shows this:

                                                                                                           C:\Windows\syswow64\kernel32.dll

    ModLoad: 00000000`75680000 00000000`756c6000   C:\Windows\syswow64\KERNELBASE.dll

    ModLoad: 00000000`71da0000 00000000`71da6000   C:\Windows\SysWOW64\SAS.dll

    ModLoad: 00000000`756d0000 00000000`7577c000   C:\Windows\syswow64\msvcrt.dll

    ModLoad: 00000000`759d0000 00000000`75ac0000   C:\Windows\syswow64\RPCRT4.dll

    ModLoad: 00000000`74620000 00000000`74680000   C:\Windows\syswow64\SspiCli.dll

    ModLoad: 00000000`74610000 00000000`7461c000   C:\Windows\syswow64\CRYPTBASE.dll

    ModLoad: 00000000`765c0000 00000000`765d9000   C:\Windows\SysWOW64\sechost.dll

    Not sure who is including SAS.dll and how come the one loaded into the activation context via manifests is not being chosen.  My only guess is some other early dependency like the ones above is loading sas.dll first.


    Am I correct in assuming that because Windows' sas.dll has no manifest, nothing can be done to redirect the loader from picking up the Windows version of sas.dll instead of our own?

    mardi 6 mars 2012 22:46

Réponses

Toutes les réponses