Environment: VC 6.0 w/ sp3, NT 4.0 w/ sp4.
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. Select the
Registry tab (this will add the DllSurrogate named value under the AppID key).
Provide a path to custom surrogate or the default
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 select 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. Select the Registry tab (this will
add the DllSurrogate named value under the AppID key). Provide a path to the
default surrogate as <..winntsystem32dllhost.exe>. 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:
#import “..DLLSurr.tlb” no_namespace named_guids
// This block of code assumes that you have already
// initialized COM libraries somewhere in your project.
// 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*/);
TRACE(“Failed to create ATest component.n”);
TRACE(e.ErrorMessage() + _bstr_t(“n”)); // Probably, the trace should
// be <Access is denied>!
TRACE(e.Description() + “n”);
// 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 and choose <Create Instance On…>.
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.
1. Inside Distributed COM, Guy Eddon and Henry Eddon, Microsoft Press 1998.
2. MSDN Library April