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?

Answer 1

I have never had to deal with such a thing, but I think I heard sometime that you can re-base your DLL to avoid the conflict.  Try changing the base DLL load address.

---

Jose R. MCP

Answer 2

I tried changing the preferred base address, but it did not change the behavior, unfortunately.  Thanks for the idea though.

Answer 3

Try using SxSTrace.exe, included in Vista and later.  It does a better job than Depends.

 

-- David

---

Efficiently read and post to forums with newsreaders: http://communitybridge.codeplex.com

Answer 4

I've used SxStrace, and it shows the manifest being processed and my DLL being located without error.  However, even though the my DLL is found, Windows's copy is still loaded instead of mine.  WinDbg shows it being loaded right after kernel32, so I suspect that is getting loaded before the manifests are processed?

Answer 5

I posted your problem to an MVP private list.  Someone was kind enough to write back:  

 

    Maybe an ACT Shim can provide a Quick (and dirty) solution for him.

   http://blogs.msdn.com/b/cjacks/archive/2007/10/15/using-the-correc tfilepaths-shim-to-redirect-files-on-windows-vista.aspx

 

-- David

---

Efficiently read and post to forums with newsreaders: http://communitybridge.codeplex.com

Answer 6

Hello,

I marked David's reply as answer, if your issue have not been solved please unmark it and update more information about this issue.

Best regards,
Jesse

---

Jesse Jiang [MSFT]
MSDN Community Support | Feedback to us