mardi 6 mars 2012 22:46
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:
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?
Toutes les réponses
mercredi 7 mars 2012 01:32I 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
mercredi 7 mars 2012 23:02I tried changing the preferred base address, but it did not change the behavior, unfortunately. Thanks for the idea though.
jeudi 8 mars 2012 17:16
jeudi 8 mars 2012 18:12I'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?
vendredi 9 mars 2012 17:07I 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
mercredi 28 mars 2012 07:37Modérateur
I marked David's reply as answer, if your issue have not been solved please unmark it and update more information about this issue.
Jesse Jiang [MSFT]
MSDN Community Support | Feedback to us