I'm trying to inject a DLL to a new process using the latests 32 bit Detours library.
http://research.microsoft.com/en-us/projects/detours/
It worked for me in the past but after a change in the DLL, it stopped working for all processes. When I resume the process I get a message box saying
The application was unable to start correctly (0xc000007b). Click OK to close the application.
I've recreated this with a plain and empty DLL injected that has no dependencies other than kernel32.dll. With other executables it works perfectly.
Any idea why this can happen?
It turned out that the problem was the the DLL I was injecting using Detours did have any exports. Once I added a dummy export, everything worked perfectly.
I don't know what the documentation looked like at the time you encountered this but based on a dummy export apparently working around the problem and the current documentation, you probably missed some requirements stated in Detouring 32-bit and 64-bit Processes. Unfortunately it says to do things without explaining how the pieces fit together.
Detours expects your helper DLL to export DetourFinishHelperProcess with ordinal 1. This isn't a function you define yourself. It will get compiled into your DLL as a result of calling DetourIsHelperProcess in your DllMain function as shown in the Using Detours sample.
Related
I am writing an Excel VSTO add-in. This add-in loads and runs unmanaged code.
In the startup code of the unmanaged dll, an invisible window for request handling is created. This function call causes a managed exception (LoaderLock) and if I remove it, everything works. I want to avoid creating an extra version just because of this. Is there a way for the unmanaged code to find out at runtime whether it is running in a managed thread? In this case, I could add a runtime check. The window is only needed in a fully unmanaged environment.
Note 1: The issue only occurs in this Excel add-in; a stand-alone managed console application using the unmanaged dll does not show this problem.
Note 2: I know that there are many things that should not be done from within DllMain. What I am doing has been working for more than a decade in managed and unmanaged environments and I want to keep code changes as small as possible.
Checking if mscoree.dll has been loaded has done the trick for me:
if (::GetModuleHandleW(L"mscoree.dll") == nullptr)
This: Checking if a WIN32 / Unmanaged DLL is loaded from a COM module on runtime and this: What does it mean when code "runs on" the .NET CLR? helped.
As exposed in the comments below, this does not tell which type of thread has loaded the dll, but only whether there is any managed component in the process. A more precise check would still be preferred. For the moment, I can live with this solution.
I have a question, I came across running an x86 app on XP x64 that throws up a couple (2) of the "The application has failed to start because XYZ.DLL was not found". My question is, it still runs fine! So how does that work? I know if some function is missing you get that and the app doesn't actually run. What causes this message yet it runs fine? I don't think LoadLibrary() would put up a message? Is it from some #pragma comment( lib, "XYZ.lib" ) in a library even if that module not used?
TIA!!
My question is, it still runs fine! So how does that work?
If a DLL function is statically linked and can't be found at runtime, the OS will fail to create and run the process at all. So, the obvious answer is that the DLL function is linked dynamically instead via calls to LoadLibrary() and GetProcAddress() at runtime.
I know if some function is missing you get that and the app doesn't actually run.
If the missing DLL function is linked statically, yes.
What causes this message yet it runs fine? I don't think LoadLibrary() would put up a message?
Actually, it can. Use SetErrorMode() to avoid that. This is stated as much in the LoadLibrary() documentation:
To enable or disable error messages displayed by the loader during DLL loads, use the SetErrorMode function.
See Silently catch windows error popups when calling LoadLibrary().
Is it from some #pragma comment( lib, "XYZ.lib" ) in a library even if that module not used?
Linking to a DLL's .lib creates static linkage to the DLL. Unless the linker has a delay-load feature available AND the project is making use of that feature, in which case any static calls to the lib's referenced DLL functions are converted into runtime calls to LoadLibrary()/GetProcAddress() by the compiler+linker for you.
I would like to create a C# managed x86 DLL wrapper for OpenPop that I call from my unmanaged (C) code.
I have done this for other products in the past using the NuGet "UnmanagedExports" package which seems to work well.
I tried doing this with the OpenPop.net package but I get a GPF as soon as I call "client = new Pop3Client();". If I remove all calls to OpenPop, the DLL loads and returns properly.
Furthermore, I am accessing OpenPop from within a try/catch structure yet it still fails with a GPF (instead of catching this error).
I installed the latest OpenPop.net package v2.0.6.1120 and I am targeting .net v4.5.2 (I also tried v4.0 with no difference).
Can OpenPop.net be used like this in conjunction with the UnmanagedExports package? If so, any suggestions on how I might debug this?
Thank you!
(I realize that this is free software so support is no expected so I am more than happy to pay for support if required)
I found the problem... I was not copying the OpenPop.dll to my application folder where my DLL is loaded. Once the file was available, the GPF no longer occurred. Too bad this was not able to be trapped by the C# exception handler.
I have a VB6 program which tries to run a DLL written in C#.
This DLL has a COM interface so I can create an object of a class in it with "CreateObject".
The problem is that it runs and works well when I run it from the VB6 IDE, but when I make an EXE and try to run it, it throws the exception:
"Automation error. The system cannot find the file specified (-2147024894)."
Why is it happening and how can i solve it?
Look at Project, References in the IDE and look which dll or ocx file belongs to the object you are referencing with CreateObject (the Object Manager might also help to find out).
This dll file must be available when the exe is compiled, too. Usually, you need to have it registered with regsvr32.exe.
A technique I use to figure issues of this type is to open the add reference dialog in Visual Basic 6. I scroll the list of available COM Libraries and see if the problem DLL is listed. If it is then CreateObject should work, you should be able to assign it do a variant variant and use late binding to access it's members.
In addition try temporally set a reference to the variable and instead of using CreateObject use the = New and see what error messages, if any, it gives you. Generally I found them to be more informative then the ones thrown by CreateObject.
Finally it would help if you post the reason why you are choosing to use CreateObject instead of setting of a reference. If the DLL is a known object that will be continually used by the program then a reference should be set and early binding generally used.
Finally it may be that the error is resulting from a dependency of the C# COM DLL not the DLL itself. If for example I was to take a Com Library and properly register it but it relies on the COM Library Widget2000 and it NOT registered then it will throw the automation error. Especially if you are testing the EXE in it's installed environment and not the environment in which you complied it.
For example suppose I have a CAD program written in VB6 and I have source tree that begins with MyCAD. THe exe is in MyCAD/MainEXE and the shape library is in MyCAD/ShapeLibrary. I run the IDE everything is fine. Then I make my setup and goto my test machine and install it and it error on the creation of shapelibrary.
The first thing I would do it check if MainEXE will run straight out of the MainEXE directory of my source tree. That test will eliminate whether it is a install issue or a quirk of the IDE vs complied version. Then I would look at the setup and see what not being registered. Also look at either the source for the C# library or the setup for the library and see what dependencies it needs. Since it a complied COM DLL you should be able to use a dependency walker tool to see what COM references it needs. Finally make sure the correct version of the .NET framework is installed.
If you are compiling the C# DLL on your test machine - make sure you have ticked the register for COM Interop setting. If you are not compiling on the same machine you need to run RegAsm with the /codebase option.
try compiling it as an installer and include the dll/com that you use in the compilation of the installer package so that the dll/com that you use will be include in the compilation of your exe.., and install it in the windows not just copy past it.
I've created a Windows library with an implementation of nsIModule (and nsIProtocolHandler) a while ago. I've only recently got round to debugging it some more, but FireFox doesn't run my library any more. I've tried to register my module again, with regxpcom and deleting xpti.dat and compreg.dat, but my contract-id doesn't get listed. If I try debugging firefox or regxpcom, it appears like my DLL doesn't get loaded (where they used to call NSGetModule of my DLL).
Has something changed to the registration process? Do I need to provide a .xpt file? It wasn't required before, and I don't need/use any interfaces of my own, so if I do it would be an empty type library anyway...
http://xxm.svn.sourceforge.net/viewvc/xxm/trunk/Delphi/gecko/
I've done a bit more searching, and found out what I need is to create an XPI file.
https://developer.mozilla.org/en/Creating_XPI_Installer_Modules