Hosting a .NET DLL as an Out-Of-Process COM Server (EXE)

Tuesday, January 7, 2014

I recently came across the need of hosting a .NET assembly (DLL) as an out-of-process COM server. While .NET ships with excellent support for COM interoperability, this particular scenario isn't directly addressed by the interop layer. While there are some fairly complex solutions such as COM+ hosting or custom class factory registration, I would like to show you how to accomplish this task using dllhost.exe, the default COM surrogate process, with just a handful of registry modifications. Why? The reason I was looking into doing this is quite simple. Suppose you have a 32-bit only unmanaged DLL that you can't recompile...
tags: , ,

Back To Basics: COM Interop and No-PIA

Saturday, December 28, 2013

Almost every week, I meet developers who hate COM. Some hate it with the heat of a million suns. Some have never used it, but heard horror stories from grey-haired colleagues. Other survivors still remember their experience fighting ATL linker errors in Visual C++ 6.0. And you know what, you can hate COM all you want. But it's a little like hating electricity. Or the Internet. Because -- on Windows -- COM powers almost everything. Office. The Windows Shell. This beautiful cozy Windows Runtime APIs that you're enjoying from JavaScript and C#. And did you know that the .NET...
tags: , ,

Diagnosing Memory Leaks in Managed Windows Store Apps

Monday, October 15, 2012

There is so much material on the web (and even on this blog) about memory leak diagnostics in managed code, and a considerable number of tools that make diagnostics increasingly easier. Modern memory profilers can open application dumps, attach to live processes, display live memory graphs, compare snapshots, identify problematic retention patterns, and so much more. Unfortunately, these tools presently don’t work with Windows Store apps. Moreover, the UI model of Windows Store apps poses a significant challenge in diagnosing many UI-related memory leaks, such as composite UI controls retaining objects embedded in them, or UI elements retaining...

Under the Covers of WinRT Using C++

Saturday, September 17, 2011

The WinRT type system relies strongly on WinRT components, which are COM objects implementing a specific set of interfaces and adhering to a certain ABI (Application Binary Interface). We will examine here this ABI and how C++ compiler extensions help reference that ABI without exposing the nitty-gritty details of dealing with COM interfaces and COM activation. A WinRT component implements the IInspectable interface, which derives from IUnknown (however, WinRT components do not have dual interfaces, i.e. they do not implement IDispatch). The IInspectable interface contains three methods: GetIids, which returns the interfaces implemented by the component; GetRuntimeClassName, which...

Detecting the STA Thread from GetToSTA

Sunday, August 15, 2010

When a thread makes a method call through an appropriately marshaled COM proxy that points to a thread in a different STA (Single-Threaded Apartment), ole32.dll kicks in and implements the minute details of marshaling input parameters across the required boundary, waiting for the call to return, and unmarshaling the return value and output parameters. In a debugger, a thread making a COM call to another STA will have a native call stack similar to the following: 0:002> kb ChildEBP RetAddr  Args to Child               ... ntdll!ZwWaitForSingleObject+0x15 ... KERNELBASE!WaitForSingleObjectEx+0x98 ...
tags: ,
one comment

STA Objects and the Finalizer Thread: Tale of a Deadlock

Wednesday, June 30, 2010

Here’s a non-trivial deadlock that manifests from using a non-pumping wait API and a finalizer. It is another example of why finalizers are a dangerous cleanup mechanism and why you should avoid them at all costs. Let’s say that you have an STA COM object called NativeComObject that your managed application is using, and you wrap the COM object with a class called FinalizableResource. This latter class has a finalizer that cleans up resources associated with the COM object by calling a cleanup method on it, or even by deterministically releasing the object with Marshal.FinalReleaseComObject. Note that...
one comment