Pavel's Blog

Windows Media Foundation: Controlling Camera Properties

pavely — Sat, 19 May 2012 20:05:52 GMT

I have blogged about Media Foundation before; it’s the “next generation” of DirectShow, introduced in Windows Vista, enhanced in Windows 7 and further enhanced in Windows 8 (more on that in a future post). One of the tasks I encountered recently was to do a video capture from a camera. This is not too difficult to do (once you understand how Media Foundation works) and there’s even two sample in the SDK. But how do you control various camera properties, such as focus, zoom, white balance, etc.?

It turns out Media Foundation does not define any specific interfaces for these tasks. Curiously enough, it implements interfaces defined by its predecessor, DirectShow, on its media source (represented by the IMFMediaSource interface), when that media source is a video camera.

This means that all you need to do is use the usual COM QueryInterface on the media source to get to the relevant functionality, represented by (at least) two DirectShow-defined interfaces, IAMCameraControl and IAMVideoProcAmp. Here’s an example that sets some properties of a camera passed in as a media source:

 HRESULT CMFVideoCaptureDlg::SetupCamera(IMFMediaSource* pCameraSource) {
    CComQIPtr<IAMCameraControl> spCameraControl(pCameraSource);
    HRESULT hr = S_OK;
    if(spCameraControl) {
        long min, max, step, def, control;
        hr = spCameraControl->GetRange(CameraControl_Exposure, &min, &max, &step, &def, &control);
        if(SUCCEEDED(hr))
            hr = spCameraControl->Set(CameraControl_Exposure, 1, CameraControl_Flags_Manual);
    }
    CComQIPtr<IAMVideoProcAmp> spVideo(pCameraSource);
    if(spVideo)
        hr = spVideo->Set(VideoProcAmp_WhiteBalance, 0, VideoProcAmp_Flags_Auto);
    return hr;
}
 

The code uses ATL’s CComQIPtr<> smart pointer class to do the QueryInterface more compactly.

Note that any such modifications may fail, because some properties are not supported by the individual camera or the camera driver. If you know your camera supports some functionality for sure, your best bet is to update the driver. Sometimes a generic camera driver is not enough and the vendor-specific driver is required.

Windows 8: TopMost vs. TopMost

pavely — Wed, 16 May 2012 06:54:54 GMT

In Windows, a Window can be made topmost, by setting an extended style with the value WS_EX_TOPMOST (8), typically provided to CreateWindowEx. A topmost window is always on top of non-topmost windows. Among all topmost windows, the normal z-order rules apply. That is, until Windows 8.

A Metro application is built with a topmost window – that makes perfect sense. What about desktop apps? Here’s an empty desktop snapped with a metro app (the desktop itself can be seen as a kind of metro app):

Now let’s open Task Manager and make it topmost (Options / Always On Top). Slide it across the dividing snap bar and Task Manager is happy to be on top of the metro app:

Curiously, clicking on the metro app window does not make Task Manager any less topmost. Now let’s open Process Explorer and make it topmost as well (Options / Always On Top). Slide it over the metro app window, and this is the result:

It seems its topmost attribute is less powerful than Task Manager’s or the metro window! That’s certainly a surprise. It turns out Task Manager is “special” – I couldn’t find any other window that can stay on top of a metro app window – or on top of Task Manager for that matter.

Maybe Task Manager has a new “secret” style bit that makes it “super topmost”. Let’s open Spy++ and select Spy / Find Window from the menu:

Dragging the “Finder Tool” over Task Manager’s main window and clicking ok, shows this in the Styles tab:

The extended style is 0x108, which is WS_EX_TOPMOST | WS_EX_WINDOWEDGE – the latter being a minor appearance adjustment, irrelevant for our purposes. It looks like a regular WS_EX_TOPMOST. Let’s try the same with the Metro window.

Dragging the Finder Tool over the metro window “doesn’t stick” for some reason. Dragging Process Explorer’s equivalent tool manages to pinpoint the process to which this window belongs (WWAHost.exe, meaning that app was written in HTML/JS), but it doesn’t give out the window handle. So, how can we get the window handle of that metro app?

