Click here to Skip to main content
11,712,524 members (80,884 online)
Click here to Skip to main content

In-process Servers and DCOMCNFG Utility

, 8 Dec 1999 64.7K 28
Rate this:
Please Sign up or sign in to vote.
Discusses DLL surrogates and how legacy in-process components can participate in a distributed environment
<!-- Article Starts -->

In-process servers can never run without a parent process. Period. However, since the release of Windows NT 4.0 Service Pack 2, in-process servers can be remoted as long as a surrogate is available to provide the needed address space. One such surrogate is the file dllhost.exe that can be remoted and then instructed to load any in-process component, providing the component with a surrogate parent process and security context. But how do you set security permissions, identity, client's authentication level, and the set of protocols and endpoints for use by clients for such an in-process component? One easy way of setting this up is to use DCOMCNFG utility. However, by default DCOMCNFG utility won't list components housed in in-process servers. It will list only component executables registered on the system.

Run OLEViewer and select any in-process DLL server object. Select the Implementation tab, and select the Use Surrogate Process check box. Provide a path to custom surrogate or the default <\winnt\system32\dllhost.exe> surrogate. Select the Registry tab (this will add the DllSurrogate named value under the AppID key).

Now run the DCOMCNFG utility. The in-process DLL server object will show up in the list of applications. Basically, we convinced the DCOMCNFG utility that the in-process DLL server object is no longer alone and that it has a parent process where it will be housed when it is remoted.

Example project:

1. Choose ATL COM AppWizard and DLLSurr as name of the project. Be sure to choose the Server type as Dynamic Link Library (DLL).
2. Add a new ATL object with a short name ATest.

Build and register the server. Select the component ATest in OLEViewer (Object Classes->All Objects->ATest). Select the Implementation tab, and select the Use Surrogate Process check box. Provide a path to the default surrogate as <\winnt\system32\dllhost.exe>. Select the Registry tab (this will add the DllSurrogate named value under the AppID key). Now run DCOMCNFG and select ATest. Choose Properties, Security, and edit Use custom access permissions and select an NT user name (for demo purpose, you may want to choose your NT user name). Select Deny access from the Type of Access combo box. Click OK all the way to close the DCOMCNFG utility.

Client code to launch the server:

#include "stdafx.h"
#include <comdef.h>
#import "..\DLLSurr.tlb" no_namespace named_guids

{
    // This block of code assumes that you have already
    // initialized COM libraries somewhere in your project.

    try
    {
        // For demo purpose, assume that the component is
        // launched on a local m/c.

        // Try to inject the component server into dllhost.exe's
        // address space
        IATestPtr ptrTest = NULL;
        HRESULT hr = ptrTest.CreateInstance(CLSID_ATest,
                NULL, CLSCTX_LOCAL_SERVER /*This flag is important*/);
        if(FAILED(hr))
        {
            TRACE("Failed to create ATest component.\n");
            _com_issue_error(hr);
        }
    }
    catch(_com_error& e)
    {
        TRACE(e.ErrorMessage() + _bstr_t("\n")); // Probably, the trace should
                                                 // be <Access is denied>!
        if(e.ErrorInfo())
            TRACE(e.Description() + "\n");
    }

    // At this point, if you see the processes list in the Task Manager,
    // you will find dllhost.exe sitting there. Kill that process before
    // you change any security settings in the DCOMCNFG utility for the
    // component.
}

Alternatively, you can also test the server in OLEViewer. From the menu, choose Object...CoCreateInstance flags, select CLSCTX_LOCAL_SERVER and deselect all other items. Right click on the component name, select Create Instance On..., and enter your machine name.

Conclusion:

This article discussed DLL surrogates briefly and how legacy in-process components can participate in a distributed environment.

It is interesting to note that Microsoft SQL Server extended procedures (which are nothing but DLLs) runs in SQL Server address space and that a badly behaved extended stored procedure could crash SQL Server.

References:

1. Inside Distributed COM, Guy Eddon and Henry Eddon, Microsoft Press 1998.
2. MSDN Library April 1999.

System Requirements:

Microsoft Visual C++ 6.0 w/ sp3, NT 4.0 w/ sp4.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here

Share

About the Author

George Poulose
United States United States
No Biography provided

You may also be interested in...

Comments and Discussions

 
GeneralInstallation Changes Pin
TechyMaila20-Jun-06 18:50
memberTechyMaila20-Jun-06 18:50 
QuestionHow to invoke In-proc server from VB Client ? Pin
KIRAN BIDDALA18-Oct-01 8:21
memberKIRAN BIDDALA18-Oct-01 8:21 
AnswerRe: How to invoke In-proc server from VB Client ? Pin
cornucopic13-Mar-06 5:07
membercornucopic13-Mar-06 5:07 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Terms of Use | Mobile
Web01 | 2.8.150819.1 | Last Updated 9 Dec 1999
Article Copyright 1999 by George Poulose
Everything else Copyright © CodeProject, 1999-2015
Layout: fixed | fluid