locked
No way to connect to COM server started by elevated process RRS feed

  • Question

  • I have an installer (our own exe, not MSI) that, after it finishes installing the application, optionally runs an instance of the application. In fact, this is the default behavior highly advisable in our case. The installer is obviously running with admin privileges (it has a manifest demanding it, and undergoes the elevation dialog when the user starts it). When the installer uses CreateProcess to start the application, the application also runs with admin privileges. There is no simple way to tell CreateProcess not to do so, which is a separate, but related bug - see the "How to CreateProcess NOT as administrator" thread. Thus, instead of using CreateProcess, I use the SAFER API and SetTokenInformation to create a restricted token (no admin privileges, medium integrity level, etc.), and then CreateProcessAsUser to start my application without admin privileges.

    But now comes a new problem, which is what this thread is about. My application exposes a COM server (CLSCTX_LOCAL_SERVER, REGCLS_MULTIPLEUSE, no RunAs, i.e. the default behavior that CoCreateInstance will only connect to the application running as the same user as the invoker). Well, if I start a new process from explorer that tries to connect to my application (that was started from the installer) via CoCreateInstance, the attempt fails, even though both are running as the same user. I guess the reason is that the tokens of the two processes are still somewhat different, despite my attempts to restrict the application's token. Needless to say, CoCreateInstance also fails if I do not try to restrict the application's token and let it run with admin privileges. (When CoCreateInstance fails, what actually happens is that it runs a new instance of my application instead of connecting to the one already running. This is unacceptable in my case, and CoCreateInstance eventually fails when the new instance automatically exits after it sees that the instance started by the installer is already running.) If I stop the application started by the installer, and start a new instance from explorer, the problem goes away, but that is not an acceptable workaround in my case.

    To make a long story short, one can not connect to a COM server exposed by a process started from a process running with admin privileges. This all goes back to the original bug, that from an admin process, one can not start a process with the exact same properties that Vista would give a process started by the same user from explorer. Microsoft, please, before Vista is released, and it's too late, give us an API to do so! Otherwise, either document what has to be done to the token to allow CoCreateInstance to connect to it, or fix CoCreateInstance to make it connect to it anyway.

    Sunday, August 27, 2006 10:08 AM

All replies

  • I now know how to get an admin process to run a process with the same privileges it would have if started from explorer, and thus get around the COM problem. It is not easy, however, and involves writing a simple service. See the "How to CreateProcess NOT as administrator?" thread.
    Sunday, September 17, 2006 5:20 AM
  • It seems like not only the elevated-privilege COM server cannot be contacted from the applications. Any COM server that is running at a different (high/low) integrity level then the application itself cannot be contacted. The Windows spawns a new COM server for applications contacting it but running at different integrity levels. So 2 instances of the same COM server end up running under the same user account.

    Take a look at my issue here : http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=950792&SiteID=1

    I am also trying to find, and so far in vein, any information about Vista COM framework changes...  Do you have any references pointing to this by any chance?
    Wednesday, November 22, 2006 9:47 PM
  • See my answer in that thread (Single-instance DCOM server access problems with high/low integrity levels )
    Thursday, November 23, 2006 1:51 PM