I decided to try calling the simple WindowFromPoint function, that I’m pretty sure Process Explorer uses as well (I was also sure Spy++ does that, though I can’t understand why it fails to see the window):

 POINT pt = { 40, 40 };
HWND h = ::WindowFromPoint(pt);
 

That worked. I got a handle and typed it into Spy++ handle text box. It turns out this window is a child window, so I navigated to its parent (that window’s name was “Store”) and finally to its parent with is the top level window. These are its properties:

The only extended style is WS_EX_TOPMOST. How about Process Explorer’s window?

Pretty much the same. So they all have the same extended style bit (WS_EX_TOPMOST), but Task Manager and the Metro window behave as “super topmost” in relation to other topmost windows. Task Manager’s window seems to be the strongest topmost ever. So far, I don’t know how that is configured.

WPF Tip: Attached properties and bindings

pavely — Sat, 12 May 2012 19:04:07 GMT

Attached properties are a great way to extend capabilities of existing elements without the need to derive or otherwise tinker with those elements. Suppose we create an attached property that is a collection of objects of some particular kind. When that property changes, those objects are read, and that special functionality is applied. Here’s a hypothetical example of such a scheme:

 public static class SomeHelper {
    public static DemoCollection GetData(DependencyObject obj) {
        return (DemoCollection)obj.GetValue(DataProperty);
    }
 
    public static void SetData(DependencyObject obj, DemoCollection value) {
        obj.SetValue(DataProperty, value);
    }
 
    public static readonly DependencyProperty DataProperty =
         DependencyProperty.RegisterAttached("Data", typeof(DemoCollection), typeof(SomeHelper), new UIPropertyMetadata(null, OnDataChanged));
 
    static void OnDataChanged(DependencyObject obj, DependencyPropertyChangedEventArgs e) {
        var coll = (DemoCollection)e.NewValue;
        // do something with collection
        foreach(var d in coll) {
            Trace.WriteLine(d.Text);
        }
    }
 
}
 
public class Demo : DependencyObject {
    public string Text {
        get { return (string)GetValue(TextProperty); }
        set { SetValue(TextProperty, value); }
    }
 
    public static readonly DependencyProperty TextProperty =
         DependencyProperty.Register("Text", typeof(string), typeof(Demo), new UIPropertyMetadata(string.Empty));
 
}
 
public class DemoCollection : List<Demo> {
}
 

To summarize: The SomeHelper class defines the Data property which is of type DemoCollection, which is a List of Demo objects. The reason DemoCollection is defined and the code doesn’t use List<Demo> directly, is because WPF’s XAML does not support generics at this time. For each Demo object within the collection, its property Text is printed using Trace.WriteLine. In a real application, this is where the special code would be.

Let’s use that in a simple scenario:

 <Grid>
    <local:SomeHelper.Data>
        <local:DemoCollection>
            <local:Demo Text="Hello" />
        </local:DemoCollection>
    </local:SomeHelper.Data>
</Grid>
 

The “local” XML prefix points to the namespace and assembly where the above types are defined. In this case, we should see “Hello” traced out to the Visual Studio debugger when running with the debugger. No surprise there.

Now suppose the value of the Text property is derived using data binding like so:

 <local:Demo Text="{Binding MyName}" />
 

This indicates that Text should be bound to the MyName property of the closest DataContext up the visual tree. Let’s set up the DataContext to be the current Window and MyName would be exposed through this window:

 public partial class MainWindow : Window {
    public MainWindow() {
        InitializeComponent();
 
        DataContext = this;
    }
 
    public string MyName {
        get { return "Cactus"; }
    }
}
 

When this is run, the expected output is “Cactus”. Surprisingly, the output is an empty string. The Visual Studio debugger outputs the following in the output window as a data binding error:

 System.Windows.Data Error: 2 : Cannot find governing FrameworkElement or FrameworkContentElement for target element. BindingExpression:Path=MyName; DataItem=null; target element is 'Demo' (HashCode=48380239); target property is 'Text' (type 'String')
 

It seems the DataContext didn’t “stick”: The message claims that DataItem=null, meaning there is no source for the binding, and so it fails.

If we try something even simpler, such as binding to a named element, such as the window itself with a well known property like this:

 <local:Demo Text="{Binding ActualWidth, ElementName=win}" />
 

