Насколько мне известно (впрочем, за 100% достоверность не ручаюсь) - нет, в этом случае данные не выходят за область памяти процесса.
In-proc сервера загружаются в АП клиента и LRPC там не используется. LPRC используется при out-of-process, для передачи данных между двумя процессами на одной машине (RPC, соответственно, используется при разных машинах). Загружаемый в АП клиента DLL-сервер взаимодействует с клиентской программой напрямую, при этом может никаких функций для взаимодействия и не экспортировать (экспортируются только служебные функции типа DllGetClassObject). Системные механизмы подключаются только при установлении соединения с сервером и получения ссылки на интерфейсы.
Не все так просто. Если in-proc COM object вызывается из другого апартмента то применятся inter-thread marshaling.
Да, если работа с com идет из другого потока то применяется маршалинг, задействуеца scm, oleaut (для стандартного маршалинг предоставляемого ОС) и по всей видимости данные уходят из процесса
Например, если создать singlethreaded COM object из multithreaded apartment'a, то вызовы к такому объекту будут маршалиться также как между процессами, несмотря на то, что и клиент и сервер живут в одном процессе. http://msdn.microsoft.com/en-us/library/windows/desktop/ms693344(v=vs.85).aspx
Все обсуждения описано сдесь: http://msdn.microsoft.com/en-us/library/windows/desktop/ms687205%28v=vs.85%29.aspx Но также не стоит забывать с чего будет вызван COM. Если с дотнета, то конечно прямого обращения мы не увидим, данные все равно будут упаковыватся, но сдругой стороны смотя чем оперировать. Если указателями то наклодных расходов не будет видно, а вот если передовать данные , то будут и причем весьма не плохие.
