I've tried Dependency Walker, but when I run the exe in profile, Dependency Walker froze.
Process Explorer shows all DLLs loaded by application.
Loaded dll in an exe are located in the Data Directory-Import Table section.
Loading the executable in studPE and looking at the "functions" tab will give you the list of dlls.
You could also load the program in OllyDbg and press Alt+E (or menu view->executable modules) to see a list of dll's
Related
I've built a inproc com server dll which I can package as 1 file or many via the build utility py2exe. When I allow all the dependencies to remain external, I have no issues, but bundling as 1 file produces problems.
When the dll is utilized (either registering it or instantiating a com object from it), it immediately loads MSVCR90.DLL from the path c:\windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6871_none_50944e7cbcb706e5\MSVCR90.DLL no matter what I do, I can't change that. There is no information that I can find (using Dependency Walker) to indicate what is causing that to load. It just happens magically...
Then, later on it loads that dll again via an explicit call to LoadLibraryA("MSVCR90.dll") (part of some py2exe black box?), but this time it does not look into the winsxs manifests / directory. Instead it looks to the system path and/or will respect a dll redirection. That's when the problem occurs. If I set the system path to start with c:\windows\winsxs\x86_microsoft.vc90.crt...\ it will load the exact same dll and be happy - but if ANY other file is utilized - inclusive of a copy of the EXACT same dll - but at a different path - then the whole thing blows up. It can't handle using two different files.
How can I fix this? Ideally, I've love to make the initial magic loading of the dll draw upon a private assembly, but no matter what I do with manifests or .dll.local etc it will not respect that until this second dll loading takes place.
Note that with the non-bundled dll (external dependencies) it always uses the winsxs MSVCR90.DLL.
I can "fix" my failure to use the dll by forcing the system path to load the winsxs copy, but that is pretty useless for a deployable com server!
The reason is that you DLL has a manifest that tells the module loader to search also in the SxS storage.
You have several choices
Build your DLL using static linkage. Not using any of the MFC-DLLs (see project settings)
Don't use a side by side manifest for the DLL and still use the MFC DLLs. But beware you have to ship those DLL with your DLL in the local path (see DLL search sequence docs)
Use a later build of VS. Later versions of VS don't use the SxS storage any more and there are no manifests for those DLLs any more.
For the 2. see this article in code project. There is an update for VS-2008 [here].
2
Build your DLL
I have a Page class in a project A. I want to navigate to this page from my Universal windows project(say Project B) page. In UWP I am trying to achieve this using Frame.Navigate(typeof(Page_classA)), since NavigationService.Navigate(new Uri()) is obsolete in UWP.
But I get a Windows.UI.Xaml.Markup.XamlParseException in this case.
Is there any other way in UWP or metro Apps for navigating to a page in different assembly?
We can use Frame.Navigate(TypeName) method to navigate to a page in different assembly.
For example, we can create a Class Library(Universal Windows) named "ProjectA" and in this project add a new Page named "PageA". Then in this project's Properties page, check the "Generate library layout" option in the Build configuration.
In WinRT environment, the resources are no longer embedded in the assembly but are placed next to the dll as content. So we need to generate library layout so that we can reference the dll in other project conveniently.
After this, we can build the project and we will get following layout in "Debug" folder:
In ProjectA folder, it contains .xaml file and .xr.xml file:
When we get the library output files, we can copy them to anywhere and in the Universal Windows Project(Project B), we just need to add reference to the "ProjectA.dll" file. Visual Studio will automatically pick these files up and put them in the appx package when it builds the app.
And in Project B, we can use following code to navigate to PageA:
Frame.Navigate(typeof(ProjectA.PageA))
In your case, you get a Windows.UI.Xaml.Markup.XamlParseException, this may be that the .pri file is missing when you add the reference. Here is a similar case. So please check your library layout and make sure these resources are are placed next to the dll you referenced.
We are working on a validation script for Kofax Capture 9.0 / 10.0 in VB.NET 3.5.
We know how to create a script using the Admin Module, and how to get it operational.
The problem is that we need to reference a dll, located on a remote machine. (GAC is no option) This dll holds abstract classes we need in each validation script.
Even when putting the dlls locally (copy local), the Validation Module (index.exe) immediately throws the "cannot find reference" exception, even though the project compiled perfectly.
I guess the basic question comes down to: where do we put the dlls, in order for the Validation Module to find them?
The simple answer is to put the dll in the same folder as the application because this is one of the places which .NET will probe when trying to find it. The Validation module is run from the Capture bin directory which will be something like "C:\Program Files (x86)\Kofax\CaptureSS\ServLib\Bin\". This would need to be done on each client using Validation.
If you have a more complicated scenario, you could look implementing the AppDomain.AssemblyResolve Event and using Assembly.LoadFile to get the assembly from a custom location, but the using the bin path is less complicated.
If you end up having further trouble, you can troubleshoot by using the Assembly Binding Log Viewer (Fuslogvw.exe) which can tell you more details about why the assembly failed to load and where .NET tried to search for it. Assembly loading can fail for reasons other than just the path.
For more detail on how .NET loads assemblies, see the following:
How the Runtime Locates Assemblies
Locating the Assembly through Codebases or Probing
We found a solution: add all library files as "links" to the project. (Add --> Existing File --> small arrow next to "Add" --> Add as Link)
This ensures the files are compiled when you build the project. The Kofax Validation Module can now find the files, whereas when referencing the file, it could not. Why it could not, remains a mystery...
I have created a ContextMenu DLL (to dispaly icon overlay and other shell context menus) and register it in my system.
Acutally, since it is a context menu dll, I wish only explorer exe should load my dll. But in my case, applications like 'Thunderbird', 'Process Explorer', 'Visual studio', ... etc are all using my dll.
Is there any way to avoid other applications using my dll. I only want explorer exe to load my dll. Is there a way to check this in my dll ???
Thanks in Advance.
In DllMain you can test the name of exe file which loaded your dll with respoct of GetModuleFileName with NULL as the firts parameter. If a wrong exe try to load your dll the DllMain can return FALSE.
I am talking about win32 dlls, those plain pe files. I am confused after I doing a test compared to what I saw in explorer.exe process.
I wrote a test with following modules:(C++)
DLLLoader.exe links to A.dll in the same folder.
B.dll links to A.dll(2) in another folder. (A.dll(2) is a totally different DLL from A.dll, but with the same name)
DLLLoader.exe will load B.dll explicitly through ::LoadLibrary.
Now I start DllLoader.exe, firstly, A.dll will be loaded, but then when it tries to load B.dll, It just failed: I suspect that is because B.dll thinks A.dll is already loaded in process, but in fact, the loaded one is not the one B.dll wanted, the import/export table can't match, so B.dll is failed to load.
This seems to tell us we can't loaded 2 dlls of same name in the same process, even they are of different path.
But when I used process explorer to monitor loaded modules in Windows's explorer.exe process, I could see following 2 dlls being loaded, with same name:
comctl32.dll User Experience Controls Library C:\WINDOWS\WinSxS...\comctl32.dll
comctl32.dll Common Controls Library C:\WINDOWS\system32\comctl32.dll
Could any of you shed some lights on this?
It basically depens on if you load the dll with its full path or only by file name. The LoadLibraryEx docs cover this pretty well:
If lpFileName does not include a path
and there is more than one loaded
module with the same base name and
extension, the function returns a
handle to the module that was loaded
first.
See http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/b3eaa07f-7f92-4693-8aa1-b8fee0b92d2f/ for a good discussion on how this can be done implicitly for WinXP and up, by activation context (manifests) to control the loading.