If you use IronPython to call AutomationElement.FromHandle, it will return null. This happens because FromHandle uses Assembly.GetCallingAssembly and expects to get a statically compiled assembly with references to the correct version of the UIAutomation libraries. However, since IronPython code gets compiled on the fly using Reflection.Emit and DynamicMethods, it confuses AutomationElement.
This UIAutomation team knows about the issue and will be fixing it. I am not sure which particular release will have the fix. The workaround is to narrow down the specific call which is failing, and then perform that call from C#/VB.Net assembly.
I had added this comment to the Assembly.GetCallingAssembly docs. I am including it here to explain the details of the problem
The common case is for the caller to have directly called currently executing method. However, the caller may have invoked the currently executing method via a delegate, or in a late-bound way using MethodBase.Invoke. The delegate or the MethodInfo might have been created by one assembly, and then another assembly could have invoked it. GetCallingAssembly will not indicate who created the delegate or the MethodInfo. So if you use GetCallingAssembly to make security decisions, you will need to be extremely careful to ensure that you handle the cases of late-bound invocation.
Another unusual case is if the caller is a DynamicMethod. Since DynamicMethods can potentially be associated with arbitrary assemblies during creating, GetCallingAssembly will return the associated assembly.