Archive
How to create and use a Custom COM Marshaler in .NET
Microsoft has done a nice job when it designed Component Object Model, also known as COM, even if the system’s complexity was painful for some developers. To fix that, they first created Vb6 (well…no comment) to soften the burden of consuming COM objects, while C++ was still a little bit rough to use (but anything concerning COM was possible !). After a few years, they finally created the .NET framework. As a fair part of the Windows architecture was based on COM and COM+, they had to make the most popular language (C# and VB.NET) of the platform compatible with it. I’m currently working on a system where the .NET code use a lot of COM to communicate with other parts of the system, and I can tell you that even most of the features of COM can be used, sometimes you have to dig deeper to make .NET component compatible with other languages. I saw a few custom marshaler described on the net, but no one done to marshal an array of “anything” (called VARIANT in COM), so I thought it could be interesting to share it with others.
How to always have the local variables values in a .NET callstack
Maybe you already had this kind of details while using the ‘!clrstack‘ command from the SOS debugging extension. And by the rules of the Murphy’s Law, it always happens specifically on the local variable that you really need to see in order to slash the bug you’re working on.
This <no data> stuff can be seen especially in release compilation because the Jitter will use all the optimization tricks it can, among which you can find inlining and massive use of registry for temporary variables, so reading local variables is almost impossible (remember C++ hum ?). Hopefully the CLR offer a simple way to disable any kind of optimization (beware, doing this have a major impact on performances!).
How to break on the ‘Main’ function with the .NET CLR 4.0 and WinDbg
If you ever tried to write a post on a technical blog, maybe you already experienced a strange thing: start with the idea of an article, and ends up with a totally different one. This is definitely the case of this one, as I just tried to have a decent local variable value in a call to the famous “!clrstack” function of the Windbg extension SOS, and I had a lot of trouble trying to break on the main function.
Most internet resources (even the help documentation of SOS itself !) advise the user to subscribe to the CLR load notification, and then load SOS and setup a deferred breakpoint. Well I don’t have any CLR load notification on my computer (Windows 7, and I tried x86/x64 applications targeting 4.0, 3.5 and 2.0), and I remembered experiencing the same behavior on my computer at work. As I’m not the only one having this issue (check this), I decided to write a short post about it.
BugSlasher 