(the window is named “win”). Again nothing appears, and the debugger output claims:

 System.Windows.Data Error: 2 : Cannot find governing FrameworkElement or FrameworkContentElement for target element. BindingExpression:Path=ActualWidth; DataItem=null; target element is 'Demo' (HashCode=63379435); target property is 'Text' (type 'String')
 

Same result. What’s going on? Can’t we use any binding in this case?

The problem is a bit subtle. A DataContext or any element for that matter cannot be found because there is no “WPF" parent” around. The Demo’s instance parent is the DemoCollection object, which knows nothing about WPF and so has no way of knowing who is its “parent” in the visual tree.

Are we doomed? Fortunately, there is a way to fix this. We need to work with an object that is more “WPF aware” than a simple List<>. The next best thing is FreezableCollection<T>. This can hold any object derived from DependencyObject, but Freezable is preferred, and in this case, required; Freezable is an interesting class in itself, but this is beyond the scope of this post and it doesn’t matter in this case. We don’t need the special aspects of Freezable, we just need its awareness of being part of the WPF world.

We need to make two changes. The first, in the collection:

 public class DemoCollection : FreezableCollection<Demo> {
}
 

The other is making sure or Demo class is indeed a Freezable:

 public class Demo : Freezable {
    public string Text {
        get { return (string)GetValue(TextProperty); }
        set { SetValue(TextProperty, value); }
    }
 
    public static readonly DependencyProperty TextProperty =
         DependencyProperty.Register("Text", typeof(string), typeof(Demo), new UIPropertyMetadata(string.Empty));
 
 
    protected override Freezable CreateInstanceCore() {
        throw new NotImplementedException();
    }
}
 

This forces us to implement the abstract CreateInstanceCore from Freezable, but that doesn’t matter in this case, because it will not be created by the Freezable cloning mechanism. In any case, implementing it is typically done by calling the new operator with the default constructor of the current type.

That’s it. Now binding works as expected in all scenarios.

Win32 and Metro–CreateFile(2)

pavely — Thu, 03 May 2012 10:05:31 GMT

When a new Windows version comes out, I’m always curious about the new Windows API (Win32) functions that are added to the release.

With Windows 8, things get a little more complicated, as there are desktop apps and there are metro apps. Now, for every Windows API function the documentation states whether this API is valid for desktop apps only or for desktop apps and metro apps.

One classic function is CreateFile. This is one of the oldest functions – exists since the very first Windows NT version. In Windows 8, it’s marked for desktop apps only. This may be understandable, as the Windows Runtime has other ways to use files, such as the StorageFile class. However, Windows 8 has a new function called CreateFile2. This one, in contrast to CreateFile, can be used in desktop and metro apps. Here’s its prototype:

 HANDLE WINAPI CreateFile2(
  _In_      LPCWSTR lpFileName,
  _In_      DWORD dwDesiredAccess,
  _In_      DWORD dwShareMode,
  _In_      DWORD dwCreationDisposition,
  _In_opt_  LPCREATEFILE2_EXTENDED_PARAMETERS pCreateExParams
);
 

Here’s the prototype of CreateFile:

 HANDLE WINAPI CreateFile(
  __in      LPCTSTR lpFileName,
  __in      DWORD dwDesiredAccess,
  __in      DWORD dwShareMode,
  __in_opt  LPSECURITY_ATTRIBUTES lpSecurityAttributes,
  __in      DWORD dwCreationDisposition,
  __in      DWORD dwFlagsAndAttributes,
  __in_opt  HANDLE hTemplateFile
);
 

The first four arguments of CreateFile2 exist in both CreateFile and CreateFile2. The new extended parameters structure of CreateFile2 simply packages the “missing” arguments into an single optional structure:

 typedef struct _CREATEFILE2_EXTENDED_PARAMETERS {
  DWORD                 dwSize;
  DWORD                 dwFileAttributes;
  DWORD                 dwFileFlags;
  DWORD                 dwSecurityQosFlags;
  LPSECURITY_ATTRIBUTES lpSecurityAttributes;
  HANDLE                hTemplateFile;
} CREATEFILE2_EXTENDED_PARAMETERS, *PCREATEFILE2_EXTENDED_PARAMETERS, *LPCREATEFILE2_EXTENDED_PARAMETERS;
 

