Question

I have a very complicated problem that occurs only for non-admin windows user.

I run a script S that resides on the desktop and calls a function in a C++ dll. Then the flow is as follows:

  1. My C++ dll creates a Delphi process, sending it a GUID as a parameter.
  2. On initialization, my Delphi process registers a class C with the given GUID using a COM object factory.
  3. My C++ dll tries to call CoCreateInstanceEx with the same GUID. ==> The operation fails with HResult 0x80029c4a Error loading type library/DLL.

No exception is thrown from the Delphi side - registration seems to work smoothly.

I used process monitor and saw to my surprise that when CoCreateInstanceEx is called, there is an attempt to read my Delphi exe file from a wrong location. Instead of trying to access where the exe is registered, there is an attempt to access the exe from the desktop, where script S resides, and of course the exe is not there.

This happens only to non-admin user. Also, if an admin user ever run this script before, it runs perfectly fine for the non-admin.

I now try to figure out why this is happening. This is why I try to understand the flow of CoCreateInstanceEx. I didn't find any useful information on the web. So how does CoCreateInstanceEx try to load types? Where does it try to look? Do you have any idea how the described situation can happen?

Any information or idea will be very appreciated!

Was it helpful?

Solution

Turns out that the exe of the Delphi process was registered with relative path instead of full path.

I'm still not sure why for admin user it worked correctly... So if anyone has an idea I'll be interested to hear.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top