I have tried to inject the DLL into another process by using EasyHook, but when the host process is shut down, the EasyHook and other injected DLLs are still in process.
Does anyone know how to unload them from target process?
Thanks.
The current version of Easyhook unloads injected dll when its executing app domain exits. If you want to exit the injected dll from your injection program, make some form of communication possible with the injected dll, to let it know that its time to exit its app domain.
See this issue
As the EasyHook 2.6 Tutorial says:
The Run method can be treated as application entry point. If you return from it, your library will be unloaded. But this is not really true ;-). In fact your library stays alive until the CLR decides to unload it. This behavior might change in future EasyHook versions by utilizing the CLR Hosting API, but currently we simply don’t know about!
So all you can do is be sure that you properly return from the Run method so that your injected DLL is no longer actively hooked or operating. It will remain there, dead, until the process is finally terminated. As far as the current EasyHook version (2.7), there is nothing you can do to forcibly unload it.
Related
I have a LabView application that uses an external C DLL. When I run my application in the development environment, the DLL is blocked even after the the app is closed.
When I want to overwrite or delete the DLL, I have to first close LabView completely.
Is this a known issue? Can anyone offer a solution for this problem?
Yes, you must do two things in your LabVIEW application:
Specify the path to the library on the block diagram rather than in the configuration dialog (which changes LabVIEW's behavior from load-time linking to run-time linking).
When you're done using the DLL node, wire a null path to tell LabVIEW that you're done using it (which causes Windows' reference count to decrement to 0 and the OS will unlock the file).
More details here: Can I Dynamically Load and Unload a DLL in LabVIEW?
I'm embedding mono in C++ application, and I'm linking it via dll library, which is then loaded into application via LoadLibrary.
When the application starts and the dll runtime linking happens, the mono runtime seems to fail to initialize itself with "Too many root sets" message. I'm unsure when and how the runtime itself is initialized (I thought it happens on mono_jit_init, but the error pops up before any call to any of the mono functions. It occurs exactly at LoadLibrary should I try load it manually instead of relying on mono.lib import library).
I succesfuly embedded it in standalone application, so I assume it is something specific to the way my dll is loaded by the application, but I don't know what exactly.
Any clues?
This may be a limitation of the way the Boehm GC works in windows: it hooks to the operating system at LoadLibrary time to get notifications of the created threads and loaded libraries (this is why you get the issue at LoadLibrary() time and not on mono_jit_init()).
Or it may be that you have really many threads and libraries loaded by the time the GC is initialized. If you link the app to mono directly, does the problem go away? If yes, that should be your current workaround.
In the future (or if building mono from git) you may be able to use the SGen GC which shouldn't suffer from this problem.
We created a plugin; it is a DLL (Run-Time Dynamic Linking) which uses a 3rd party library (wxWidgets) and also links dynamically to that. The host software seems to scan our plugin, but exported functions are not called. We checked all dependencies with DependencyWalker.
We see in the debugger that the plugin is loaded, but the DllMain is not called, and the plugin is unloaded.
We tried loading our plugin from a simple test application using LoadLibrary and GetProcAddress which recognized and called the exported functions.
Having wxWidgets linked statically worked fine, though.
Does anyone have an idea why the exported function, respectively DllMain are not called, or can point out a tool which is capable to monitor the whole DLL loading process?
If wxWidgets is loaded already into the process address space before your plugin is loaded (the host app could do that, or there might be another plugin linking to wxWidgets which is loaded before yours), then there might be a chance that it is another version, missing some of the entry points that your plugin needs. Running the host app under DependencyWalker or WinDbg should show you which wxWidgets DLL is loaded, and you could try to load your plugin from your test app using exactly the same wxWidgets DLL. That should reveal whether there are missing dependencies.
Perhaps the host software does some funky things when loading the plugin and doesn't like wxWindows.
Anyways, try using the ProcessExplorer from the SysInternals suite to check what the process is doing.
I have built a .dll under WinXP that claims it can't find DWMAPI.DLL when it's loaded. The problem is that this DLL is a Vista DLL, and this a known issue for XP users that have IE7 installed. The recommendation is to uninstall IE7 or repair the .NET Framework via Add/Remove programs. I did the repair, and nothing changed. I'm not about to uninstall IE7 since there must be a better solution that's not the equivalent of "reinstall windows".
I've read bad things about people who attempted to uninstall IE7, so I'm reluctant to go that route.
I am using C++ under Visual Studio 2003 (7.1). I don't see an option where I may have forced delay loading at application launch. I just used default settings when I created the DLL project. I did just now find an interesting option, Linker->Input->Delay Loaded DLLs, so I put DWMAPI.DLL in there to force it to be delay-loaded. However, I get this when linking:
LINK : warning LNK4199: /DELAYLOAD:dwmapi.dll ignored; no imports found from dwmapi.dll
.. and it of course didn't change a thing when trying to load my DLL. For the heck of it, I added the whole tree of DLLs that lead to DWMAPI.DLL, and I get the same message. (For the record, it's foundation.dll->shell32.dll->shdocvw.dll->mshtml.dll->ieframe.dll->dwmapi.dll .)
To be more specific about what I'm doing, I am writing a Maya plugin and get the always-helpful text in the script editor:
// Error: Unable to dynamically load : D:/blahblahblah/mydll.mll
The specified module could not be found.
//
// Error: The operation completed successfully.
//
// Error: The operation completed successfully.
(mydll) //
I used Dependency Walker to initially track down the problem, and that's what lead me to DWMAPI.DLL. These are the message depends gives me, and DWMAPI.DLL is the only thing that has a yellow question mark next to it:
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.
Gerald is right. Maya is, in fact, using a different PATH than the Dependency Walker. My plug-in loads another DLL (for image processing) that lives in the Maya plug-ins directory and depends found it with no problem, but Maya didn't. I had to add ";plug-ins" to the PATH in Maya.env.
Seeing as this problem wasn't related to DWMAPI.DLL after all, but DWMAPI is a common problem, I'll post the best link I found about the DWMAPI issue on Novell's website here. Basically, most programs will have this warning in depends.exe, but if there is a delay-load icon next to it, and you are sure that the program won't directly or indirectly call DWMAPI, then it's fine. The problem is elsewhere. If the delay-load icon isn't present, then you have to look at the /DELAY and /DELAYLOAD options in Visual Studio. The fact that depends gave me a "warning" and not an "error" was a clue to the fact that DWMAPI is not being loaded automatically.
Based on your updated problem, DWMAPI.dll is probably not your problem. Dependency walker will always give you that error whenever you are linking to mshtml as it always checks delay loaded DLLs.
At this point my best guess is that you have your project set to dynamically load the runtime libraries and the search path for DLLs is being changed by Maya. So it may be unable to find the MSVC runtime DLL(s). I haven't developed Maya plugins in a long time, but I've had that problem with other apps that have plugin DLLs recently.
Try changing your setting in C/C++->Code Generation->Runtime Library to Multi-Threaded rather than Multi-Threaded DLL.
Aside from that you can try fiddling with Dependency Walker to make it use the same search paths as Maya and see if you can come up with another dependency problem.
As a last resort you can launch Maya in a debugger and set a breakpoint on LoadLibrary and find out which library is not being loaded that way.
This is a tricky one. There's really 2 main ways you will get this error.
1) You have your project set to force delay loaded DLLs to load at application launch. DWMAPI.dll is a delay-loaded DLL and thus normally will not be loaded unless one of it's functions is called. That won't happen on XP unless you're trying to do it in your DLL. But it's possible to set a compiler option to force your app to load the delay loaded DLLs anyway. If you're doing that, don't.
2) It's often a false error that you will get from depends.exe when there is another problem. Run your DLL through dependency walker and see if there are any other dependency problems. If all else fails, try uninstalling IE7 and see if the problem persists. If it is a false error, after you install IE7 you will see the real error. You can install IE7 again afterwards.
I had exactly this problem.
Sneaky problem that took hours to solve.
Anyway. I compiled my managed C++ application on the release machine. Got complaints from customers that could not run it, worked like a charm on all of our machines.
It turned out that the release machine was automatically patched one night a month ago with the ATL vulnerability fix, and so was all other machines also, except one XP machine.
That particulare XP machine could not run the application either. Installed the ATL fix (see link below), and voilá, every thing worked just like before.
http://www.microsoft.com/downloads/details.aspx?familyid=766A6AF7-EC73-40FF-B072-9112BAB119C2&displaylang=en
So lesson learned, always check your intermediate manifests (found the in debug or release directory), that will tell you what version of the DLL that the program have been linked against.
Hope it helps anyone.
Try changing your setting in C/C++->Code Generation->Runtime Library to Multi-Threaded rather than Multi-Threaded DLL.
I have a VB.NET ClickOnce application that I am trying to install on my computer. Previously, I was able to install and run these apps without issue. Now when I install the application, I can see the flash of a window opening, and then nothing. (There are also no processes left hanging or anything when viewed with the task manager.)
After some digging around I noticed that there are files in my Temporary Internet Files with names like "FusionBindError" and then my application name and different DLL names.
I have done everything I can find on the net to do, reinstall applications, reinstalled the .NET Framework, deleted my Local Settings folder and relogged in.
Does anyone out there have any other ideas for me to try?
I tried the Mage.exe suggestion, but it failed to help. Same with the other installation location suggestion. The application flashes at the bottom of the screen but does not open. I have tried using FUSLOGVW to check the bindings and nothing shows up in there. (Good or bad, there are no binding entries.)
Have you tried using mage.exe? This is a command-line tool that comes with .NET framework. Start up a VS command prompt, and try mage -cc. This will clear your applicaiton cache and will force a new click-once download. This is the first thing I do when my click-once applications fail and it works 99% of the time.
A couple of suggestions:
FusLogVW isn't working for you because you have to enable assembly binding failure logging inside the registry. This MSDN article describes how to do this.
Another thing that comes to mind is, perhaps the ClickOnce app install, or perhaps the whole ClickOnce store is corrupted. Try deleting the ClickOnce app store then reinstalling the application.
It's possible that new prerequisites were added that you don't have on hand. If the URL you are using points directly to "my.application" or whatever your equivalent is, prerequisites won't be processed.
So try pointing to the setup.exe that is created in the same directory as the .application file.
Other than that, it sounds like you're doing all the right stuff...
Also, it could be useful to run the fuslogvw utility on a machine where the application actually works. Or reflector.
And then see if indeed any of its dependencies being loaded surprise you.
Also, for these types of errors, be sure to check if disabling the antivirus resident protection helps. Sometimes it causes problems accessing assemblies' manifests and such.
I uninstalled my Kensington Mouse software, and that resolved my installation errors.
Who knew that mouse software that I never used could cause so much trouble??
Sometimes if your machine is working for days this problem will show up. Try to restart your machine. The same problem happened to me and it disappeared when I restarted my machine.