I have been trying something which may turn to be impossible in the end. It's been a long while since I've been in COM land.
Consider two apps and a COM STA DLL. First app loads COM STA DLL as a plugin and this DLL tries to register itself "globally" so that the second app sees it. Something like GetObject("Excel.Application").
I have tried two approaches (which may turn to be the same thing).
Approach 1: I have tried using CoRegisterClassObject to register my STA instance of an object. This call succeeds with S_OK. But if I try to GetActiveObject using the same CLSID immediately after CoRegisterClassObject, I get MK_E_UNAVAILABLE - 0x800401e3.
Is GetActiveObject the wrong API to call? If not, why would it fail?
Approach 2: I have also tried using GetRunningObjectTable, IRunningObjectTable:Register and CreateClassMoniker but when trying to get to the object from ROT in a second app, I am faced with another failure.
My STA DLL is properly registered and uses typelib for marshaling (which is also registered).
Am I missing something or is what I am trying to do not possible at all? If latter, are there any simple alternatives for me?
It seems when you want to use GetActiveObject your friends are RegisterActiveObject and RevokeActiveObject. I was totally off. It works perfectly now! I hope this helps someone.
Related
Is there any issue with starting a COM component exe using CreateProcess followed by CoCreateInstance (using the class ID from CLSIDFromProgID) ?
I have done this and it seems to work but am getting side effects on closing down.
Sometimes it closes down properly, sometimes (when looking through Process Explorer), the process stays active but moves in the tree.
Sorry for being vague but what I'd like to know is whether it's legitimate to start a COM object in this way (CreateProcess then CoCreateInstance) or whether the only way to properly achieve this is just to call CoCreateInstance?
Thanks!!!
Only CoCreateInstance. Why do you wanna bother with CreateProcess at all?
I have written a simple dialog based MFC application using a thirdd party soft tree control. I am trying to write a automation client for the application. For this I wrote a singleton out-of-process COM Testing Agent for the dialog based application sample app. The Com server exposes a Run method to the automation client. This Run method access the gut of the mfc app and actually mimicks a click on the GUI. The problem i am facing is when the automation client tries to invoke Run method on the Com object it is able to invioke it but when the Run method crashes when it tries to access the control's methods such as getCaretInedx.
I have tried to cach the exception and log the message to a file but have not been able to do so.
My question is: Is there any limitation in the way a com object can access the application? Or am i missing anything to facilitate this.
Any help or pointer is greatly appreciated. Since this is my first in COM I have not been able to make much progress.
Thanks
Is your client's window actually being created? If not, the hwnd doesn't exist, which is probably why it crashes. Furthermore, your client may be hidden behind another window when it is started, and may exhibit different behavior than when the user called it through regular interaction.
In general, calling code that relies on or interacts with the UI from a COM server is fraught with peril, especially when that code is not written in the first place to behave like this. Most UI isn't that defensive about HWND's existing etc.
I want to use Deviare V2 API to intercept winapi calls from a test application. The problem is the hooks and the system calls are in the same process and for this reason the calls aren't intercepted.
If I open separate processes for each of them then the interception will work. Does anyone else ever had this scenario/problem ?
The thing is I'm trying to add some unit test to a peace of code and instead of modifying existing production code to wrap/mock all system calls I thought I could simply intercept all this calls and fake them as I wish.
It's actually much easier to hook APIs in your own process (actually when you want to hook in another process you need to DLL inject into that process anyway, so basically when you're hooking in your own process you can just skip that step). It might be a bug with the library you are using. Try Microsoft Detours or if you're up to it, patch the memory yourself, it's not that hard actually, a few hours work if you're new to the subject.
What you need to be wary of is that some C++ compilers will in some cases (I think debug builds) use some jump stub or something like this, which can interfere with the hooking process. In that case you must take some extra care when hooking - MS Detours probably does this properly. You can try debug/release builds if that affects your success.
What I mean is to get the proper address of the API. If the function is in a DLL like is the case with WinAPI you can be sure you are getting the right address if you use LoadLibrary and GetProcAddress.
On a side note I don't think API hooking is a proper way to avoid mocking/stubbing for testing, although it should work.
If you are interested more in how hooking works you can check out my paper on it here: http://lkm.fri.uni-lj.si/zoranb/research/berdajs-bosnic%20SPE%202011.pdf
I have created a COM dll using ATL. When I attempt to use it within unmanaged C++ I find that I get a buffer overrun. I am currently testing using one simple method called OnInitIDA() and all I do within this is a cout statement and return. When I ran this the HRESULT returned would be 0 however it would not output the line I expected. By using the step over and step into functions of the debugger I found that rather than entering the code for OnInitIDA when called this actually went into another method called GetInclusionList. Once I placed a statement within this method and when the app was run this line was printed off. Does anyone have any idea why the wrong method would be invoked?
If it helps my code has been posted here: https://docs.google.com/open?id=0B3ehFEncKJH7ZDgxMGI1YjgtZTE2MS00ZTBkLWI2NzgtYzVhZjUxOWEzZGI0
This sounds like you've changed your interface since building your client.
It would be a good idea to clean and rebuild all your projects.
I found an answer to my question. Basically, when I created my dll project it inherited from IDispatch, however the interface I was using in the test app expected it to inherit from IUnknown. This meant the interfaces did not match, with IDispatch inheriting from IUnknown and adding a number of methods. Change changing these to match the dll worked.
Ok so I am learning C++ slowly. I am familiar with all the console syntax and everything, but now I'm moving on to windows programming. Now what im trying to do, is create a DLL that I inject into a process, so it's hooked in. All I want the C++ application to do, is have text in it, that says "Hooked" if it's successfully injected, and an error if something wrong happened. Or even if I can do it without a DLL, Just open an executable, and when the certain process I'm trying to hook is opened, the status is changed to "Hooked". Also I have a safaribooksonline.com account so if there is any good reads you would recommend, just write it down. thanks
I think you might be looking at this backwards. In C/C++ an application 'pulls' a DLL in rather than having a DLL 'injected' into an application. Typically for plugins/hooks, there is some mechanism to inform an application of a DLL's availability (often just its presence in a specific directory) and a configuration file or some other logic is used to instruct the application to explicitly load the library, extract a function or two, and call them.
For Windows programming, I'd suggest doing a search for examples of the LoadLibrary() API call. You'll likely find a tutorial or two on how to do it.
If by "hooked" you mean, "have my DLL run in that processes' address space", you want CreateRemoteThread(). This is fairly advanced and difficult to debug, because your bugs make the other program crash. It's how a lot of malware works, by the way.
If you mean "have my DLL get notified of activity in the other process", you want SetWindowsHookEx().
Sounds like you want to inject as soon as the application starts? You can do that with Microsoft's Detours DetourCreateProcessWithDll(). Example here.