Is there a way to check if an application is using a particular object? Or, a way to check if its using a specific dll (since its an in process obbject)?

I found a usefull looking dll (picstart.dll) inside the version 6 of MPLAB, it seems it might be a controller for a Microchip device programmer. It would sure be usefull to me if I could make a seperate controller for one of these. But since it has some methods that will not work in VB, exploring it will take some work. So before I put in a bunch of effort, I want to make sure its what MPLAB uses to run its programmer.

Any ideas?
Posted on 2003-03-06 23:00:03 by Ernie
Since all COM is just a table of jumps...why not replace (aka hook) the original jumps BEFORE MPLAB starts with dummy calls to your own logging routines and then forward all request to original routines... this way you could find out / collect information about what routines/objects/parameters some application will use IMHO
Posted on 2003-03-07 01:54:06 by BogdanOntanu

Yep that would work, I thought of it, but it seemed like a lot of work, there are several interfaces to clone, unless I just trap the DllMain proc so I can see if it loads.

BUT... how about I just rename the dll (so MPLAB can't find it) and see what happens? AH HAAA!, no more reference to PicStart being on my programmer list.

So its just what I think it is, and worth exploring.

Thanks guys.
Posted on 2003-03-07 08:44:57 by Ernie
You could also use masm's tools to get a peek at the functions (methods) stored within the dll.


I use this from time to time to "snoop" around ;) .

Posted on 2003-03-07 15:52:30 by NaN
I tried this first, using DUMPBIN.EXE. The dll has just 4 exports:


These should be old news to us COMmies. Its how I initially knew I was dealing with a COM object.

So now it becomes usefull to make a message spy for it. What I think *might* work is to make my own CoClass dll with the same CLSID, dll name, ect as the dll in question. Each method will just be a report it was called (so I can see how each operation is negotialtd) and then pass off the work to the real dll. Basically, make the spy dll with the same name as the interesting dll, same CoClass ID, Interfaces, ect. Then the 'real' program will load my 'spy' dll, and my spy dll loads the real dll, and maybe I learn something by observing how they work together.

However... there is a problem. The real dll will have the same CoClass ID built into it. Even with the real dll renamed I can't use CoCreateInstance to get an object handle, cause the registry entries will be spoofed to point to my dummy dll (by renaming the spy.dll with the real dlls name).

I'm going to try using LoadLibrary instead of CoCreateInstance to get my interface pointer from the real, renamed dll. I should just need to invoke its DllGetClassObject. Since its all inprocess, and CoInitialize will have been called anyway, I have hope this will work.
Posted on 2003-03-07 23:09:09 by Ernie
Why not just use Elicz COM spy tool?

Posted on 2003-03-07 23:24:23 by _Shawn
Elicz COM spy tool?


(OK, I just got myself a copy, looks like a nice piece of work, but seems to lack any information on how it works! I'll stick to what I understand.)
Posted on 2003-03-08 09:38:28 by Ernie
Ernie, could you share this dll with me. I dont have it in my version of MPasm. I have a program called EXE Scope that may work (or might not).
Posted on 2003-03-08 17:44:30 by NaN
Its part of the new 32 bit MPLAB free download, which is now up to 6.13. You'll find it in the C:\Program Files\MPLAB IDE\dlls folder.
Posted on 2003-03-10 20:46:34 by Ernie