This structure actually adds nothing to what CreateFile can specify. The dwFlagsAndAttributes of CreateFile is logically split to three groups of flags represented by dwFileAttributes, dwFileFlags and dwSecurityQosFlags in this structure for CreateFile2. Although the split is a good thing, it doesn’t explain why CreateFile is forbidden in metro style apps. Furthermore, the documentation for CreateFile2 states that in metro apps this function can only open files and directories (and not things like pipes, mailslots, consoles, etc.).

So why is CreateFile forbidden in metro apps? Perhaps it does allow opening something that CreateFile2 forbids?

I decided to try calling it from a metro app. Trying to just use CreateFile would not compile, as a set of #ifdef/#endif is placed inside the Windows headers to prevent compiling a forbidden API. This, however, can be circumvented easily. We can just create the correct prototype manually:

 extern "C" {
    HANDLE WINAPI CreateFileW(
        __in      LPCTSTR lpFileName,
        __in      DWORD dwDesiredAccess,
        __in      DWORD dwShareMode,
        __in_opt  LPSECURITY_ATTRIBUTES lpSecurityAttributes,
        __in      DWORD dwCreationDisposition,
        __in      DWORD dwFlagsAndAttributes,
        __in_opt  HANDLE hTemplateFile
    );
}
 

This is just the CreateFile declaration from the docs wrapped in an extern “C” declaration; this is important, otherwise the liker would complain of an unresolved external (trying to look for C++ linkage). Also, note the function is declared as CreateFileW (the Unicode version) and not simply CreateFile, as CreateFile is actually a macro, and would not have been found by the linker.

Let’s add a simple call to this CreateFileW in a blank C++ metro style application in the BlankWindow constructor:

 HANDLE h = ::CreateFileW(L"C:\\Users\\Pavel\\Documents\\test.txt", GENERIC_READ, FILE_SHARE_READ | FILE_SHARE_WRITE, nullptr, OPEN_EXISTING, 0, 0);
if(h == INVALID_HANDLE_VALUE) {
    auto err = ::GetLastError();
}
else
    ::CloseHandle(h);
 

This code tries to open a text file. This fails with error code 5 (access denied), as does CreateFile2. Although I set up the manifest with access to the documents library and set up a TXT file association, it refuses to work.

There doesn’t seem to be a noticeable difference between CreateFile and CreateFile2. I don’t understand at this time why CreateFile2 exists, apart from the convenience of that extra optional structure. There’s a room for further investigation, perhaps looking at NtDll.dll to see if these call different system services (unlikely, but worth a check).

WPF 4.5 Cookbook

pavely — Thu, 26 Apr 2012 16:40:44 GMT

A few months back, I was approached by Packt publishing, asking me to write a WPF book, in their “cookbook” style, and I accepted. I haven’t written an entire book before, but I have written dozen of courses for Hi-Tech College, John Bryce Training and now for CodeValue, in a range of topics, from Windows Internals and device driver development, to advanced C++, to basic and advanced .NET topics, to WPF, and even some oddities such as the Windows Media Foundation.

Writing a book, however, is different than writing a course, and I was at least curious whether I could produce something useful, given that WPF is not new and has already several decent books out there. So, what’s special about this book? First, it doesn’t target the absolute beginner, although I do cover most of WPF fundamentals in the first two chapters, but is more oriented towards the intermediate WPF developer, and sometimes a bit higher than that (or so I hope). Second, I do expect this “cookbook” style, where recipes to common problems are presented, followed by explanations and expansions, to feel a somewhat different experience, where dependencies among recipes are almost non-existent (and we all know dependencies are bad ).

And third, I ‘m reminded by an interview I read a few years back with Dino Esposito, who told the following story about himself: He was to give a session in a conference about COM (Component Object Model). Before that session started, he noticed Don Box (then the ultimate guru of COM) sitting down in the first row to listen. Dino walked up to him and asked why is he here? Surely, there’s nothing new Dino can teach Don Box about COM. Don Box replied, “It’s all about perspective”. Well, this is my perspective on WPF.

