Worker Process Remoting

What is Worker Process Remoting?

For Visual Studio 2019, Concord was extended to be able to load additional components outside of the IDE process. This technology is named Worker Process Remoting. Worker Process Remoting allows Concord components which previously had to be loaded into the IDE process (devenv.exe) to now be loaded in a separate 64-bit process. This allows these components to take advantage of the additional virtual and physical memory resources that the computer has instead of being constrained to the 4 gigabytes of shared address space that the devenv.exe process is constrained to. The primary use of Worker Process Remoting is to load components that make significant use of C/C++ symbols, such as the C++ symbol provider, and the C++ expression evaluator, into a separate process.

Worker Process Remoting is just for IDE-side components, that is components with a component level which is larger than 100,000. It builds off the 'standard' remoting support that Concord has had since the beginning, but it lifts some of the restrictions that regular remoting has. For example, in regular remoting, many Dkm objects (ex: DkmProcess) intentionally cannot be created in one remote debugger process and marshalled to another remote debugger process.

The main class for worker process remoting in the Concord API is Microsoft.VisualStudio.Debugger.DefaultPort.DkmWorkerProcessConnection.

How to configure a component to run in a worker process

If you own a component, and you want to have it start loading in a worker process you need to take a few steps:

1: Set WorkerProcessSupported="true" in your .vsdconfigxml file. Example:

<Class Name="CMyNativeClass" ClassId="{504A0631-514F-4EB8-AFA5-C7F682F895F7}" WorkerProcessSupported="true">
  <Implements>
    <InterfaceGroup>

Note that this requires building with the Visual Studio 2019 (VS 16) version of vsdconfigtool.exe. The resulting .vsdconfig file can still be loaded in older version of Visual Studio. See the Obtaining the Concord API headers, libraries, etc wiki page for more information.

2: If necessary - split your class up

Concord doesn't allow all IDE side interfaces to be implemented in worker processes. If step 1 resulted in errors from the VSDConfigTool about implementing interfaces which aren't supported in worker processes you will need to refactor your class into multiple classes - one class which is loaded into the worker process, and another class which will always load into the IDE. These classes can communicate with each other (or other code running in VS) using custom messages (DkmCustomMessage).

In addition to implementing IDE-only interfaces, there are also a few other cases where this refactoring may be necessary:

• If your component consumes APIs that are only callable from the IDE process. An example of such an API is DkmMainVsThread.Invoke. APIs will generally fail with code E_XAPI_METHOD_UNAVAIL_IN_WORKER_PROCESS.
• If you need to immediately be notified of events (implement a 'IDkm*Received' or 'IDkm*Notification' interfaces). Unlike in the IDE, events that originate in the IDE (or monitor) will not be immediately dispatched to the worker process but rather this notification is deferred until the next call between the IDE and the worker process.

3: If your component is implemented in native C++, you need to make sure that your extension includes both an x86 and an x64 implementation of your component, and any of its dependencies. It is important to have an x64 implementation because worker processes always run as an x64 process (even when an x86 process is being debugged). It is important to have an x86 in case the user has worker process remoting disabled (such as when the user is on a non-x64 OS). See here for more information.

Debugging

See Tips for debugging extensions for information about debugging extensions loaded into worker processes.