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?
Related
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.
I have program that uses a dll to make my device work. The driver for this device is installed on other computers.
My program works properly on my computer, but if I try to install it on another computer the dll no longer functions correctly (dll method can not find device).
But!, If I'm rebuild the program on the failing computer it works well.
What the reason of this behaviour?
Why it start work properly only after rebuilding ?
It could be binding to a different set of dlls that it is dependant on one one computer but these could be different (but compatible) on the other target machine, a recompile would mean that this code then linked against a different library version and functioned.
This is however a best guess as the question is not reall answerable in its current form
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.
How would I go about calling a dll from kernel mode?
I have tried making a custom lib file using multiple techniques but I cannot get anything to work. I have also researched on google but cannot seem to find anything. I was also curious if it was possible to create entries in the import address table from c++ or at link time?
The fundamental issue for a DLL in kernel mode is whether the DLL calls any user-mode code. If a DLL contains anything other than native kernel API calls, you'll get linker errors if you try to link your driver with it when you build (and the kernel wouldn't load it anyway)
check the following link
Calling a DLL in a Kernel-Mode Driver
Edit:
Another useful link
DLLs in Kernel Mode Tim Roberts
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.