According to the publisher, the book must be around 300 pages. This is pretty low for WPF, as WPF is huge, so I had to cut down some topics, to make sure I’m covering the major WPF pillars. Eventually, I expect to be at around 350 pages.

The book includes 11 chapters, 6 of which I’ve already written (without incorporating technical reviewers’ comments):

1. Foundations

2. Resources

3. Layout and Panels

4. Using Standard Controls

5. Application and Windows

6. Data Binding

7. Commands and MVVM

8. Styles, Triggers & Templates

9. Graphics & Animation

10. Custom Elements

11. Threading

The expected publication date (if all goes well) is around August.

The book official page is at http://www.packtpub.com/windows-presentation-foundation-4-5-cookbook/book

Windows Devices UG Meeting Reminder: WinRT & Metro Apps

pavely — Tue, 17 Apr 2012 15:31:00 GMT

The Windows Devices user group managed by Elad Shaham and myself is meeting next Tuesday (the 24th) at Microsoft Offices in Ra’anana. We’ll have two sessions dedicated to Windows 8.

Full agenda and registration (free) is available at http://insidewindowsruntime.eventbrite.com/

See you there!

WPF 4.5: Markup Extension for Events

pavely — Sat, 07 Apr 2012 15:34:25 GMT

One of the new features coming in WPF 4.5 (already available through the Visual Studio 11 Beta and .NET 4.5 Beta) is the ability to create markup extensions that work on events (as opposed to properties, which have always had this capability).

Markup extensions for properties are crucial, and there are quite a few useful ones, such as {Binding} and {StaticResource}. Would this ability be useful for events?

One such case is when a command is needed to be invoked (ICommand) because of some event, typically found in MVVM scenarios. The problem is that only some events can actually trigger a command (out of the box) such as Click for ButtonBase and Click for MenuItem. What about other events? What about other elements that don’t implement ICommandSource and therefore have no Command property to connect to?

This is where a markup extension for events can come in handy. The solutions so far to this issue usually involved using the Interactivity assembly from the Expression Blend SDK, that provides actions, triggers and behaviors, one of which provides a way to invoke a command (InvokeCommandAction). We can try to do something similar using the new feature, which will not require the Blend SDK at all.

How to use it

Let’s look at the usage first. Consider a simple paining program the draws lines on a Canvas. We want to handle a mouse down, move and up events in the ViewModel (as opposed to the view). This decouples things, and provides command objects that can later be used to manage (e.g.) undo/redo features. Here’s how the Canvas markup should look like:

 <Canvas ClipToBounds="True" Background="White" 
        MouseLeftButtonDown="{local:EventToCommand StartPaintCommand}"
        MouseMove="{local:EventToCommand AddLineCommand}" 
                             MouseLeftButtonUp="{local:EventToCommand EndPaintCommand}">
</Canvas>
 

The markup extension constructor is interpreted as a property path to bind to (relative to the current DataContext). At first, it seems easier to add a Command property (of type ICommand) to the markup extension (and I did) , but it’s really useful; that’s because it’s not possible to provide a {Binding} expression as the value of that property. To do that we’d have to turn the Command property to a dependency property – but we can’t because MarkupExtension does not derive from DependencyObject

The solution I used was to declare a BindingCommandPath property (or via the constructor), that interprets the property path as a binding path (this is the most common scenario). A helper method digs into the property path and gets the actual value:

 static object ParsePropertyPath(object target, string path) {
    var props = path.Split('.');
    foreach(var prop in props) {
        target = target.GetType().GetProperty(prop).GetValue(target);
    }
    return target;
}
 

This little method does not support indexing, but that is not commonly used, and in any case wouldn’t be too hard to add.

Creating a markup extension

