Vista, CoTreatAsClass problem, TrustedInstaller


  • My application is using CoTreatAsClass API to put its COM object in place of existing one (DirectShow's CSLID_FilterGraph) for debugging purposes. While things work great on Windows XP, with Vista it seems to be a problem to put everything in proper way.

    CoTreatAsClass does not return any error during registration from under regsvr32 process (run AsAdministrator), however it does not effectively registers my COM object for substitution. I found that it is probably caused by the facts that CLSIDs of interested have their registry keys owned by TrustedInstaller service and are read-only for Administrators. In order to succeeed with CoTreatAsClass it is required to take ownership of respective CLSID key prior to call to CoTreatAsClass. I thought that API call should have returned as error code such as E_ACCESSDENIED because it clearly failed to activate the requested substitution.

    After CoTreatAsClass is initialized taking ownership on the key and following CoTreatAsClass call. I see that my COM objects is instantiated only when hosting application is started AsAdministrator. Being run under limited privileges account original CLSID is used and TreatAs part is ignored. Are there any suggestion on extending effect of TreatAs substitution onto applications started without elevation?
    2009년 6월 20일 토요일 오후 2:04

모든 응답

  • To follow up the question: wrapping the CoTreatAsClass into following sequence works the problem around:

    • adjust process token privileges
    • take ownership of the relevant CLSID (HKCR\CLSID\{...}) key from TrustedInstaller
    • reopen the key now as an owner to obtain additional access to the key
    • add permissions to write to the key
    • the CoTreatAsClass call of interest - this time it does add the subkey and activates TreatAs feature on the COM class
    • restore original owner (TrustedInstaller) and DACL on the key

    Some code is here , in CSpyT<...>::UpdateRegistry function.
    2009년 6월 22일 월요일 오전 8:08
  •   Roman, as you know in another thread I'm also using CoTreatAsClass in Win XP to substitute my custom SampleGrabber for the original SG. Now that I'm testing it in Windows 7 I'm seeing the same problem that you are seeing. Could you please elaborate on your work around for this?


    Tom Fisher

    2012년 4월 3일 화요일 오전 4:00
  •  The solution steps are above, and the updated code snippet link is: /trunk/FilterGraphSpy/Common.h

    2012년 4월 3일 화요일 오전 6:47
  •   Thanks Roman. It also just occurred to me that in Win 7, I should be able to manually(As Administrator in Regedit) change the TreatAs reg keys for the original SG to accomplish the same thing.

    Is this correct?

    Tom Fisher

    2012년 4월 3일 화요일 오후 2:59
  • The code I linked to above does all automatically (nothing needs to be manually done). In your original question you can do easier than with CoTreatAsClass. As you want to take over Sample Grabber in a particular isolated system you can just have Sample Grabber's CLSID for your own filter class. This wil be sufficient and to revert the original behavior you would just regsvr32 quartz.dll and this will restore original mapping of this CLSID to the original Sample Grabber coclass. CoTreatAsClass is neater, however you might prefer to do it simpler.

    2012년 4월 3일 화요일 오후 3:18
  •   So all I have to do in my code is change all occurences CLSID_MyNewGrabber to CLSID_SampleGrabber and then register the DLL ? I don't need to do anything to the orig grabber?
    2012년 4월 3일 화요일 오후 3:38
  • As you want that your target application picks your SG instead of standard, and not other applications are using SG in this system (or you are OK with this), registering with CLSID_SampleGrabber is okay. Not the best way to hook, but works out in this scenario, CoTreatAsClass gives you the same result, in just a bit more longer way.

    2012년 4월 3일 화요일 오후 3:48
  •   Thanks again. I just tried this in Win7. I successfully(noerrors) registered it as you recommended via regsrv, then rebooted and the registry entry for the SG CLSID still lists Qedit.dll as the file source. In addition, when I try to manually change the reg entry to point to my dll, it will not allow the change even when I run regedit as admin. What am I doing wrong ??;-((

    2012년 4월 3일 화요일 오후 4:23
  • my new SG running in Win7(x64) by first manually "adjusting" my priveleges in the registry. That allowed me to change all the CLSID_SampleGrabber entries file references from Qedit.dll to my SG dll.

    Thanks again for your suggestions and help.

    Tom Fisher

    2012년 4월 4일 수요일 오후 1:09