Bdtjtk

Both the callback and the AccessibleObjectFromEvent call appear to be working as intended, and I'm not using any locking mechanisms, but if AccessibleObjectFromEvent is present in the callback the winforms form will occasionally lock up.

I noticed when it freezes it has this odd property where right-clicking on its taskbar icon unfreezes it.

Pausing with the debugger just takes you to Application.Run(new Form1()), and nothing appears blocked on the .Net side - the debugger's window updates can even trigger some Active Accessibility events and then let you step through those events in the callback - working - all while the form remains frozen!

I note that AccessibleObjectFromEvent works by sending a WM_GETOBJECT message, but the .Net side is never stuck at the AccessibleObjectFromEvent call, and calling AccessibleObjectFromEvent from inside a SetWinEventHook callback is AFAIK a normal way to do Active Accessibility.

I've not noticed any correlation with Active Accessibility events when it freezes, but I don't really have enough information to rule that out. I also tried it compiled x86 (instead of Any), and that made no difference.

I boiled it down to its most minimal form:

using Accessibility;

using System;

using System.Diagnostics;

using System.Runtime.InteropServices;

using System.Windows.Forms;



namespace WindowsFormsApp1 {

    static class Program {



        // PInvoke declarations, see http://www.pinvoke.net/default.aspx/user32.setwineventhook

        [DllImport("user32.dll")]

        static extern IntPtr SetWinEventHook(uint eventMin, uint eventMax, IntPtr hmodWinEventProc, WinEventDelegate lpfnWinEventProc, uint idProcess,  uint idThread, WinEventFlag dwFlags);

        public delegate void WinEventDelegate(IntPtr hWinEventHook, uint eventType, IntPtr hwnd, int idObject, int idChild, uint dwEventThread, uint dwmsEventTime);

        [DllImport("oleacc.dll")]

        public static extern uint AccessibleObjectFromEvent(IntPtr hwnd, uint dwObjectID, uint dwChildID, out IAccessible ppacc, [MarshalAs(UnmanagedType.Struct)] out object pvarChild);



        [Flags]

        public enum WinEventFlag : uint {

            /// <summary>Events are ASYNC</summary>

            Outofcontext   = 0x0000,

            /// <summary>Don't call back for events on installer's thread</summary>

            Skipownthread  = 0x0001,

            /// <summary>Don't call back for events on installer's process</summary>

            Skipownprocess = 0x0002,

            /// <summary>Events are SYNC, this causes your dll to be injected into every process</summary>

            Incontext      = 0x0004

        }



        static IntPtr hookHandle = IntPtr.Zero;

        static GCHandle garbageCollectorHandle;



        static void AccessibilityEventHandler(IntPtr hWinEventHook, uint eventType, IntPtr hWnd, int idObject, int idChild, uint dwEventThread, uint dwmsEventTime) {

            try {

                object objChild = null;

                IAccessible accWindow = null;

                AccessibleObjectFromEvent(hWnd, (uint)idObject, (uint)idChild, out accWindow, out objChild);

                Debug.WriteLine("Hook was invoked");

            } catch (Exception ex) {

                Debug.WriteLine("Exception " + ex);

            }

        }



        [STAThread]

        static void Main() {

            WinEventDelegate callback = new WinEventDelegate(AccessibilityEventHandler);

            // Use the member garbageCollectorHandle to keep the delegate object in memory. Might not be needed, and can't properly pin it because it's not a primitive type.

            garbageCollectorHandle = GCHandle.Alloc(callback);



            SetWinEventHook(

                0x7546, // eventMin (0x7546 = PropertyChanged_IsOffscreen)

                0x7546, // eventMax

                IntPtr.Zero,

                callback,

                0,

                0,

                WinEventFlag.Outofcontext

            );



            // Two hooks are not necessary to cause a freeze, but with two it can happen much faster - sometimes within minutes

            SetWinEventHook(

                0x0001, // eventMin (0x0001 = System_Sound)

                0x0001, // eventMax

                IntPtr.Zero,

                callback,

                0,

                0,

                WinEventFlag.Outofcontext

            );



            Application.EnableVisualStyles();

            Application.SetCompatibleTextRenderingDefault(false);

            Application.Run(new Form1());

        }

    }

}

With such a minimal app it's harder to notice the message pump freeze, but you won't be able to drag the window or bring it to the foreground once it's locked. The bug is intermittent, often it happens within 5 minutes, sometimes it takes so long I give up, if you leave it overnight and the form is still responsive in the morning then it might depend on machine/OS (tried on Win 10.0.17174 and 10.0.17763, .net 4.5.2 and 4.6.1).

I'm 99% sure the call to AccessibleObjectFromEvent is required for the app to freeze, but with intermittent freezes there's no way to absolutely know for sure.

Reentrancy

Following Jimi's suggestions in the comments, I ran the minimal app with the flags

WinEventFlag.Outofcontext | WinEventFlag.Skipownthread | WinEventFlag.Skipownprocess

It took a while to freeze, but has still frozen. The Debug.WriteLine() calls indicate it's still responding to Active Accessibility events normally - i.e. no recursive busy-loop is happening through that callback (at least not now that I'm looking), but the form is frozen. It's using 0% CPU in the task manager.

The freeze is slightly different now, in that the task manager doesn't list it as "not responding" and I can bring it to the foreground by left-clicking the taskbar icon - normally the taskbar can't even bring it to the foreground. However the form still can't be moved or resized, and you can't bring the form to the foreground by clicking on it.

I'd also added some Debug.WriteLine in front of the AccessibleObjectFromEvent call, and tracked reentrancy depth, I can see that it is occasionally reentrant, but usually to a depth of only one before unwinding, and no deeper than 13 before fully unwinding. This appears to be caused by there being many events already in the message queue, rather than the hook handler recursively causing events it must then handle. The UI is currently frozen and the hook handler is 0 deep (i.e. not currently reentrant).