Writing a markup extension for events is fundamentally no different than writing it for properties. The first thing is to create a class deriving from MarkupExtension:

 public sealed class EventToCommandExtension : MarkupExtension {
 

The main thing to do is implement the abstract ProvideValue method. This should return something appropriate – in an event case, a delegate object appropriate for the event’s delegate type.

A command can receive a parameter – in this case it would probably want the sender and the RoutedEventArgs-derived type. For this a created a simple generic class:

 public sealed class EventCommandArgs<TEventArgs> where TEventArgs : RoutedEventArgs {
    public TEventArgs EventArgs { get; private set; }
    public object Sender { get; private set; }
 
    public EventCommandArgs(object sender, TEventArgs args) {
        Sender = sender;
        EventArgs = args;
    }
}
 

Now for the main event: overriding ProvideValue. Here we need to return an alternative (our own) handler, that will invoke the required command. First, let’s get the service that provides some context for the markup extension usage:

 public override object ProvideValue(IServiceProvider sp) {
    var pvt = sp.GetService(typeof(IProvideValueTarget)) as IProvideValueTarget;
 

Now we can examine the TargetProperty property to get the actual event object. Curiously enough, it’s sometimes an EventInfo (which is expected), but sometimes it’s a MethodInfo. So we need to deal with the difference and eventually connect to our own handler, called DoAction:

 if(pvt != null) {
    var evt = pvt.TargetProperty as EventInfo;
    var doAction = GetType().GetMethod("DoAction", BindingFlags.NonPublic | BindingFlags.Instance);
    Type dlgType = null; 
    if(evt != null) {
        dlgType = evt.EventHandlerType;
    }
    var mi = pvt.TargetProperty as MethodInfo;
    if(mi != null) {
        dlgType = mi.GetParameters()[1].ParameterType;
    }
    if(dlgType != null) {
        _eventArgsType = dlgType.GetMethod("Invoke").GetParameters()[1].ParameterType;
        return Delegate.CreateDelegate(dlgType, this, doAction);
    }
}
 

The trick is to create the exact delegate type (it’s RoutedEventHandler or something more specific – we need that specificity to make the command implementor itself simpler and type safe; more on that in a moment. That’s why we create the delegate dynamically with Delegate.CreateDelegate.

In our DoAction method, we need to invoke the connected command correctly:

 void DoAction(object sender, RoutedEventArgs e) {
    var dc = (sender as FrameworkElement).DataContext;
    if(BindingCommandPath != null) {
        Command = (ICommand)ParsePropertyPath(dc, BindingCommandPath);
    }
    Type eventArgsType = typeof(EventCommandArgs<>).MakeGenericType(_eventArgsType);
    var cmdParams = Activator.CreateInstance(eventArgsType, sender, e);
    if(Command != null && Command.CanExecute(cmdParams))
        Command.Execute(cmdParams);
}
 

Again, because we don’t know in advance what kind of EventArgs are actually used by that particular event, we create the EventCommandArgs generic type dynamically, by first creaing the “open” type (with no specific generic parameter) and then calling MakeGenericType to make it a creatable “closed” type. Then we call ICommand.Execute if ICommand.CanExecute returns true.

Implementing the commands

The PaintingViewModel class implements the three commands shown above. Here’s the command to start painting:

 bool _isPainting;
ICommand _startPaintCommand;
public ICommand StartPaintCommand {
    get {
        return _startPaintCommand ?? (_startPaintCommand = new RelayCommand<EventCommandArgs<MouseButtonEventArgs>>(args => {
            var element = args.Sender as IInputElement;
            _lastPoint = args.EventArgs.GetPosition(element);
            element.CaptureMouse();
            _isPainting = true;
        }));
    }
}
 

RelayCommand<> is the typical command used in MVVM scenarios (look at the source code). It’s sometimes called DelegateCommand (available in Prism, but they’re similar).

Here’s the command bound to a mouse move event:

 ICommand _addLineCommand;
public ICommand AddLineCommand {
    get {
        return _addLineCommand ?? (_addLineCommand = new RelayCommand<EventCommandArgs<MouseEventArgs>>(args => {
            var element = args.Sender as IInputElement;
            var pt = args.EventArgs.GetPosition(element);
            Model.AddLine(_lastPoint, pt);
            _lastPoint = pt;
        }, args => _isPainting
        ));
    }
}
 

The Model property is of type Paining that holds a collection of LineInfo objects. Again, look at the source.

Here’s a view at runtime:

Paining Program demo

What’s New in CLR 4.5 Debugging API?

pavely — Tue, 03 Apr 2012 16:51:39 GMT

The most used command in the SOS extension DLL is probably !dumpheap. This command is able to show every object on the managed heap. This capability has no match within Visual Studio. The reason is that Visual Studio uses the CLR debugging API, that doesn’t seem to have this capability.

At first glance, the ICorDebugProcess interface has the perfect method: EnumerateObjects. What could be better than that? Unfortunately, the documentation states that this method is not implemented… bummer.

A while back I created a project CLR Explorer. This was supposed to be a tool to look at managed processes. Looking at metadata was easy enough, but runtime information was scarce, as the debug interfaces did not have a way to get managed heap information.

With .NET 4.5. beta released, I looked through the debug interfaces. I wanted to see if anything changed since CLR 4. I discovered there is a new interface supposedly supported on a CorDebugProcess object, ICorDebugProcess5. This new interface (the previous one was ICorDebugProcess3 – clearly the number 4 was to be avoided to not give the false impression that this is available with CLR 4).

This new interface has a method named EnumerateHeap – great! finally… and the method seems to be documented as having an actual implementation.

So, I decided to give it a try…

Attaching to a Process

Warning! C++ (and COM) ahead!

First, let’s get the CLR meta host object:

 CComPtr<ICLRMetaHost> spMetaHost;
hr = ::CLRCreateInstance(CLSID_CLRMetaHost, __uuidof(ICLRMetaHost), (void**)&spMetaHost);
 

This object is the root for starting to work with the CLR (debugging or not). It was introduced in CLR 4.

We need to get the ICorDebug interface. This is how it’s done (hProcess is a handle to the process we want to attach to – obtained using the usual OpenProcess API):

 CComPtr<IEnumUnknown> spEnumUnk;
spMetaHost->EnumerateLoadedRuntimes(hProcess, &spEnumUnk);
CComPtr<IUnknown> unk;
spEnumUnk->Next(1, &unk, NULL);
CComQIPtr<ICLRRuntimeInfo> spInfo(unk);
ATLASSERT(spInfo);
CComPtr<ICorDebug> spDebug;
spInfo->GetInterface(CLSID_CLRDebuggingLegacy, __uuidof(ICorDebug), (void**)&spDebug);
 

(Error handling is mostly non existing to keep the code short)

Now we need to initialize the ICorDebug object and attach to the process to debug:

 hr = spDebug->Initialize();
CComObject<CDebugManagedCallback>* pHandler;
pHandler->CreateInstance(&pHandler);
spDebug->SetManagedHandler(pHandler);
 
CComPtr<ICorDebugProcess> spProcess;
hr = spDebug->DebugActiveProcess(pid, FALSE, &spProcess);
 

The CDebugManagedCallback class is a local C++ COM class that is the handler for debugging events. I will not show this one here (you can check out the CLR Explorer project to see one such class in action). For the purpose of this post, it really is just there so ICorDebug would be happy.

Now for the fun part. Can we get an ICorDebugProcess5? If we can, let’s use it:

 CComQIPtr<ICorDebugProcess5> spProcess5(spProcess);
if(spProcess5) {
    COR_HEAPINFO heapInfo;
    hr = spProcess->Stop(0);
    hr = spProcess5->GetGCHeapInformation(&heapInfo);
    cout << "GC Type: " << (heapInfo.gcType == CorDebugWorkstationGC ? "Workstation" : "Server") << endl;
    cout << "Heaps: " << heapInfo.numHeaps << endl;
    if(heapInfo.areGCStructuresValid) {
        CComPtr<ICorDebugHeapEnum> spEnumHeap;
        hr = spProcess5->EnumerateHeap(&spEnumHeap);
        ULONG count;
        hr = spEnumHeap->GetCount(&count);
        if(SUCCEEDED(hr)) {
            // unfortunately... hr = E_NOTIMPL
            cout << "# Objects: " << count << endl;
        }
        COR_HEAPOBJECT obj;
        hr = spEnumHeap->Next(1, &obj, nullptr);    // works!
        CComPtr<ICorDebugType> spType;
        spProcess5->GetTypeForTypeID(obj.type, &spType);
        if(spType) {
            CorElementType type;
            spType->GetType(&type);
            cout << type << endl;
        }
    }
}
 

The ICorDebugProcess5::GetGCHeapInformation gets some basic info for the heap. Then we can enumerate the objects on the managed heap. The GetCount method on the enumeration interface is not implemented, which makes perfect sense, since this information is unknown to the CLR, would be expensive to keep track of, and adds no real value.

The Next method however, works! Now we can enumerate the heap!

A new version of CLR Explorer is certainly due!

My Async Programming with C# 5.0 & .NET 4.5 session is available for viewing

pavely — Wed, 28 Mar 2012 20:26:33 GMT

The session I gave at Microsoft Ra’anana two days is available on channel 9. This was in Hebrew, so if this is not your native tongue, you can probably still enjoy the code demos. Here are the links:

Part 1

Part 2

Enjoy!

Asynchronous Programming with C# 5.0 & .NET 4.5 Session

pavely — Mon, 26 Mar 2012 11:38:52 GMT

This morning I gave a session on asynchronous programming with C# 5.0 at Microsoft offices in Ra’anana. Thank you all for attending, it was great fun!

As promised, the presentation slides and demos are attached below (the Windows 8 demos can naturally be run on Windows 8 only).

The session was recorded, so if you missed it, or just want to hear the same jokes again, the recording will be available in a few days – check out the MSDN blog for details of availability.

Async Demos

Async Metro Demo

Presentation Slides

INotifyPropertyChanged implementation with C# 5.0

pavely — Tue, 20 Mar 2012 20:40:30 GMT

The INotifyPropertyChanged interface has become a very popular interface, typically used in MVVM scenarios (WPF/Silverlight). It looks simple, with a single member, which is an event, and its basic implementation by some data type may be something like this: class Book : INotifyPropertyChanged { public event PropertyChangedEventHandler PropertyChanged; protected virtual void OnPropertyChanged( string propName) { var pc = PropertyChanged; if (pc != null ) pc( this , new PropertyChangedEventArgs (propName...(read more)

What happened to asynchrony with WebClient in .NET 4.5?

pavely — Sat, 17 Mar 2012 14:01:13 GMT

In the Visual Studio 2010 Async CTP , a bunch of extension methods have been added to the WebClient class, to facilitate the “awaiting” of C# 5.0, such as DownloadStringTaskAsync , which can be simply used like so: var wc = new WebClient (); string result = await wc.DownloadStringTaskAsync( "http://msdn.microsoft.com" ); One of the overloads present in the CTP accepts a CancellationToken , so that the operation could be cancelled by an external CancellationTokenSource . For example: async...(read more)

Presentations I’ll be giving this month

pavely — Tue, 13 Mar 2012 21:03:00 GMT

This month turned out to be a busy one for me, at least as far as public presentations are concerned. All sessions are free of charge, but you should register – details follow: Parallel and Asynchronous Programming with .NET 4/4.5 and C# 5.0 This session is to be held on the 20th, at John Bryce offices in Tel Aviv. I will do a quick recap of tasks and the Parallel class, and then move to async programming with and without the new C# 5.0 features. I will be using VS 2010 and the recently released...(read more)

Static vs. Instance (vs. Extension)

pavely — Thu, 08 Mar 2012 23:01:11 GMT

Sometimes I teach a basic .NET & C# course. Among many other things, I discuss arrays. I mention that all .NET arrays derive from System.Array , and so get some functionality for free, such as sorting. Here’s a simple array: int [] a = new int [10]; Now, the inexperienced student may type “a.”, opening the intellisense list box, and look for a method named Sort – after all, the instructor (me) said arrays support such an operation. The confused student can’t find any such method. Of course the...(read more)

Visual Studio 11 Beta–First Impressions

pavely — Fri, 02 Mar 2012 08:37:49 GMT

Visual Studio 11 Beta is out (along with Windows 8 Beta), so naturally, I installed it right away (I did create a restore point just in case…). I wanted to get some first impressions of VS 11, and this is the result. Installation Installing VS 11 was easier than ever, because there were no choices at all – just install and be done with it. No way to remove unneeded components. I don’t know if this is going to be the final install experience, but this is certainly new. I’m still not sure this is entirely...(read more)