System.Windows.Markup.XamlParseException occurred
  HResult=-2146233087
  LineNumber=8
  LinePosition=32
  Message='Provide value on 'System.Windows.Baml2006.TypeConverterMarkupExtension' threw an exception.' Line number '8' and line position '32'.
  Source=PresentationFramework
  StackTrace:
       at System.Windows.Markup.WpfXamlLoader.Load(XamlReader xamlReader, IXamlObjectWriterFactory writerFactory, Boolean skipJournaledProperties, Object rootObject, XamlObjectWriterSettings settings, Uri baseUri)
       at System.Windows.Markup.WpfXamlLoader.LoadDeferredContent(XamlReader xamlReader, IXamlObjectWriterFactory writerFactory, Boolean skipJournaledProperties, Object rootObject, XamlObjectWriterSettings parentSettings, Uri baseUri)
       at System.Windows.ResourceDictionary.CreateObject(KeyRecord key)
       at System.Windows.ResourceDictionary.OnGettingValue(Object key, Object& value, Boolean& canCache)
       at System.Windows.ResourceDictionary.OnGettingValuePrivate(Object key, Object& value, Boolean& canCache)
       at System.Windows.ResourceDictionary.GetValueWithoutLock(Object key, Boolean& canCache)
       at System.Windows.ResourceDictionary.GetValue(Object key, Boolean& canCache)
       at System.Windows.DeferredThemeResourceReference.GetValue(BaseValueSourceInternal valueSource)
       at System.Windows.DependencyObject.GetEffectiveValue(EntryIndex entryIndex, DependencyProperty dp, RequestFlags requests)
       at System.Windows.DependencyObject.GetValueEntry(EntryIndex entryIndex, DependencyProperty dp, PropertyMetadata metadata, RequestFlags requests)
       at System.Windows.DependencyObject.GetValue(DependencyProperty dp)
       at System.Windows.StyleHelper.GetChildValueHelper(UncommonField`1 dataField, ItemStructList`1& valueLookupList, DependencyProperty dp, DependencyObject container, FrameworkObject child, Int32 childIndex, Boolean styleLookup, EffectiveValueEntry& entry, ValueLookupType& sourceType, FrameworkElementFactory templateRoot)
       at System.Windows.StyleHelper.GetChildValue(UncommonField`1 dataField, DependencyObject container, Int32 childIndex, FrameworkObject child, DependencyProperty dp, FrugalStructList`1& childRecordFromChildIndex, EffectiveValueEntry& entry, ValueLookupType& sourceType, FrameworkElementFactory templateRoot)
       at System.Windows.StyleHelper.GetValueFromTemplatedParent(DependencyObject container, Int32 childIndex, FrameworkObject child, DependencyProperty dp, FrugalStructList`1& childRecordFromChildIndex, FrameworkElementFactory templateRoot, EffectiveValueEntry& entry)
       at System.Windows.StyleHelper.ApplyTemplatedParentValue(DependencyObject container, FrameworkObject child, Int32 childIndex, FrugalStructList`1& childRecordFromChildIndex, DependencyProperty dp, FrameworkElementFactory templateRoot)
       at System.Windows.StyleHelper.InvalidatePropertiesOnTemplateNode(DependencyObject container, FrameworkObject child, Int32 childIndex, FrugalStructList`1& childRecordFromChildIndex, Boolean isDetach, FrameworkElementFactory templateRoot)
       at System.Windows.FrameworkTemplate.InvalidatePropertiesOnTemplate(DependencyObject container, Object currentObject)
       at System.Windows.FrameworkTemplate.HandleBeforeProperties(Object createdObject, DependencyObject& rootObject, DependencyObject container, FrameworkElement feContainer, INameScope nameScope)
       at System.Windows.FrameworkTemplate.<>c__DisplayClass0.<LoadOptimizedTemplateContent>b__5(Object sender, XamlObjectEventArgs args)
       at System.Xaml.XamlObjectWriter.OnBeforeProperties(Object value)
       at System.Xaml.XamlObjectWriter.Logic_CreateAndAssignToParentStart(ObjectWriterContext ctx)
       at System.Xaml.XamlObjectWriter.WriteStartMember(XamlMember property)
       at System.Xaml.XamlWriter.WriteNode(XamlReader reader)
       at System.Windows.FrameworkTemplate.LoadTemplateXaml(XamlReader templateReader, XamlObjectWriter currentWriter)
  InnerException:
       HResult=-2146232800
       Message=Cannot locate resource 'resourcelibrary;v1.0.5703.26795;themes/resourcelibrary;component/sadface.jpg'.
       Source=PresentationFramework
       StackTrace:
            at MS.Internal.AppModel.ResourcePart.GetStreamCore(FileMode mode, FileAccess access)
            at System.IO.Packaging.PackagePart.GetStream(FileMode mode, FileAccess access)
            at System.IO.Packaging.PackWebResponse.CachedResponse.GetResponseStream()
            at System.IO.Packaging.PackWebResponse.GetResponseStream()
            at System.IO.Packaging.PackWebResponse.get_ContentType()
            at System.Windows.Media.Imaging.BitmapDecoder.SetupDecoderFromUriOrStream(Uri uri, Stream stream, BitmapCacheOption cacheOption, Guid& clsId, Boolean& isOriginalWritable, Stream& uriStream, UnmanagedMemoryStream& unmanagedMemoryStream, SafeFileHandle& safeFilehandle)
            at System.Windows.Media.Imaging.BitmapDecoder.CreateFromUriOrStream(Uri baseUri, Uri uri, Stream stream, BitmapCreateOptions createOptions, BitmapCacheOption cacheOption, RequestCachePolicy uriCachePolicy, Boolean insertInDecoderCache)
            at System.Windows.Media.Imaging.BitmapFrame.CreateFromUriOrStream(Uri baseUri, Uri uri, Stream stream, BitmapCreateOptions createOptions, BitmapCacheOption cacheOption, RequestCachePolicy uriCachePolicy)
            at System.Windows.Media.ImageSourceConverter.ConvertFrom(ITypeDescriptorContext context, CultureInfo culture, Object value)
            at System.Windows.Baml2006.TypeConverterMarkupExtension.ProvideValue(IServiceProvider serviceProvider)
            at MS.Internal.Xaml.Runtime.ClrObjectRuntime.CallProvideValue(MarkupExtension me, IServiceProvider serviceProvider)
       InnerException:

This same application, when run outside of the debugger runs without issue.

A bit of debugging turned up that the environment block of the application when run under the debugger has an extra environment variable set:

     ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO=1

With that discovery I was able to set this environment variable outside of the debugger and also reproduce the issue, verifying it as the root cause.

A bit of online research on this turned up this article - blogs.msdn.com/b/wpf/archive/2015/02/24/expanding-wpf-for-ui-debugging.aspx indicating this is a new feature of the WPF framework for .NET 4.6.

I was able to further determine that this can be turned on and off in the debugger from the Tools menu, Options, Debugging, 'Enable UI Debugging Tools for XAML' property, allowing an straight-forward work around for the exception.

After reporting this to WPF product team they verified it is a bug in WPF and is under consideration for a fix in an future .NET hotfix rollup

The Microsoft User Interface Automation (UIA) framework is great for helping automate testing and provide accessibility services for applications generally, but there are some cases where it may be disadvantageous for a client with very deeply nested UI components, since UIA requests can become taxing under those circumstances, degrading performance particularly.  This may even inadvertently happen to an application, which has no intentional awareness of UIA features, but which simply derives from the default features exposed within another framework, for example, the Windows Presentation Framework (WPF), which incorporates UIA features into every control by default.  In this case, an application with deeply nested UI components (such as a large TreeView, or DataGrid) might expose thousands of elements to UIA, without even being aware.  If such an application is run in an environment where another application is making frequent or numerous UIA requests, then those requests, which might normally be very quickly processed, can become burdensome.  Examples of such scenarios could be remote desktop sharing applications, narration or accessibility applications, testing frameworks, or any other application that might make UIA requests, ultimately answered from the process space of the unwary WPF developer, who may only recognize that when running in a particular scenario, his application performance begins to suffer significant degradation.

Potential alternate causes for similar but unrelated behavior

It should be noted that there are several known issues in .NET 3.5 and 4.0, wherein WPF’s implementation walks the visual tree unnecessarily in some cases, causing further performance hits.  The fix for .NET 4.0 was included with the .NET 4.5 distribution, and when 4.5 is installed on a client, the 4.0 binaries are also affected (being one in the same for both versions of the framework).  For prior releases, the fixes are available through the following KB articles:

2591373:  FIX: A .NET Framework 3-based WPF application stops responding if you right-click a control to open a pop-up control
2484841:  FIX: A .NET Framework 4.0 WPF application becomes unresponsive if used with MSAA or UIA client applications

For these scenarios, one may directly distinguish these performance issues from the ones addressed by the workaround suggested in this sample, through observing the following call stacks when inspecting the process in a debugger during its poorly performing state (or by debugging hang dumps captured of the process memory in that state).  The issues addressed in the above fixes will exhibit the following characteristic call stacks, of deeply nested calls to InvalidateAutomationAncestors():

PresentationCore_ni!MS.Internal.UIElementHelper.InvalidateAutomationAncestors(System.Windows.DependencyObject)+0xcf
PresentationCore_ni!MS.Internal.UIElementHelper.InvalidateAutomationAncestors(System.Windows.DependencyObject)+0xcf
PresentationCore_ni!MS.Internal.UIElementHelper.InvalidateAutomationAncestors(System.Windows.DependencyObject)+0xcf
PresentationCore_ni!MS.Internal.UIElementHelper.InvalidateAutomationAncestors(System.Windows.DependencyObject)+0xcf
PresentationCore_ni!MS.Internal.UIElementHelper.InvalidateAutomationAncestors(System.Windows.DependencyObject)+0xcf
PresentationCore_ni!MS.Internal.UIElementHelper.InvalidateAutomationAncestors(System.Windows.DependencyObject)+0xcf
PresentationCore_ni!MS.Internal.UIElementHelper.InvalidateAutomationAncestors(System.Windows.DependencyObject)+0xcf
PresentationCore_ni!MS.Internal.UIElementHelper.InvalidateAutomationAncestors(System.Windows.DependencyObject)+0xcf

A call stack more characteristic to the issue described and addressed in this post might show a deeply nested series of calls into UpdateLayout() or UpdateSubtree() functions instead, and are not due to any outstanding known issues within the WPF framework itself, but are sometimes an inevitable consequence of implementing a broad UI accessibility framework, and then running UIA clients, some of which may expose the framework to heavy load under some circumstances.  Assuming the above known issues are not involved then, the application developer caught in such a circumstance – wherein some external UIA client is unnecessarily generating excessive hits against the automation tree – may implement an easy workaround to avoid the issue. 

The workaround is that one may simply override the default AutomationPeer exposed by some top level control, under which were many other descendants generating heavy UIA activity by some UIA client or another, and for which he does not actually require exposure to that UIA client.  Instead of returning all of the UI children of the control from its AutomationPeer (as WPF does by default), one may return a null collection, and in doing so, short circuit UIA from that portion of the tree.  If automation must continue to work for some few particular node(s) from the underlying controls, we can even return just a specific node, or any other combination of nodes, with any degree of sophistication required to meet automation requirements. 

WARNING:

The developer employing this approach must be aware that he is breaking the default automation tree intentionally, an act which eliminates the performance overhead of traversing a large and complex control tree, but which also destroys the ability of automation to reach those exposed controls, unless they are explicitly exposed through his custom implementation. 

For example, narration would not work for any controls that were eliminated from the tree, nor would they be accessible to automation tests themselves, without being included.  To witness this limitation, just run the sample, and then use the Narrator in Windows, clicking on a few of the nodes in the tree to experiment.  You will find that the nodes we did not expose through our custom AutomationPeer are not narrated, while the one we did expose is still narrated.  But the top level item using the default AutomationPeer narrates any node of the tree selected from its descendants.  In many cases, this constraint is perfectly acceptable, but a developer using the approach should be aware of it before he considers a change that could potentially break his code for some users or scenarios.

With all of that explanation and forewarning out of the way, on to the fun part!

How to Implement the Workaround

We create a TreeViewItemWithCustomAutomationPeer just as we do a normal TreeViewItem (where local: corresponds to the local namespace of our project as provided in an xmlns declaration at the top of the MainWindow.xaml):

<local:TreeViewItemWithCustomAutomationPeer Header="CustomAutomationPeerItem">
...
<TreeViewItem Name="SpecialItemToBeExposed" ... ></TreeViewItem>
</local:TreeViewItemWithCustomAutomationPeer Header="CustomAutomationPeerItem">

Code taken from MainWindow.xaml.

The code works by exposing a custom version of the control we want to use, but for which we will trim its children out of the UIA tree.  In my example, I use a TreeViewItem control, since this kind of control is easy to show deep nesting, but it could be anything at all:

// Our custom TreeViewItem, which implements its own custom AutomationPeer
public class TreeViewItemWithCustomAutomationPeer : TreeViewItem
{
     // The only change we make, to return our custom AutomationPeer,
     // instead of the default one that would have been returned.
     protected override AutomationPeer OnCreateAutomationPeer()
     {
         return new CustomAutomationPeerForTreeViewItemWithCustomAutomationPeer(
         // The item itself for the default TreeViewItemAutomationPeer constructor
         this,
         // And get some child designated as necessary for UIA, for whatever reason,
         // just used as an example, so we have something to expose custom...
         TreeHelper.FindChildren<TreeViewItem>(this).Where(
             i => i.Name == "SpecialItemToBeExposed").First()
         );
     }
}

Code taken from TreeViewItemWithCustomAutomationPeer.cs.

We must also implement a custom TreeViewItemAutomationPeer, which I named in the sample with the silly but verbosely accurate choice CustomAutomationPeerForTreeViewItemWithCustomAutomationPeer.
Here is that implementation:

// Our custom TreeViewItemAutomationPeer, deriving from the default one...
public class CustomAutomationPeerForTreeViewItemWithCustomAutomationPeer :
    TreeViewItemAutomationPeer
{
    public TreeViewItem SomeItemWeWantToExpose = null;
    public CustomAutomationPeerForTreeViewItemWithCustomAutomationPeer(
        TreeViewItem currentItem, TreeViewItem someItemWeWantToExpose)
        : base(currentItem)
    {
        SomeItemWeWantToExpose = someItemWeWantToExpose;
    }
    // HERE'S THE ONLY THING THAT REALLY MATTERS IN THIS SIMPLE IMPLEMENTATION!!!
    // You could just return NULL for no children, trim the whole tree out. 
    // But let's say you DO need to expose some element way down in the tree,
    // for whatever reason.  You can do that too, however you want to!
    // That is what is happening with the arbitrary element I chose to include
    // for the purposes of this sample.  But you could also implement
    // the same thing with multiple nodes, or even with other children,
    // having their own custom AutomationPeer implementations too.  Whatever
    // your actual UIA requirements, you could still manage to achieve them, and
    // unless they actually do consist of the entirety of the app's control tree,
    // you could still improve performance by eliminating any nodes that are not
    // actually required...
    protected override List<AutomationPeer> GetChildrenCore()
    {
        List<AutomationPeer> children = new List<AutomationPeer>();
        // Some child we want to return...  We just passed it into our custom class
        // during its construction and kept track of it to return as the only child.
        children.Add(
            TreeViewItemAutomationPeer.CreatePeerForElement(
                SomeItemWeWantToExpose as UIElement));
        return children;
    }
Code taken from TreeViewItemWithCustomAutomationPeer.cs.

In the sample, this implementation provides a short-circuit of an otherwise arbitrarily loaded TreeView, to demonstrate how many fewer nodes are represented, while still exposing one deeply nested node that we designated here as being relevant to UI Automation.  The sample window, when fully expanded to show all the nodes, looks like this:

Although the print is small due to the size of the window to show the deep nesting, you can see both of the top level nodes in the TreeView hold deeply nested structures of child nodes and siblings without any children of their own.

The bottommost node in the second structure is highlighted.  Its parent is the one I chose to expose arbitrarily in the custom AutomationPeer’s children.  As such, when UIA navigates this tree, it will traverse 25 nodes in the top portion of the tree, which are skipped in the lower tree of the same layout, because we have short circuited it to return only one particular node there, with no children even of its own except for its contents.  The impact can be observed using Inspect.exe, from the Windows SDK, to witness the UIA tree returned from both nodes in the TreeView now:

Note the sample does add a reference to UIAutomationProvider in its references, from the default WPF project references added by Visual Studio.  Sample code attached.

CustomAutomationPeerSample.zip

Each window class is responsible for defining its appearance, which includes the client and non-client portions of the window. A window’s border is typically part of its non-client area. Windows will handle drawing the border of a window when non-client window messages such as WM_NCPAINT are passed to the DefWindowProc function.

However, DefWindowProc will use the “classic” border appearance for child windows. Controls themselves are responsible for drawing their borders if the appearance defined for the current visual style is desired.

In Windows XP and later, COMCTL32.DLL version 6 provides an implementation of each of the standard Windows controls (Edit, Button, etc.) and common controls (List View, Tree View, etc.) that are rendered using the current visual style, if one is currently active. It does so by calling the Theme APIs when rendering the contents of the control.

The following code demonstrates using the Theme API to draw the border of an edit control in various states.

int cy = 60;
RECT rc = {10, 10, 300, cy};
int nPartId = EP_EDITBORDER_NOSCROLL;
HTHEME hTheme = OpenThemeData(hWnd, L"EDIT");
if (hTheme)
{
 DrawThemeBackground(hTheme, hdc, nPartId, EPSN_DISABLED, &rc, NULL);
 
 OffsetRect(&rc, 0, cy);
 DrawThemeBackground(hTheme, hdc, nPartId, EPSN_FOCUSED, &rc, NULL);
 
 OffsetRect(&rc, 0, cy);
 DrawThemeBackground(hTheme, hdc, nPartId, EPSN_HOT, &rc, NULL);
 
 OffsetRect(&rc, 0, cy);
 DrawThemeBackground(hTheme, hdc, nPartId, EPSN_NORMAL, &rc, NULL);
 
 CloseThemeData(hTheme);
}
 

The following code demonstrates using the Theme API to draw the border of a rich edit control using the Edit theme class. This code can be added to a Win32 Windows project created in Visual Studio 2010 and Visual Studio 2012 using the following steps:

1. Add the following to stdafx.h:

#include <Richedit.h>
#include <CommCtrl.h>
#include <Uxtheme.h>
#include <vsstyle.h>
#include <vssym32.h>
 

2. Replace the implementation of the InitInstance function with the following: 

BOOL InitInstance(HINSTANCE hInstance, int nCmdShow)
 {
 hInst = hInstance; // Store instance handle in our global variable
 HINSTANCE hInstRE = LoadLibrary(L"MSFTEDIT.DLL");
 
 HWND hWnd = CreateWindowEx(WS_EX_APPWINDOW, 
 szWindowClass, 
 szTitle, 
 WS_OVERLAPPEDWINDOW,
 CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, 
 NULL, NULL, hInstance, NULL);
 DWORD dwStyle = WS_CHILD | 
 WS_VISIBLE | 
 WS_VSCROLL | 
 WS_HSCROLL | 
 ES_MULTILINE;
 
 
 HWND hWndRE = CreateWindowEx(WS_EX_CLIENTEDGE, 
 MSFTEDIT_CLASS, 
 L"Rich Edit Control", 
 dwStyle,
 10, 10, 300, 300, 
 hWnd, NULL, hInstRE, NULL);
 SetWindowSubclass(hWndRE, RichEditSubclassProc, 1, NULL);
 SendMessage(hWndRE, WM_THEMECHANGED, 0, 0);
 
 ShowWindow(hWnd, nCmdShow);
 UpdateWindow(hWnd);
 return TRUE;
 }

3. Add the following functions to the project:

void DrawThemedFrame(HWND hWnd, HRGN hrgnUpdate, HTHEME hTheme)
 {
 int idPart = EP_EDITBORDER_HVSCROLL;
 int idState = EPSHV_NORMAL;
 int cxEdge = GetSystemMetrics(SM_CXEDGE);
 int cyEdge = GetSystemMetrics(SM_CYEDGE);
 
 if (GetFocus() == hWnd)
 {
 idState = EPSHV_FOCUSED;
 }
 
 if (!IsWindowEnabled(hWnd))
 {
 idState = EPSHV_DISABLED;
 }
 
 HDC hDC = GetWindowDC(hWnd);
 if (hDC)
 {
 //
 // Get the border size from the theme
 int cxBorder, cyBorder;
 GetThemeInt(hTheme, idPart, idState, TMT_BORDERSIZE, &cxBorder);
 cyBorder = cxBorder;
 
 //
 // Get the window coordinates
 RECT rcWindow;
 GetWindowRect(hWnd, &rcWindow);
 
 //
 // Create an update region without the client edge to pass to 
 // DefWindowProc
 InflateRect(&rcWindow, -cxEdge, -cyEdge);
 HRGN hrgn = CreateRectRgnIndirect(&rcWindow);
 if (hrgnUpdate)
 {
 CombineRgn(hrgn, hrgnUpdate, hrgn, RGN_AND);
 }
 
 //
 // Zero origin the rect
 OffsetRect(&rcWindow, -rcWindow.left, -rcWindow.top);
 
 //
 // Clip our drawing to the non-client edge
 OffsetRect(&rcWindow, cxEdge, cyEdge);
 ExcludeClipRect(hDC, 
 rcWindow.left, 
 rcWindow.top, 
 rcWindow.right, 
 rcWindow.bottom);
 InflateRect(&rcWindow, cxEdge, cyEdge);
 DrawThemeBackground(hTheme, hDC, idPart, idState, &rcWindow, 0);
 
 //
 // Fill with the control's brush since the theme border may not be as 
 // thick as the client edge
 if (cxBorder < cxEdge && cyBorder < cyEdge)
 {
 InflateRect(&rcWindow, cxBorder-cxEdge, cyBorder-cyEdge);
 FillRect(hDC, &rcWindow, GetSysColorBrush(COLOR_WINDOW));
 }
 
 //
 // Let DefWindowProc to the rest, excluding the border we just painted
 DefWindowProc(hWnd, WM_NCPAINT, (WPARAM)hrgn, 0);
 
 DeleteObject(hrgn);
 ReleaseDC(hWnd, hDC);
 }
 }
 
 
 
 LRESULT CALLBACK RichEditSubclassProc(HWND hWnd, 
 UINT uMsg, 
 WPARAM wParam, 
 LPARAM lParam, 
 UINT_PTR uIdSubclass, 
 DWORD_PTR dwRefData)
 {
 HTHEME hTheme = (HTHEME)GetWindowLongPtr(hWnd, GWLP_USERDATA);
 
 switch (uMsg)
 {
 case WM_DESTROY:
 RemoveWindowSubclass(hWnd, RichEditSubclassProc, 1);
 CloseThemeData(hTheme);
 SetWindowLongPtr(hWnd, GWLP_USERDATA, (LONG_PTR)NULL);
 break;
 
 case WM_SYSCOLORCHANGE:
 case WM_SETFOCUS:
 case WM_KILLFOCUS:
 case WM_ENABLE:
 if (hTheme)
 DrawThemedFrame(hWnd, NULL, hTheme);
 break;
 
 case WM_THEMECHANGED:
 if (hTheme)
 {
 CloseThemeData(hTheme);
 hTheme = NULL;
 }
 
 hTheme = OpenThemeData(hWnd, L"EDIT");
 SetWindowLongPtr(hWnd, GWLP_USERDATA, (LONG_PTR)hTheme);
 InvalidateRect(hWnd, NULL, TRUE);
 break;
 
 case WM_NCPAINT:
 if (hTheme)
 {
 DrawThemedFrame(hWnd, (HRGN)wParam, hTheme);
 return 0;
 }
 break;
 }
 return DefSubclassProc(hWnd, uMsg, wParam, lParam);
 }
 

 4. Add uxtheme.lib and comctl32.lib to the import libraries in the project’s Linker settings.

The resulting project creates a Rich Edit control that is drawn using the theme data for edit controls when themes are active. Please note this sample demonstrates the minimum code needed to draw a themed border for a control and does not perform any error handling.

Some scenarios would be a Windows service that runs in the background and needs to print reports to a printer, or a Windows service that needs to print errors when an infrequent problem occurs on a server machine.

A Windows service that is designed to print can use the Win32 GDI APIs to print documents to a printer.  There are some considerations when printing from Windows services, however.  If all the print jobs can be sent with one user's credentials, the service can be run under that user's account and will have access to the printers that are known to that user on that computer.  If the service must print using the credentials of one or more users defined at run time, then the service must call LogonUser(), LoadUserProfile(), and ImpersonateLoggedOnUser() before printing. 

While it is possible to send GDI+ output to a printer by obtaining a device context handle for the printer and then passing that handle to a GDI+ Graphics constructor, this is not recommended.  The GDI+ functions and classes are not supported for use within a Windows service.  Attempting to use these functions and classes from a Windows service may produce unexpected problems, such as diminished service performance and run-time exceptions or errors:

   msdn.microsoft.com/en-us/library/windows/desktop/ms533798(v=VS.85).aspx

In addition, if you are developing a Microsoft .NET application, System.Drawing is not supported in a service or web application. Attempting to use System.Drawing within one of these application types may produce unexpected problems, such as diminished service performance and run-time exceptions (see the “Caution” section in msdn.microsoft.com/en-us/library/system.drawing.aspx).

System.Printing is also not supported in a service context.  This is documented on MSDN here.  System.Printing is part of Windows Presentation Foundation.

   msdn.microsoft.com/en-us/library/bb613549(v=vs.90).aspx

You should be using the Win32 GDI APIs when printing from your Windows Service:

  msdn.microsoft.com/en-us/library/windows/desktop/dd145203(v=vs.85).aspx

The following Win32 C++ sample code demonstrates how to print a single page to a printer using the Win32 GDI APIs.  The following is only intended as sample code.         

        TCHAR szPrinterName[MAX_PATH] = TEXT("");
        DWORD dwNameLen = MAX_PATH;
        HDC hDC;
        DOCINFO di;

        // We will operate on the default printer
        GetDefaultPrinter( szPrinterName, &dwNameLen );
        // Create the HDC for the printer
        if( (hDC = CreateDC( TEXT("WINSPOOL"), szPrinterName, NULL, NULL )) == NULL )
            return FALSE;

        // The StartDoc function starts the print job
        ZeroMemory( &di, sizeof(DOCINFO) );
        di.cbSize = sizeof(DOCINFO);
        di.lpszDocName = TEXT("Print Job");

        if( StartDoc( hDC, &di ) <= 0 )
        {
            DeleteDC( hDC );
            return FALSE;
        }

        // The StartPage function prepares the printer driver to accept data
        if( StartPage( hDC ) <= 0 )
        {
            EndDoc( hDC );
            DeleteDC( hDC );
            return FALSE;
        }

        TCHAR szString[32] = TEXT("Printing from a service");
        TextOut( hDC, 0, 0, szString, lstrlen( szString ) );

        if( EndPage( hDC ) <= 0 )
        {
            EndDoc( hDC );
            DeleteDC( hDC );
            return FALSE;
        }

        if( EndDoc( hDC ) <= 0 )
        {
            DeleteDC( hDC );
            return FALSE;
        }

        //  Delete the HDC
        DeleteDC( hDC );

If you are developing a Microsoft .NET application, you can use Platform Invocation Services (PInvoke) to call the Win32 GDI APIs to print.  The following C# sample code demonstrates how to print a rectangle to a printer using the Win32 GDI APIs.  The following is only intended as sample code.          

        private void PrintRectangle()
        {
            const int ERROR_INSUFFICIENT_BUFFER = 122;

            IntPtr hdc;
            DOCINFO di = new DOCINFO();
            di.cbSize = 20;
            di.pDocName = "TestingGDI";

            int pcchBuffer = 256;
            StringBuilder pszBuffer = new StringBuilder(pcchBuffer);

            if (GetDefaultPrinter(null, ref pcchBuffer))
            {
                return;
            }

            int lastWin32Error = Marshal.GetLastWin32Error();
            if (lastWin32Error == ERROR_INSUFFICIENT_BUFFER)
            {
                pszBuffer.Capacity = pcchBuffer;
                GetDefaultPrinter(pszBuffer, ref pcchBuffer);
            }

            // This is the default printer
            String szPrinter = pszBuffer.ToString();

            hdc = CreateDC(IntPtr.Zero, szPrinter,
                 IntPtr.Zero, IntPtr.Zero);

            Int32 nRes = StartDoc(hdc, di);

            if (nRes > 0)
            {
                // We call the Win32 StartPage to start a new page on the HDC
                nRes = StartPage(hdc); // You can add error checking to this code

                // Draw a Rectangle
                Rectangle(hdc, 10, 10, 500, 500);

                nRes = EndPage(hdc);

                // First, call the Win32 function to signal the end of the document
                EndDoc(hdc);
                //Then delete the HDC we created for this print job
                DeleteDC(hdc);
            }
        }

        [DllImport("winspool.drv", CharSet = CharSet.Auto, SetLastError = true)]
        public static extern bool GetDefaultPrinter(StringBuilder pszBuffer, ref int pcchBuffer);

        // Win32 DOCINFO structore for starting a print document
        [StructLayout(LayoutKind.Sequential, CharSet = CharSet.Auto)]
        public class DOCINFO
        {
            public int cbSize;
            public string pDocName;
            public string pOutputFile;
            public string pDataType;
            public int fwType;
        }

        // CreateDC() to create a printer HDC
        [DllImport("gdi32.dll", CharSet = CharSet.Auto, SetLastError = true)]
        public static extern IntPtr CreateDC(IntPtr pNull1, string lpszDevice,
        IntPtr
        pNull2, IntPtr lpInitData);

        // StartDocW - the Unicode version of StartDoc - to start a print job
        [DllImport("gdi32.dll", EntryPoint = "StartDocW", SetLastError = true,
        CharSet = CharSet.Unicode, ExactSpelling = true,
        CallingConvention = CallingConvention.StdCall)]
        public static extern Int32 StartDoc(IntPtr hDC, [In,
        MarshalAs(UnmanagedType.LPStruct)] DOCINFO di);

        // StartPage - starts a new page in a print job
        [DllImport("gdi32.dll", EntryPoint = "StartPage", SetLastError = true,
        CharSet = CharSet.Auto, ExactSpelling = true,
        CallingConvention = CallingConvention.StdCall)]
        public static extern Int32 StartPage(IntPtr hDC);

        // EndPage - ends the current page on a printer DC
        [DllImport("gdi32.dll", EntryPoint = "EndPage", SetLastError = true,
        CharSet = CharSet.Auto, ExactSpelling = true,
        CallingConvention = CallingConvention.StdCall)]
        public static extern Int32 EndPage(IntPtr hDC);

        // EndDoc - signals the end of a print job
        [DllImport("gdi32.dll", EntryPoint = "EndDoc", SetLastError = true,
        CharSet = CharSet.Auto, ExactSpelling = true,
        CallingConvention = CallingConvention.StdCall)]
        public static extern Int32 EndDoc(IntPtr hDC);

        // DeleteDC - to clean up our printer DC after the job is done
        [DllImport("gdi32.dll", EntryPoint = "DeleteDC", SetLastError = true,
        CharSet = CharSet.Auto, ExactSpelling = true,
        CallingConvention = CallingConvention.StdCall)]
        public static extern bool DeleteDC(IntPtr hDC);

        [DllImport("gdi32")]
        public static extern bool Rectangle(IntPtr hdc, int nLeftRect, int nTopRect, int nRightRect, int nBottomRect);

 --Definitions--

GDI Objects are resources that are managed by GDI32.DLL on behalf of an application. Some of the most common types of GDI objects are Device Contexts (DCs), Bitmaps, Brushes, Fonts, Metafiles, Pens, and Regions.  GDI Objects are stored in Kernel Memory (specifically the Paged Pool or Session Pool portions of kernel memory – more on this later).

GDI Handles are unique identifiers of a GDI Object.  Each GDI Object can have only one handle.  Each GDI Handle is process-specific (cannot be used by other processes).

The GDI Handle Table is a table (array) of GDI entries.  Each entry contains 32-bits of information about a GDI object, including the handle, the type of the object (i.e. bitmap, DC, pen, font, etc.), the process for which that handle is valid, and a pointer to the actual GDI object in Kernel Memory. This table exists in User Memory.

Note: the fact that it contains the type of the object is very useful to us, and this can be used to help track down what we’re leaking and why – more on this later.

--Creating GDI objects (and getting back a handle)--

To create a GDI object, we call the appropriate GDI API function (usually of the form CreateXXX, such as CreateFontIndirect), which will create the object in kernel memory, and if successful, add an entry in the GDI Handle Table, and return a handle to that object. 

But what if we run out of handles?  What if there isn’t enough room left in kernel memory for the object?  In these cases, the GDI function will fail, and GetLastError will usually return ERROR_INVALID_HANDLE.

--Limits--

There is a limit of 65,536 (64k) GDI handles per session.  Note though that, particularly on 32-bit (x86) systems, the effective maximum is usually lower than this, due to memory limitations.  For example, you generally won’t fit anywhere near 65,536 large bitmaps on a 32-bit system, no matter how many handles you’re allowed to have.

That 65,536 handles needs to accommodate all processes in the session (your app doesn’t get to use them all).  In fact, to prevent a single process from bringing the entire system to its knees (and making the OS unable even to draw a dialog saying “I…CAN’T…DRAW…ANYMORE”), there is a per-process limit, which by default is 10,000 GDI handles.  Although there is rarely, if ever, any good reason for any process to need more than 10k unique GDI objects in memory at the same time, this limit can be raised via the following registry value…

 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Windows\GDIProcessHandleQuota

If an application is running out of GDI handles (i.e. you hit 10k handles and can’t create any more), then raising the above limit is NOT the suggested way of solving the problem. 

First of all, raising this limit does not raise the available kernel memory to store the actual GDI objects that the handles identify.

Second of all, raising this limit REDUCES the number of GDI objects that the rest of the system (including Windows itself) can use.

Thirdly, and maybe most importantly, the application should be redesigned to not use so many GDI resources.  The right thing to do is to manage resources more efficiently in the application.

--Debugging--

Okay, so what do we do if we suspect that we are using too many GDI objects?

1 – Are we really leaking (or using too many) handles?  If so, how many and how fast? 

• Check GDI Object usage via Task Manager (note, you need to specify the GDI Objects column – shown below).

• Generally, if you see a process with a GDI Object count in the thousands, then there is a potential problem.
• If you see a process with a GDI Object count of near 9,999, then it is very probably out of GDI resources and cannot create more.
• When a process (or the system) is out of resources, the creation API (i.e. CreateFont, CreateDC, etc.) will fail and set the last error (GetLastError) to 5 (ERROR_INVALID_HANDLE).

2 – What types of GDI objects are these?  Fonts? Brushes?  Bitmaps?  etc. 

• Find out what types of GDI objects are being leaked (if not already known).  This is harder than it used to be, since most of the tools out there that query this information have fallen out of date with Vista and later.  For reference, and as a starting point if you want to try to get them working…
• GDIObj from www.fengyuan.com/download.html
• GDILeaks from msdn.microsoft.com/en-us/magazine/cc188782.aspx
• There are more, or you could write your own and use the above as reference (see below).You can do this yourself, but it involves some tricks.  The most important thing you’ll need is the address of the GDI handle table in User Memory.  Though undocumented, this can be obtained by looking for GdiSharedHandleTable inside the process environment block (the PEB).  This field contains the address for the handle table. 
• Under WinDbg, once you have public symbols setup, run dt ntdll!_PEB.  This will tell you where in the PEB you can find GdiSharedHandleTable.  Note the location can vary, and will vary between x64 and x86.
• Once you have this location, you can look through the entries in memory.  It will take some trial and error since the exact layout is undocumented and unsupported.  Hint: You could try to use one of the previously linked (older) tools as a starting point. 
• Once you know what type of objects you’re leaking, look for where you are creating these object types in your code (i.e. search for CreateFont and CreateFontIndirect if you are using thousands of font handles), and make sure you are de-selecting and deleting these objects whenever you are done with them.
  • If you think you really need thousands of objects, ask yourself – are these really all unique objects?  Or am I creating hundreds of instances of a 12 point Arial font?  If the latter, then try caching a single instance for use by the different parts of your code (for example, create a single 12-point Arial font when your app starts up, and save the handle off).  Just use the same handle as needed in your code.  Delete it with DeleteObject when you’re really done with it (maybe not until your app closes).
  • On the other hand, if you really need thousands of unique objects, try to create/select/use/de-select/delete these objects each time you need them.

3 – If there isn’t a clear problem handle leak found via 1 and 2…

• Check overall Paged Pool usage.
• This can be quickly checked with Task Manager (notice the “Paged” field in the Performance tab of Task Manager shown here)…

• Even better, check the Paged Pool usage with Process Explorer.
• First, you need to set up symbols via Options->Configure Symbols.  Enter a symbol path of SRV**msdl.microsoft.com/download/symbols
• Then,       click View->System Information…
• Note, Process Explorer also shows the limit (when symbols are configured correctly as above) - which is information that Task Manager does not give…

4 - If #3 shows that you are running out of Paged Pool…

• First, a bit about which “Paged Pool” we care about (there are really two kinds).  For systems that don’t have Terminal Services installed, we’re talking about general paged pool; on all other systems, we mean the per-session session pool.
• If running XP or earlier versions of Windows, then, you would need to explicitly “tell” the system that you want pool allocations to be tagged.  On these older systems, run gflags.exe (along with WinDbg, this is included with Debugging Tools for Windows), and select the “Enable pool tagging” checkbox. Then, reboot (again, XP and earlier only).

• Poolmon will tell you what objects are using up Paged Pool (it will also show you the overall usage like Task Manager and Process Explorer did)…

• To narrow down what PoolMon shows you, you can start it as follows (for example)…
• poolmon –gla*
• You can also tell it to sort by various fields and turn off highlighting (press ? for help and ESC to get out of help).
• pooltag.txt ships with the Windows Driver Kit (WDK) and lists all the tags, but we only care about a few…
• The tags that GDI use all start with ‘G’, making this usage more easy to track (not only in poolmon, but when debugging - for example, under WinDbg, you could run !poolused 4 Gla: ).
• Some example tags are…
• “Gla:” Font type is 0xa.
• “Gla1” DC type is 0x1.
• “Gh05” SURF (bitmap) type is 0x5.
• To give you a rough idea of memory usage seen through experimentation (these are under XP):
• DCs (Gla1) – 1600 bytes per object
• Fonts (Gla:) – 656 bytes per object
• Bitmaps (Gla5) – 392 bytes per object
• Regions (Gla4) – 176 bytes per object
• Palettes (Gla8) – 160 bytes per object
• Brushes (Gla@) – 112 bytes per object
• Tracking down a pagedpool leak is often more art than science, but a few tools to help you figure out what is leaking are:
• Under WinDbg: !poolused 4
• Under WinDbg: !vm 1
• poolmon (see above)

• Note – to track Session Paged Pool, use poolmon /s, or poolmon /s# (where # is a session ID).  You can toggle between system and session by typing s while poolmon is running.

5 – Once you know what is being leaked…

• Review your code.  Make sure you are cleaning up after yourself with DeleteObject.  This is something you should do before even going down this road!
• If you can’t find the culprit, try adding some trace information next to your CreateXXX and DeleteObject calls, and then examine the output after running.
• Put a breakpoint on the CreateXXX function (where the actual function name depends on the type of object – e.g. ExtCreateBrush), and try to see who the guilty party is.

• NOTE - Often, if there is a leak of this kind, the function is being hit hundreds or thousands of times, and not every one will be part of the actual leak (often, most of them are not!).  Just because you’re leaking fonts, doesn’t mean *this* CreateFontIndirect call is part of the problem.

Some common mistakes…

• In .NET, not explicitly calling Dispose on all System.Drawing objects before they go out of scope (the using keyword is also acceptable).
• Not calling DeleteObject on each created GDI object in native (non-.NET) code.
• Creating lots of memory intensive objects (for example large bitmaps).  Particularly on 32-bit systems.  Also, particularly in a terminal services session, where the available session paged pool is much lower.

Direct2D is the supported technology for rendering images to an image file on disk in a service context.  Below is C# ASP.NET code which shows how to render a Direct2D scene to an image file on disk.  This code can be used in any C# service. It demonstrates how to create a Direct2D bitmap based on image data in memory, draw Direct2D objects, such as an Ellipse and a Rectangle, and it also uses DirectWrite to render text. The code relies on the DirectX assembly from the Windows API Code Pack for Microsoft .NET Framework. This assembly provides developers access to Direct2D and DirectWrite from managed code.  You will need to use the following file from the Windows API Code Pack for Microsoft .NET Framework, and add it as a reference to your project:    Microsoft.WindowsAPICodePack.DirectX.dll     See:  archive.msdn.microsoft.com/WindowsAPICodePack     The Windows API Code Pack for Microsoft .NET Framework is a free, managed source code library provided by Microsoft as is.

After you implement the C# code (below), then you should see an image on disk created as follows:

/**************************** Module Header ******************************\
' Copyright (c) Microsoft Corporation.
'
' This code demonstrates how to use Direct2D to render 2D objects and text to
'   an image file on disk.
'
' THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND,
' EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED
' WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.
'**************************************************************************/
 
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using Microsoft.WindowsAPICodePack.DirectX;
using Microsoft.WindowsAPICodePack.DirectX.Direct2D1;
using Microsoft.WindowsAPICodePack.DirectX.WindowsImagingComponent;
using Microsoft.WindowsAPICodePack.DirectX.DirectWrite;
 
namespace D2DServerSide
{
    public partial class _Default : System.Web.UI.Page
    {
 
        D2DFactory d2dFactory;
        ImagingFactory wicFactory;
        DWriteFactory dwriteFactory;
        D2DBitmap d2dBitmapBarcode;
        RenderTarget wicRenderTarget;
 
        RenderTargetProperties renderProps = new RenderTargetProperties
        {
            PixelFormat = new PixelFormat(
                     Microsoft.WindowsAPICodePack.DirectX.Graphics.Format.B8G8R8A8UNorm,
                     AlphaMode.Ignore),
            Usage = RenderTargetUsages.None,
            RenderTargetType = RenderTargetType.Software
        };
 
        // Demonstrates how to create a Direct2D bitmap based on image data in memory
        private void CreateBitmap()
        {
            // We have a 32 bpp Bitmap.  This is one example.
            // The width and height are:  69 x 23
            var size = new SizeU((uint)69, (uint)23);
 
            BitmapProperties bmpProp = new BitmapProperties(new PixelFormat(
                    Microsoft.WindowsAPICodePack.DirectX.Graphics.Format.B8G8R8A8UNorm,
                    AlphaMode.Ignore), wicRenderTarget.Dpi.X, wicRenderTarget.Dpi.Y);
                    d2dBitmapBarcode = wicRenderTarget.CreateBitmap(size, bmpProp);
 
            int nWidth = (int)size.Width;
            int nHeight = (int)size.Height;
 
            byte[] testData = new byte[nWidth * nHeight * 4];
            byte TestByte = 1;
            int nCurrentDest = 0;
 
            for (int y = 0; y < nHeight; y++)
            {
                for (int x = 0; x < nWidth; x++)
                {
                    byte CurrByte = (byte)TestByte++;
 
                    testData.SetValue(CurrByte, nCurrentDest);   // blue
                    testData.SetValue(CurrByte, nCurrentDest + 1);  // green
                    testData.SetValue(CurrByte, nCurrentDest + 2);  // red
                    nCurrentDest += 4;
                }
            }
            d2dBitmapBarcode.CopyFromMemory(testData, ((uint)nWidth) * 4 );
        }
 
        protected void Button1_Click(object sender, EventArgs e)
        {
            //Create Factories.
            d2dFactory = D2DFactory.CreateFactory(D2DFactoryType.Multithreaded);
            wicFactory = ImagingFactory.Create();
            dwriteFactory = DWriteFactory.CreateFactory();
 
            float ShippingLabelWidth = 500.0f;
            float ShippingLabelHeight = 500.0f;
 
            SizeU size = new SizeU((uint)ShippingLabelWidth, (uint)ShippingLabelHeight);
 
            ImagingBitmap wicBitmap = wicFactory.CreateImagingBitmap(
                      size.Width,
                      size.Height,
                      PixelFormats.Bgr32Bpp,
                      BitmapCreateCacheOption.CacheOnLoad);
 
            wicRenderTarget =
                      d2dFactory.CreateWicBitmapRenderTarget(wicBitmap, renderProps);
 
            // Create a sample Bitmap
            CreateBitmap();
 
            wicRenderTarget.BeginDraw();
 
            wicRenderTarget.Clear(new ColorF(0, 1, 0, 1));  // clear the background
            SolidColorBrush blackSolidColorBrush;
 
            blackSolidColorBrush = wicRenderTarget.CreateSolidColorBrush(new ColorF(0, 0, 0, 1));
 
            // Render an Ellipse
            Ellipse ellipse = new Ellipse();
            ellipse.Point = new Point2F(300.0f, 300.0f);
            ellipse.RadiusX = 100.0f;
            ellipse.RadiusY = 150.0f;
 
            wicRenderTarget.DrawEllipse(ellipse, blackSolidColorBrush, 10.0f);
 
            // Render a Rectangle
            RectF rect;
            rect = new RectF(130, 30, 200, 100);
            wicRenderTarget.DrawRectangle(rect, blackSolidColorBrush, 10.0f);
 
            // Render text rotated
            TextFormat textFormat_Value;
 
            textFormat_Value = dwriteFactory.CreateTextFormat("Arial", 17,
                      Microsoft.WindowsAPICodePack.DirectX.DirectWrite.FontWeight.Bold,
                      Microsoft.WindowsAPICodePack.DirectX.DirectWrite.FontStyle.Normal,
                      Microsoft.WindowsAPICodePack.DirectX.DirectWrite.FontStretch.Normal);
 
            RectF renderText_Value;
 
            renderText_Value = new RectF(10, 150, 180, 250);
 
            wicRenderTarget.Transform = Matrix3x2F.Rotation(90, new Point2F(100, 95));
            wicRenderTarget.DrawText("This is a test", textFormat_Value,
                                          renderText_Value, blackSolidColorBrush);
            wicRenderTarget.Transform = Matrix3x2F.Translation(0, 0);
 
            RectF DrawBitmap_Rect;
            DrawBitmap_Rect = new RectF(10, 275, 180, 350);
            wicRenderTarget.DrawBitmap(d2dBitmapBarcode, 1.0f,
                                         BitmapInterpolationMode.NearestNeighbor, DrawBitmap_Rect);
 
            wicRenderTarget.EndDraw();
 
            try
            {
                // This code will need write permissions to the folder on the server that
                // you wish to save the image file to.
                // You will need to grant permission to the "Network Service" user
                //  account.
                wicBitmap.SaveToFile(wicFactory, ContainerFormats.Png,
                                       "c:\\SampleFiles\\Images\\test.png");
            }
            catch (Exception ex)
            {
                // Catch the exception that is unhandled in TryCast.
                 Type ExceptionType = ex.GetType();
 
                // Check for System.UnauthorizedAccessException here.  You will need to
                //   grant permission
                //   to the "Network Service" user account for the folder on the server
                //   that you wish to save the image file to.
                // Restore the original unhandled exception.
                throw;
            }
            finally
            {
                // Clean up
                d2dFactory.Dispose();
                wicFactory.Dispose();
                dwriteFactory.Dispose();
            }
        }
    }
}

Run-time requirements for Direct2D:

-          Windows 7 or Windows Vista with Service Pack 2 (SP2) and Platform Update for Windows Vista and later.

-          Windows Server 2008 R2 or Windows Server 2008 with Service Pack 2 (SP2) and Platform Update for Windows Server 2008 and later.

For Windows XP and Windows Server 2003, you will need to use Win32 GDI.  For more information on GDI, see:   msdn.microsoft.com/en-us/library/windows/desktop/dd145203(v=vs.85).aspx

For more information on Direct2D, see:

msdn.microsoft.com/en-us/library/windows/desktop/dd370990(v=vs.85).aspx

For more information on the Windows API Code Pack for Microsoft .NET Framework, see:

archive.msdn.microsoft.com/WindowsAPICodePack

1 - Use the Desktop Duplication API.  This is a very powerful and full-featured API, which provides access to every frame of desktop update, BUT, it is not available prior to Windows 8.

One drawback is that most full-screen exclusive mode DirectX or OpenGL applications will not be able to be captured with Desktop Duplication.  Exclusive mode really means that the ‘Windowed’ field of D3DPRESENT_PARAMETERS is set to false.  Some apps are not in true full-screen mode and are windowed, but with the window set to the size of the desktop.  These can still be captured.

To make matters a little more confusing, newer DirectX (11.1 and later) exclusive mode apps can be captured with the Desktop Duplication API, unless they "opt-out" and specifically disallow it (in which case they won't be capture-able by Desktop Duplication, just like a pre-11.1 DirectX app).

2 - The old standby, GDI, can still capture the screen.  Typically, BitBlt is used.  This technique is not perfect, and there are some things, such as multimedia output, that won't get captured.

BitBlt can also can be slow, although you can get much better performance by making sure that the bitmap (that you are capturing into) is the same resolution as the screen.  To assure this, you could use CreateCompatibleBitmap (for a device-dependent bitmap), or CreateDIBSection (for a device-independent bitmap).  If you use CreateDIBSection, just make sure the bit-depth and layout matches the screen's.  This allows BitBlt to avoid any color conversion, which can drastically slow everything down.  Here's what such code might look like from a high level...

// Pseudo-code...

HDC hDCScreen = GetDC(NULL);

HDC hDCMem = CreateCompatibleDC(hDCScreen);

HBITMAP hBitmap = CreateCompatibleBitmap(hDCScreen, screenwidth, screenheight);

SelectObject(hDCMem, hBitmap);

BitBlt(hDCMem, 0, 0, screenwidth, screenheight, 0, 0, SRCCOPY);

…

3 - Another option is to use Direct3D.  Note that some have reported that this can actually be slower than BitBlt, but performance of any technique will depend a lot on the hardware and graphics settings (regardless of the method used).  To do this with Direct3D, you could use GetRenderTargetData to copy the rendering surface (retrieved with GetRenderTarget) to an off-screen surface (which can be created with CreateOffscreenPlainSurface).  After copying the surface data this way, you can save the contents of the surface to a file using D3DXSaveSurfaceToFile.

4 - Yet another possibility is to use Windows Media technologies to do the capture (specifically, Expression Encoder will do this if you just need another application).  To do it programmatically yourself (using Windows Media), you can use the Windows Media Video 9 Screen codec.

5 - Finally, for pre-Windows 8 systems, you could develop a Mirror Driver to do this (Windows 8 uses another driver model, which is also described under the preceding link).

Some of the above techniques (particularly #2 and #3) can also be used to capture only a single window.  Note that iif you use BitBlt to do this, you could "or in" the CAPTUREBLT flag if you wanted to capture windows that are layered on top of your window .  The PrintWindow API is another good option for capturing only a single window (not listed above since it can't capture the entire screen).

The CreateWindowEx function

We should first discuss how the CreateWindowEx function works before diving into how to troubleshoot CreateWindowEx failures.Windows applications, including .NET applications that use Windows Forms or Windows Presentation Foundation, create their windows by calling the CreateWindowExA or CreateWindowExW functions. Both functions internally call a common USER32 function that will perform some parameter validation, such as the window styles and handles specified in the call, handle creating a MDI child window if the WS_EX_MDICHILD extended window style is specified and processes the current activation context for the calling thread. If all is well on the USER32-side of the CreateWindowEx call, it then calls into the kernel-mode (WIN32K) implementation of CreateWindowEx.

The kernel-side of the CreateWindowEx call will first check the following conditions:

• Does the specified window class exist?
• Can the text for the atom be retrieved, if the caller specified an atom for the class name?
• Was a parent window specified, if creating a child window?
• Will the new window exceed the nested window depth limit, if creating a child window or an owned window? The default limit is 50 levels deep and can be configured via the USERNestedWindowLimit registry value.
• Does the parent/owner window belong to the same desktop as the calling thread?

Assuming that each of these checks pass, CreateWindowEx will perform the following tasks when attempting to create a new window object:

• Determine if creating a handle for the new window object will exceed the User handle quota limit for the calling process.
• Allocates memory for the new window object from the desktop's heap.
• Initializes the memory for the new window object
• Creates a handle for the new window object in the User handle table

Assuming that the window object was created successfully, CreateWindowEx will notify registered WinEvent and WH_CBT hooks that a new window object has been created, determine the location, size, z-order position, etc. of the new window, followed by calling the window's WndProc to process WM_NCCREATE and WM_CREATE window messages. CreateWindowEx then returns the handle of the new window object.

Causes of CreateWindowEx failures

You may have noticed some of the conditions that will cause CreateWindowEx to fail from the previous section. Let's enumerate conditions that will cause CreateWindowEx to fail:

• The specified window class does not exist.
• Using invalid window styles or extended window styles.
• Using invalid User handles, such as window handles and menu handles.
• Attempting to create a child window without specifying a parent window.
• Attempting to create a child window or an owned window and the specified parent/owner belongs to a different desktop than the calling thread.
• Creating a child or owned window will exceed the nested window limit.
• Creating a new window object will exceed the handle quota for the calling process.
• There is insufficient heap available in the desktop’s heap to allocate memory for the new window object.
• There are no available entries in the User handle table.

Note that while a new window object is successfully created, the CreateWindowEx function may still return NULL. How can this happed?

Recall that before returning, CreateWindowEx will call the window's WndProc to process a WM_NCCREATE and a WM_CREATE window message. The WndProc can stop the window creation by returning 0 when handling the WM_NCCREATE window message or by returning -1 when handling the WM_CREATE window message. CreateWindowEx handles this situation by destroying the window object and returning NULL. Additionally, a WH_CBT hook can stop the window creation by returning 0 from its hook procedure when handling the HCBT_CREATEWND notification.

CreateWindowEx failures and GetLastError

The Windows SDK documentation for the CreateWindowEx function states that extended error information can be obtained by calling GetLastError when CreateWindowEx returns NULL. But how useful is the error code returned by GetLastError?

The answer is that it depends on the error condition that caused CreateWindowEx to return NULL.

For example, GetLastError will return ERROR_CANNOT_FIND_WND_CLASS if the window class does not exist. On the other hand, GetLastError may return NOERROR or some error code that seems unrelated to calling CreateWindowEx if the window's WndProc stopped the window creation when handling the WM_NCCREATE or WM_CREATE messages.

Troubleshooting CreateWindowEx failures

Although GetLastError does not always return a valid error code on a CreateWindowEx failure, you should always check the error code as it may help diagnose the source of the failure. Current versions of the .NET Framework included the value returned by GetLastError when throwing a Win32Exception. Earlier versions of the .NET Framework did not include the error code when throwing a Win32Exception.

Hitting the User handle quota limit for the process should be pretty simple to identify. You can view the User object handle count for a process in Task Manager (taskmgr.exe) or by calling the GetGuiResources function. If the handle count is approaching the User handle quota limit, then Task Manager and GetGuiResources is likely reporting a value near the limit. Additionally, GetLastError should return ERROR_NO_MORE_USER_HANDLES. The default limit is 10,000 and can be configured via the USERProcessHandleQuota registry value.

Running out of desktop heap is a little more difficult to identify since there is no mechanism that ships with Windows to measure available desktop heap for a given desktop. However, GetLastError should return ERROR_NOT_ENOUGH_MEMORY. You can find more information on desktop heap at blogs.msdn.com/b/ntdebugging/archive/2007/01/04/desktop-heap-overview.aspx.

Then there are the scenarios where CreateWindowEx fails and GetLastError returns NOERROR or what appears to be an invalid error code. Generally, in this scenario, the failure is caused by the window's WndProc stopping the window creation. There are some user-mode troubleshooting options that you can use before you start stepping through the disassembly of the kernel side of the CreateWindowEx function.

One approach is to set a WH_CBT window hook on the thread calling CreateWindowEx to determine if a window object has been created for a given CreateWindowEx call. Recall that WH_CBT hook procedures are called with the HCBT_CREATEWND notification after a window object has been created and before the window procedure is called to handle the WM_NCCREATE and WM_CREATE window messages.

You can then set a WH_CALLWNDPROC window hook on the thread calling CreateWindowEx or set a breakpoint on the window's WndProc (if known) to determine if the window's WndProc is called to handle the WM_NCCREATE and WM_CREATE window messages. You can also use the Spy++ tool included with Visual Studio to monitor when windows owned by a thread process WM_NCCREATE and WM_CREATE window messages.

Debugging CreateWindowEx with WinDBG

I tend to use the Debugging Tools for Windows for most of my debugging work, specifically WinDBG. The debugging tasks described below are from a 32-bit Windows 7 system using the version of WinDBG included with the Windows SDK for Windows 7 and the public Microsoft symbol server.

You may encounter a scenario where you are trying to troubleshoot a CreateWindowEx failure where you do not know the address of the window's WndProc, such as a third-party control. How do you set a breakpoint on the WndProc?

Recall that most of the work for creating a window is done in kernel mode, which includes calling the window's WndProc to process WM_NCCREATE and WM_CREATE window messages. Since the kernel side of CreateWindowEx tries to call a user mode function, Windows needs to transition back into user mode to call the WndProc, which is done via the DispatchClientMessage function.

You can use a breakpoint on CreateWindowEx that enables a breakpoint on DispatchClientMessage and another breakpoint when CreateWindowEx returns that disables the breakpoint on DispatchClientMessage. This should allow you to determine if the window procedure of the window is being called.

Here are breakpoints that I used when debugging an instance of Notepad:

0:000> bl
 0 e 75934ec3     0001 (0001)  0:**** USER32!DispatchClientMessage ".echo ***** DispatchClientMessage *****;dd @esp+4 L4;g"
 1 e 7592ec7c     0001 (0001)  0:**** USER32!CreateWindowExW ".echo ***** CreateWindowExW called *****;be 0;g"
 2 e 7592ecb0     0001 (0001)  0:**** USER32!CreateWindowExW+0x34 ".echo ***** CreateWindowExW returned *****;bd 0;r @eax;g"

Breakpoint 0 is initially disabled. It will be enabled when CreateWindowEx is called and disabled when CreateWindowEx returns. When hit, the breakpoint will dump the parameters passed to the function and then resume execution. You could also set up the breakpoint to halt in the debugger where you could then step into the window procedure. Note in the debug output below that the last parameter to DispatchClientMessage is the address of the window procedure.

Breakpoint 1 displays a message that CreateWindowEx is being called, tries to display the class name passed to CreateWindowEx (which will fail if an atom is passed) and enables the breakpoint on DispatchClientMessage.

Breakpoint 2 displays a message that CreateWindowEx is returning, displays the value of the handle that it is returning and disables breakpoint 0.

Below is the debugger ouput from the first CreateWindowEx call in the process:

***** CreateWindowExW called *****
***** DispatchClientMessage *****
001bf504  00b9fc18 00000081 00000000 001bf56c
***** DispatchClientMessage *****
001bf548  00b9fc18 00000083 00000000 001bf594
***** DispatchClientMessage *****
001bf4d4  00b9fc18 00000001 00000000 001bf53c
***** DispatchClientMessage *****
001bf554  00b9fc18 00000005 00000000 00000000
***** DispatchClientMessage *****
001bf554  00b9fc18 00000003 00000000 00000000
***** CreateWindowExW returned *****
eax=000602fe

Note the window messages that are being received by the window. WM_NCCREATE is 0x81 and WM_CREATE is 0x1. The other messages are also a part of normal window creation.

In the example above, you might have noticed that I skipped how I found the address of the return from CreateWindowEx in order to set breakpoint 2. The method that I used was to examine the disassembly of the CreateWindowExW function and looked for the return instruction, highlighted below.

0:000> u user32!CreateWindowExW L13
USER32!CreateWindowExW:
7592ec7c 8bff            mov     edi,edi
7592ec7e 55              push    ebp
7592ec7f 8bec            mov     ebp,esp
7592ec81 6800000040      push    40000000h
7592ec86 ff7534          push    dword ptr [ebp+34h]
7592ec89 ff7530          push    dword ptr [ebp+30h]
7592ec8c ff752c          push    dword ptr [ebp+2Ch]
7592ec8f ff7528          push    dword ptr [ebp+28h]
7592ec92 ff7524          push    dword ptr [ebp+24h]
7592ec95 ff7520          push    dword ptr [ebp+20h]
7592ec98 ff751c          push    dword ptr [ebp+1Ch]
7592ec9b ff7518          push    dword ptr [ebp+18h]
7592ec9e ff7514          push    dword ptr [ebp+14h]
7592eca1 ff7510          push    dword ptr [ebp+10h]
7592eca4 ff750c          push    dword ptr [ebp+0Ch]
7592eca7 ff7508          push    dword ptr [ebp+8]
7592ecaa e8edfeffff      call    USER32!_CreateWindowEx (7592eb9c)
7592ecaf 5d              pop     ebp
7592ecb0 c23000          ret     30h

I then use the following syntax to set the breakpoint:

bp2 7592ecb0 ".echo ***** CreateWindowExW returned *****;bd 0;r @eax;g"

Alternately, you can set a conditional breakpoint when CreateWindowEx returns and use the !gle command to dump the value that will be returned by GetLastError if CreateWindowEx fails, where the EAX register is zero. In the scenario below, I created a simple Windows Forms application that repeatedly creates child windows until the User handle process quota is reached and CreateWindowEx fails.

I use the following command to set a conditional breakpoint on the return from CreateWindowExW that breaks in the debugger when the function fails:

bp 7592ecb0  "j (@eax==0) '.echo ***** CreateWindowExW failed. *****';'g'"

Once the debugger breaks on a CreateWindowEx failure, you can obtain the last error value with the !gle command:

0:000> !gle
LastErrorValue: (Win32) 0x486 (1158) - The current process has used all of its system allowance of handles for Window Manager objects.

You can also execute other debugger commands, including .NET debugger extension commands such as !clrstack:

0:000> .loadby sos clr
0:000> !clrstack
OS Thread Id: 0xea4 (0)
Child SP IP       Call Site
001ae9c4 7592ecb0 [InlinedCallFrame: 001ae9c4]
001ae9a8 5e6c50ef DomainBoundILStubClass.IL_STUB_PInvoke(Int32, System.String, System.String, Int32, Int32, Int32, Int32, Int32, System.Runtime.InteropServices.HandleRef, System.Runtime.InteropServices.HandleRef, System.Runtime.InteropServices.HandleRef, System.Object)
001ae9c4 5e6a978c [InlinedCallFrame: 001ae9c4] System.Windows.Forms.UnsafeNativeMethods.IntCreateWindowEx(Int32, System.String, System.String, Int32, Int32, Int32, Int32, Int32, System.Runtime.InteropServices.HandleRef, System.Runtime.InteropServices.HandleRef, System.Runtime.InteropServices.HandleRef, System.Object)
001aea88 5e6a978c System.Windows.Forms.UnsafeNativeMethods.CreateWindowEx(Int32, System.String, System.String, Int32, Int32, Int32, Int32, Int32, System.Runtime.InteropServices.HandleRef, System.Runtime.InteropServices.HandleRef, System.Runtime.InteropServices.HandleRef, System.Object)
001aead0 5e6a8e9f System.Windows.Forms.NativeWindow.CreateHandle(System.Windows.Forms.CreateParams)
001aeb54 5e6a8b82 System.Windows.Forms.Control.CreateHandle()
001aebac 5e6a8921 System.Windows.Forms.Control.CreateControl(Boolean)
001aebe4 5e6a8818 System.Windows.Forms.Control.CreateControl()
001aebfc 5e6b1c31 System.Windows.Forms.Control+ControlCollection.Add(System.Windows.Forms.Control)
001aec38 5e6b1aab System.Windows.Forms.Form+ControlCollection.Add(System.Windows.Forms.Control)
001aec4c 5ef8f027 System.Windows.Forms.Control.set_ParentInternal(System.Windows.Forms.Control)
001aec58 5ebfd59a System.Windows.Forms.Control.set_Parent(System.Windows.Forms.Control)
001aec60 002903c3 WindowsFormsApplication1.Form1.button1_Click(System.Object, System.EventArgs)*** WARNING: Unable to verify checksum for WindowsFormsApplication1.exe
 [D:\Cases\WindowsFormsApplication1\WindowsFormsApplication1\Form1.cs @ 24]
001aec80 5e654507 System.Windows.Forms.Control.OnClick(System.EventArgs)
001aec94 5e656ca2 System.Windows.Forms.Button.OnClick(System.EventArgs)
001aecac 5ec3a480 System.Windows.Forms.Button.OnMouseUp(System.Windows.Forms.MouseEventArgs)
001aecc8 5ec03dd1 System.Windows.Forms.Control.WmMouseUp(System.Windows.Forms.Message ByRef, System.Windows.Forms.MouseButtons, Int32)
001aed5c 5efa6a2f System.Windows.Forms.Control.WndProc(System.Windows.Forms.Message ByRef)
001aed60 5efae391 [InlinedCallFrame: 001aed60]
001aedb4 5efae391 System.Windows.Forms.ButtonBase.WndProc(System.Windows.Forms.Message ByRef)
001aedf8 5e6c19f8 System.Windows.Forms.Button.WndProc(System.Windows.Forms.Message ByRef)
001aee04 5e6aa393 System.Windows.Forms.Control+ControlNativeWindow.OnMessage(System.Windows.Forms.Message ByRef)
001aee0c 5e6aa311 System.Windows.Forms.Control+ControlNativeWindow.WndProc(System.Windows.Forms.Message ByRef)
001aee20 5e6aa256 System.Windows.Forms.NativeWindow.Callback(IntPtr, Int32, IntPtr, IntPtr)
001aefc4 00840ab8 [InlinedCallFrame: 001aefc4]
001aefc0 5e6c6c1c DomainBoundILStubClass.IL_STUB_PInvoke(MSG ByRef)
001aefc4 5e6ba99f [InlinedCallFrame: 001aefc4] System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG ByRef)
001af008 5e6ba99f System.Windows.Forms.Application+ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr, Int32, Int32)
001af00c 5e6ba5cc [InlinedCallFrame: 001af00c]
001af0a4 5e6ba5cc System.Windows.Forms.Application+ThreadContext.RunMessageLoopInner(Int32, System.Windows.Forms.ApplicationContext)
001af0fc 5e6ba421 System.Windows.Forms.Application+ThreadContext.RunMessageLoop(Int32, System.Windows.Forms.ApplicationContext)
001af12c 5e642815 System.Windows.Forms.Application.Run(System.Windows.Forms.Form)
001af140 002900ae WindowsFormsApplication1.Program.Main() [D:\Cases\WindowsFormsApplication1\WindowsFormsApplication1\Program.cs @ 18]
001af370 710d21bb [GCFrame: 001af370] 

Conclusion

Hopefully you will be able to apply some of the techniques described in this post if you find yourself in the situation where you are trying to troubleshoot CreateWindowEx failures in managed and native applications.

One of the most common issues we debug related to Windows Forms applications is when an application becomes unresponsive due to the SystemEvents.UserPreferenceChanged event. This blog to explain what is actually occurring, and how to find and fix the culprit. The reason this occurs and the solution is explained in KnowledgeBase article 943139.

Windows Forms application freezes when system settings are changed or the workstation is locked
support.microsoft.com/kb/943139/EN-US

For the purposes of this discussion, I’m going to talk mainly about System.Windows.Forms.Control or just “Control” (remember that a Windows Form itself is a derivative of the Control class).

Why Windows Forms Applications Become Unresponsive During SystemEvents.UserPreferenceChanged

As KB article 943139 mentions, the application may become unresponsive when a Windows Forms Control has been created on a thread which doesn’t pump window messages; and when the application’s UI thread receives and processes a WM_SETTINGCHANGE message. Note the window message could be for other “settings” related messages such as WM_SYSCOLORCHANGE, WM_DISPLAYCHANGED, WM_THEMECHANGED, among others.

The SystemEvents class uses a hidden window internally to handle processing the window messages related to the SystemEvents class. If you were to look at this under Spy++, the window caption for this hidden window starts with “.NET-BroadcastEventWindow”.  So when a WM_SETTINGCHANGE (or related) message comes in, the Winforms message pump retrieves it from the thread’s message queue and dispatches it to the window procedure associated with the “.NET-BroadcastEventWindow”. This uses the thread’s SynchronizationContext.Send method to invoke the delegate which eventually raises the SystemEvents.UserPreferenceChanged event for the target window.

Windows Forms installs a WindowsFormsSynchronizationContext on each thread which has created a Windows Forms Control. This derived SynchronizationContext is used by Windows Forms to handle communications between various threads with Windows Forms controls. So the delegate which SystemEvents wants to invoke eventually raises UserPreferenceChanged is invoked, it is done so on the WindowsFormsSynchronizationContext.  The internal implementation of WindowsFormsSynchronizationContext uses a Windows Forms control known as the “Marshaling Control” to handle communication between various threads, and subsequently the overridden SynchronizationContext.Send method uses Control.Invoke to marshal the call from the current thread to the target thread. In order for Control.Invoke to return, the target thread must be pumping window messages.When the target thread does not pump window messages, the UI thread is going to block indefinitely, and now you’re hung.

Debugging a Windows Forms Application in the Unresponsive State

So what does this look like under the debugger? Alright, let’s debug this after we are in the hung state to see what’s happening. The rest of this blog assumes you are familiar with the use of Windbg, user mode and .NET debugging. If you attach Windbg to a Windows Forms application in this state, your main UI thread should look something like this.

 0:000>knL
 # ChildEBP RetAddr 
00 0018e2e0 75340bdd ntdll!NtWaitForMultipleObjects+0x15
01 0018e37c 758a1a2c KERNELBASE!WaitForMultipleObjectsEx+0x100
03 0018e418 76da2bf1 USER32!RealMsgWaitForMultipleObjectsEx+0x14d
04 0018e444 76d9202d ole32!CCliModalLoop::BlockFn+0xa1
05 0018e4c4 79e0d245 ole32!CoWaitForMultipleHandles+0xcd
06 0018e4e4 79e0d1a6 mscorwks!NT5WaitRoutine+0x51
07 0018e550 79e0d10a mscorwks!MsgWaitHelper+0xa5
08 0018e570 79ec42d8 mscorwks!Thread::DoAppropriateAptStateWait+0x28
09 0018e5f4 79ec436d mscorwks!Thread::DoAppropriateWaitWorker+0x13c
0a 0018e644 79e64af8 mscorwks!Thread::DoAppropriateWait+0x40
0b 0018e748 791169df mscorwks!WaitHandleNative::CorWaitOneNative+0x156
0c 0018e764 79116995 mscorlib_ni!System.Threading.WaitHandle.WaitOne(Int64, Boolean)+0x2f
0d 0018e77c 7b3f2231 mscorlib_ni!System.Threading.WaitHandle.WaitOne(Int32, Boolean)+0x25
0e 0018e798 7aed4c20 System_Windows_Forms_ni!System.Windows.Forms.Control.WaitForWaitHandle(System.Threading.WaitHandle)+0x89
0f 0018e830 7b3f3bb0 System_Windows_Forms_ni!System.Windows.Forms.Control.MarshaledInvoke(System.Windows.Forms.Control, System.Delegate, System.Object[], Boolean)+0x31c
10 0018e86c 7b621873 System_Windows_Forms_ni!System.Windows.Forms.Control.Invoke(System.Delegate, System.Object[])+0x50
11 0018e884 04f42496 System_Windows_Forms_ni!System.Windows.Forms.WindowsFormsSynchronizationContext.Send(System.Threading.SendOrPostCallback, System.Object)+0x5f
12 0018e8b8 04f4064f System_ni!Microsoft.Win32.SystemEvents+SystemEventInvokeInfo.Invoke(Boolean, System.Object[])+0x62
13 0018e904 04f4195b System_ni!Microsoft.Win32.SystemEvents.RaiseEvent(Boolean, System.Object, System.Object[])+0x10f
14 0018e920 04b85989 System_ni!Microsoft.Win32.SystemEvents.OnUserPreferenceChanged(Int32, IntPtr, IntPtr)+0x77
15 0018e98c 009f09e4 System_ni!Microsoft.Win32.SystemEvents.WindowProc(IntPtr, Int32, IntPtr, IntPtr)+0x189
WARNING:Frame IP not in any known module. Following frames may be wrong.
16 0018e9b0 770662fa 0x9f09e4
17 0018e9dc 77066d3a USER32!InternalCallWinProc+0x23
18 0018ea54 770677c4 USER32!UserCallWinProcCheckWow+0x109
19 0018eab4 7706788a USER32!DispatchMessageWorker+0x3bc
1a 0018eac4 00491a32 USER32!DispatchMessageW+0xf
1b 0018eae0 7aed8cee CLRStub[StubLinkStub]@491a32
1c 0018eb94 7aed8957 System_Windows_Forms_ni!System.Windows.Forms.Application+ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32, Int32, Int32 +0x24e
1d 0018ebec 7aed87a1 System_Windows_Forms_ni!System.Windows.Forms.Application+ThreadContext.RunMessageLoopInner(Int32, System.Windows.Forms.ApplicationContext)+0x177
1e 0018ec1c 7ae95911 System_Windows_Forms_ni!System.Windows.Forms.Application+ThreadContext.RunMessageLoop(Int32, System.Windows.Forms.ApplicationContext)+0x61
1f 0018ec34 004600ae System_Windows_Forms_ni!System.Windows.Forms.Application.Run(System.Windows.Forms.Form)+0x31
20 0018ec40 79d61b4c UserPreferencesHang!UserPreferencesHang.Program.Main()+0x3e

You can see in the above callstack the same sequence of events I described earlier. In this particular case, a WM_SYSCOLORCHANGE message was dispatched to the window procedure.

The window procedure handles this by eventually calling Microsoft.Win32.SystemEvents+SystemEventInvokeInfo.Invoke. This obtains the thread’s SynchronizationContext (in this case, the WindowsFormsSynchronizationContext) and calling its Send method. This calls into Control.Invoke, which then calls into System.Threading.WaitHandle.WaitOne, etc. which we eventually see stuck in kernel32!WaitForMultipleObjects. Since the target thread isn’t pumping window messages, we are blocked indefinitely. To determine the target thread, we need to do some managed debugging using the managed debugger extension (sos.dll).

First, load sos.dll into the debugger using the .loadby command. NOTE: If using .NET 4.0 / 4.5, use "clr" instead of "mscorwks" below.

 0:000> .loadby sos.dll mscorwks

Let’ s examine the thread’s managed stack objects, looking for the lowest most instance of a WindowsFormsSynchonizationContext object.

0:000>!dumpstackobjects
OS Thread Id: 0x19ac (0)
ESP/REG  Object   Name
0018e5e0 0259dd78 System.Windows.Forms.WindowsFormsSynchronizationContext
0018e66c 025ebbc4 System.Threading.ManualResetEvent
0018e680 025ebbc4 System.Threading.ManualResetEvent
0018e6e8 025ebbc4 System.Threading.ManualResetEvent
0018e6ec 025de4ac System.Windows.Forms.Application+MarshalingControl
0018e6f8 025ebbc4 System.Threading.ManualResetEvent
0018e700 025de4ac System.Windows.Forms.Application+MarshalingControl
0018e730 025ebbdc Microsoft.Win32.SafeHandles.SafeWaitHandle
0018e760 025ebbc4 System.Threading.ManualResetEvent
0018e778 025de4ac System.Windows.Forms.Application+MarshalingControl
0018e78c 025eba7c System.Windows.Forms.Control+MultithreadSafeCallScope
0018e7cc 025de514 System.Windows.Forms.PropertyStore
0018e7d4 025de4ac System.Windows.Forms.Application+MarshalingControl
0018e7d8 025ebb10 System.Collections.Queue
0018e7dc 025de4ac System.Windows.Forms.Application+MarshalingControl
0018e7e0 025ebad0 System.Windows.Forms.Control+ThreadMethodEntry
0018e7e4 025eba88 System.Threading.ExecutionContext
0018e7e8 025de4ac System.Windows.Forms.Application+MarshalingControl
0018e7ec 025de4ac System.Windows.Forms.Application+MarshalingControl
0018e7f4 025de4ac System.Windows.Forms.Application+MarshalingControl
0018e7fc 025de4ac System.Windows.Forms.Application+MarshalingControl
0018e824 025eba7c System.Windows.Forms.Control+MultithreadSafeCallScope
0018e828 025eba48 System.Threading.SendOrPostCallback
0018e82c 025de4ac System.Windows.Forms.Application+MarshalingControl
0018e83c 025eba68 System.Object[]   (System.Object[])
0018e840 025eba48 System.Threading.SendOrPostCallback
0018e844 025eba7c System.Windows.Forms.Control+MultithreadSafeCallScope
0018e85c 025de014 System.Threading.Thread
0018e860 025eb558 System.Object[]   (System.Object[])
0018e864 025de4ac System.Windows.Forms.Application+MarshalingControl
0018e868 025eba48 System.Threading.SendOrPostCallback
0018e874 025eba68 System.Object[]   (System.Object[])
0018e878 025eba68 System.Object[]   (System.Object[])
0018e87c 025eba48 System.Threading.SendOrPostCallback
0018e880 025de3f8 System.Windows.Forms.WindowsFormsSynchronizationContext
<snip>

I’ve highlighted the relevant WindowsFormsSynchronizationContext object above. Now we can dump it out to examine it.

0:000>!dumpobj 025de3f8
Name: System.Windows.Forms.WindowsFormsSynchronizationContext
MethodTable: 7af215b0
EEClass: 7ad06a94
Size: 20(0x14) bytes

(C:\Windows\assembly\GAC_MSIL\System.Windows.Forms\2.0.0.0__b77a5c561934e089\System.Windows.Forms.dll)
Fields:
      MT   Field   Offset                 Type VT     Attr   Value Name
79780f9c  40005c8       4         System.Int32  1 instance        0 _props
7af1f750  4003b24       8 ...ows.Forms.Control  0 instance 025de4ac controlToSendTo
7918a4d8  4003b25       c System.WeakReference  0 instance 025de40c destinationThreadRef
791647f4  4003b26       0       System.Boolean  1 TLstatic dontAutoInstall
    >> Thread:Value 19ac:0 18f0:0<<
791647f4  4003b27       4       System.Boolean  1 TLstatic inSyncContextInstallation
    >> Thread:Value 19ac:0 18f0:0<<
7918a00c  4003b28       8 ...ronizationContext  0 TLstatic  previousSyncContext
    >> Thread:Value 19ac:0259dcd4 18f0:025de354 << 

We are interested in the destinationThreadRef member, which will be a WeakReference that points to our Thread of interest. Let’s dump the address of the destinationThreadRef member.

0:000> !dumpobj 025de40c
Name: System.WeakReference
MethodTable: 7918a4d8
EEClass: 78f4a22c
Size: 16(0x10) bytes 
(C:\Windows\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)

Fields:
      MT   Field   Offset                 Type VT     Attr   Value Name
791935f0  40005b4       4        System.IntPtr  1 instance  1c1778 m_handle
791647f4  40005b5       8       System.Boolean  1 instance        0 m_IsLongReference
 

The m_handle member is the address of a pointer to our Thread. So we must take this address, and look to see what address it points to.

0:000> dd 1c1778 l1
001c1778  025de014

Now we can dump the object located at that address to get our System.Threading.Thread object.

0:000>!dumpobj 025de014
Name: System.Threading.Thread
MethodTable: 791912fc
EEClass: 78f4d9a4
Size: 56(0x38) bytes
(C:\Windows\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)

Fields:
      MT   Field   Offset                 Type VT     Attr   Value Name
7918210c  400063f       4 ....Contexts.Context  0 instance 00000000 m_Context
7918da1c  4000640       8 ....ExecutionContext  0 instance 025de360 m_ExecutionContext
79190d28  4000641       c        System.String  0 instance 00000000 m_Name
7919118c  4000642      10      System.Delegate  0 instance 00000000 m_Delegate
7918a424  4000643      14    System.Object[][]  0 instance 025de2a0 m_ThreadStaticsBuckets
79192ec4  4000644      18       System.Int32[]  0 instance 025de344 m_ThreadStaticsBits
79193924  4000645      1c ...ation.CultureInfo  0 instance 00000000 m_CurrentCulture
79193924  4000646      20 ...ation.CultureInfo  0 instance 00000000 m_CurrentUICulture
79190944  4000647      24        System.Object  0 instance 00000000 m_ThreadStartArg
791935f0  4000648      28        System.IntPtr  1 instance  6dc270 DONT_USE_InternalThread
79192f74  4000649      2c         System.Int32  1 instance        2 m_Priority
79192f74  400064a      30         System.Int32  1 instance        3 m_ManagedThreadId
79169944  400064b     16c ...LocalDataStoreMgr  0   shared  static s_LocalDataStoreMgr
    >> Domain:Value  00681bd8:025e2f54 <<
79190944  400064c     170        System.Object  0  shared   static s_SyncObject
    >> Domain:Value  00681bd8:02532260 << 

The m_ManagedThreadId member above represents the managed thread ID of the thread of interest. So now we can dump all managed threads, looking for the thread with that ID. Note that we must look at the “ID” column in the following output for the managed thread ID.

IMPORTANT: The ID column from the !threads output below represents the value in hexadecimal. Therefore, it is extremely important to convert the m_ManagedThreadId field from the output above to hex in order to look for the right thread. To do that, simply enter the following command into your debugger, using the integer value of the thread Id above. In this case, we use 0n3 to specify we want to see the hex representation of the integer value 3.

0:000> ?0n3
Evaluate expression: 3 = 00000003

In this case, 3 is the same representation in both decimal and hex, so that is what we look for in the output below.

0:000>!threads
ThreadCount: 3
UnstartedThread: 0
BackgroundThread: 2
PendingThread: 0
DeadThread: 0
Hosted Runtime: no
                                     PreEmptive   GC Alloc          Lock  
       ID OSID ThreadOBJ    State    GC       Context       Domain  Count APT Exception
   0    1 19ac 00685e30   2006020 Enabled  025f0b9c:025f1fe8 00681bd8     0 STA
   2    2 2124 006a1f80      b220 Enabled  00000000:00000000 00681bd8     0 MTA (Finalizer)
   4    3 18f0 006dc270   180b220 Enabled  025e3d90:025e3fe8 00681bd8     0 MTA (Threadpool Worker) 

Notice that the line with ID 3 (again, that’s our managed thread ID), corresponds to debugger thread 4 in the output above. That is the thread of interest that owns the window. Before switching to that thread in the debugger, note that the thread has is an MTA thread created in the .NET Threadpool. From this alone, we know there are potential problems. First, Windows Forms are only supported on threads using an STA model, and there are places in Winforms that may crash if used on a non-STA thread. The other thing we should be able to assume right away, is that since this is a .NET threadpool thread, it almost certainly will not be pumping messages. So let’s switch to that thread and find out.

 0:000> ~4s
eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=00000248 edi=081cf5dc
eip=77b9f8b1 esp=081cf594 ebp=081cf600 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
ntdll!ZwWaitForSingleObject+0x15:
77b9f8b1 83c404          add     esp,4

0:004> knL
 # ChildEBP RetAddr
00 081cf594 75340a91 ntdll!ZwWaitForSingleObject+0x15
01 081cf600 758a1194 KERNELBASE!WaitForSingleObjectEx+0x98
02 081cf618 79d65497 KERNEL32!WaitForSingleObjectExImplementation+0x75
03 081cf65c 79d653e3 mscorwks!CLREventWaitHelper+0x2f
04 081cf6ac 79d65402 mscorwks!CLREvent::WaitEx+0x117
05 081cf6c0 79dcb75f mscorwks!CLREvent::Wait+0x17
06 081cf740 79dcbbed mscorwks!ThreadpoolMgr::SafeWait+0x73
07 081cf7a4 79ec305a mscorwks!ThreadpoolMgr::WorkerThreadStart+0x11c
08 081cf8c8 758a339a mscorwks!Thread::intermediateThreadProc+0x49
09 081cf8d4 77bb9ef2 KERNEL32!BaseThreadInitThunk+0xe
0a 081cf914 77bb9ec5 ntdll!__RtlUserThreadStart+0x70
0b 081cf92c 00000000 ntdll!_RtlUserThreadStart+0x1b

As you can see from the output above, this thread is pretty much what we thought it would be. It is a .NET threadpool thread sitting in WaitForSingleObject, waiting for the CLR to hand it some work. It’s definitely not pumping window messages, so the UI thread stays blocked indefinitely. So the resolution to this issue is to do what KB article 943139 mentions: create your Windows Forms controls on an STA thread which routinely pumps messages for the duration of the thread. 

We know the resolution to the issue, but what if you don’t know what code was responsible for creating the Control(s) on the worker thread? This is really the crux of the problem. The key is being able to find what code is creating these Controls, and the rest of this blog will focus on how to determine that.

Using Windbg to Determine When Windows Forms Controls Are Created

It is certainly easy enough to set a breakpoint on the constructor for System.Windows.Forms.Form or System.Windows.Forms.Control, but the problem with that approach is that it will be hit every time your main UI thread creates an instance of one of these objects. We want to limit our output to determining when code is creating Controls on threads other than your primary UI thread. The easiest way to do that is to set a breakpoint on the constructor for the System.Windows.Forms.Application+MarshalingControl type. Whenever any Control is created, Windows Forms first looks to see if it needs to create an instance of the MarshalingControl discussed earlier. The MarshalingControl is created once per thread, the first time anything creates an instance of a Control on that thread. This will track the first time any Control is created on your main UI thread, but also the first time a Control is created on any other thread as well. This should serve to achieve our goal of determining where Controls are being created on a per thread basis, while limiting the amount of unnecessary output.

To do this, start your Windows Forms application and attach Windbg. Once attached, make sure your symbol path is set as appropriate and reload symbols. You can set it to the public Microsoft symbol server, or use your own internal symbol path.

0:000>.sympath srv*msdl.microsoft.com/download/symbols
Symbol search path is: srv*msdl.microsoft.com/download/symbols
Expanded Symbol search path is: srv*msdl.microsoft.com/download/symbols

0:000>.reload

Reloading current modules
.................................

 Load the SOS.dll debugger extension from the folder where the CLR (mscorwks.dll) is located. Note: if debugging .NET 4.0 or later, you would use “clr” instead of “mscorwks” in the command below.

0:000>.loadby sos.dll mscorwks 

Locate the address of the constructor for System.Windows.Forms.Application+MarshalingControl. We do this using !name2ee along with the module name for the DLL (you can use * to search all modules), and the fully qualified method name.

0:000>!name2ee System_Windows_Forms_ni System.Windows.Forms.Application+MarshalingControl..ctor

Module: 7a981000 (System.Windows.Forms.dll)
Token: 0x060017d8
MethodDesc: 7a99cbcc
Name: System.Windows.Forms.Application+MarshalingControl..ctor()
JITTED Code Address: 7ab46fc0

7ab46fc0 is the address we want to place a breakpoint on. This breakpoint should be hit the first time a Control is created on a thread. It will dump the managed callstack to the output window and then continue on with normal execution.

0:000> bp 7ab46fc0 ".echo MarshalingControl creation detected. Callstack follows.;!clrstack;.echo ==============================;gc"

Then run the application and operate under normal conditions to see what output you receive.

0:000> g
MarshalingControl creation detected. Callstack follows.
OS Thread Id: 0x410 (4)
ESP       EIP
07b8ed34 7ab46fc0 System.Windows.Forms.Application+MarshalingControl..ctor()
07b8ed38 7ab75b33 System.Windows.Forms.Application+ThreadContext.get_MarshalingControl()
07b8ed68 7ab75713 System.Windows.Forms.WindowsFormsSynchronizationContext..ctor()
07b8ed7c 7ab75615 System.Windows.Forms.WindowsFormsSynchronizationContext.InstallIfNeeded()
07b8eda8 7ab746e8 System.Windows.Forms.Control..ctor(Boolean)
07b8ee48 7ab7c3e4 System.Windows.Forms.ScrollableControl..ctor()
07b8ee64 7ab7c2f7 System.Windows.Forms.ContainerControl..ctor()
07b8ee78 7ab743db System.Windows.Forms.Form..ctor()
07b8ee94 005a0478 UserPreferencesHang.ProgressForm..ctor()
07b8eea0 005d046a UserPreferencesHang.Form1.DisplayProgressForm()
07b8eeb4 005d041b UserPreferencesHang.Form1.backgroundWorker1_DoWork(System.Object, System.ComponentModel.DoWorkEventArgs)
07b8eec8 7a84d3ed System.ComponentModel.BackgroundWorker.OnDoWork(System.ComponentModel.DoWorkEventArgs)
07b8eee0 7a84d14e System.ComponentModel.BackgroundWorker.WorkerThreadStart(System.Object)
07b8f308 797e1b4c [HelperMethodFrame_PROTECTOBJ: 07b8f308] System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr, System.Object[], System.Object, Int32, Boolean, System.Object[] ByRef)
07b8f44c 78af95c3 System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(System.RuntimeMethodHandle, System.Object[], System.Object, Int32, Boolean, System.Object[] ByRef)
07b8f470 790e273a System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(System.Runtime.Remoting.Messaging.IMessage, System.Runtime.Remoting.Messaging.IMessageSink)
07b8f4d0 790f646a System.Runtime.Remoting.Proxies.AgileAsyncWorkerItem.DoAsyncCall()
07b8f4dc 790f64a0 System.Runtime.Remoting.Proxies.AgileAsyncWorkerItem.ThreadPoolCallBack(System.Object)
07b8f4e4 78b4a18f System.Threading._ThreadPoolWaitCallback.WaitCallback_Context(System.Object)
07b8f4ec 78b604bf System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
07b8f504 78b4a6f3 System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(System.Threading._ThreadPoolWaitCallback)
07b8f518 78b4a589 System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(System.Object)
07b8f6a8 797e1b4c [GCFrame: 07b8f6a8]

The output above shows where this sample application was using the BackgroundWorker component, and handling it's DoWork event. The handler for this is fired on an MTA thread in the .NET Threadpool. We see where the BackgroundWorker's event handler called into some custom code in UserPreferencesHang.Form1.DisplayProgressForm(), which then created an instance of a custom Windows Form. From this output, now we know where to fix our code to prevent it from creating the Form on this background thread. In this case, the fix would be to use Control.Invoke (or BeginInvoke) to marshal the call of the DisplayProgressForm method over to the UI thread.

Final Thoughts

We have explained how .NET Windows Forms applications can become unresponsive when handling the Microsoft.Win32.SystemEvents.UserPreferenceChanged event. We have demonstrated how to debug an application already in this state, and more importantly, how to use the debugger to track the creation of Windows Forms on other threads. This should go a long way to helping you diagnose and correct any applications that are suffering from this condition.

Happy Hunting!