Text cursor indicator crashing our app?

Question

I have reports from customers that using the text cursor indicator results in our app crashing multiple times each day. I have turned it on and I do trap some access violations during shutdown of our app. We are heavy users of OpenGL but I don't know if there is any connection with that. What I do find is we are "randomly" crashing at shutdown if I exercise UI that ends up getting this cursor indicator displayed. I do see issues with the indicator "blobs" at the top and bottom of the cursor, for example, if I move a dialog with an edit control or combobox on it while the indicator is displayed (and not just in our app).

I suspect some sort of threading issue due to how random this is. But, I have a specific question, is UIAutomation.dll involved in any way with this feature? So far, my crashes are almost always in UIAutomation. The crash occurs if we do a PeekMessage during shutdown. I have verified after a crash that the window handle we pass to PeekMessage is still valid using Spyxx. Below is an example stack crash. The "fix" so far with our customers, is the same with AutoCad customers that are crashing when this is turned on - turn it off.

UIAutomationCore.dll!std::_Hash<class std::_Umap_traits<unsigned long,class CApartmentTracker *,class std::_Uhash_compare<unsigned long,struct std::hash<unsigned long>,struct std::equal_to<unsigned long> >,class std::allocator<struct std::pair<unsigned long const ,class CApartmentTracker *> >,0> >::lower_bound(unsigned long const &)	Unknown    
UIAutomationCore.dll!MsaaProxy::~MsaaProxy()	Unknown    
UIAutomationCore.dll!MsaaProxy::`vector deleting destructor'(unsigned int)	Unknown    
UIAutomationCore.dll!ComInnerStub::Release(void)	Unknown    
UIAutomationCore.dll!UiaNode::ProviderInfo::~ProviderInfo(void)	Unknown    
UIAutomationCore.dll!`eh vector destructor iterator'(void *,unsigned __int64,unsigned __int64,void (*)(void *))	Unknown    
UIAutomationCore.dll!UiaNode::`vector deleting destructor'(unsigned int)	Unknown    
UIAutomationCore.dll!UiaNode::Release(void)	Unknown    
UIAutomationCore.dll!ReleaseOnCorrectContext_Callback()	Unknown    
UIAutomationCore.dll!ComInvoker::CallTarget()	Unknown    
UIAutomationCore.dll!ReleaseCollection::DispatchReleases()	Unknown    
UIAutomationCore.dll!ChannelBasedServerConnection::ReleaseObjects()	Unknown    
UIAutomationCore.dll!HookBasedServerConnection::`vector deleting destructor'(unsigned int)	Unknown    
UIAutomationCore.dll!RefcountBase::Release(void)	Unknown    
UIAutomationCore.dll!HookBasedServerConnectionManager::HookCallback()	Unknown    
UIAutomationCore.dll!HookUtil<&HookBasedClientConnection::HookCallback(void *,unsigned long,void * *,unsigned long *,void * *),0>::CallOut(void *,unsigned long,void * *,unsigned long *,void * *)	Unknown    
UIAutomationCore.dll!HandleSyncHookMessage()	Unknown    
UIAutomationCore.dll!HookUtil<&HookBasedClientConnection::HookCallback,0>::CallWndProc()	Unknown    
user32.dll!fnHkINLPCWPSTRUCTW()	Unknown    
user32.dll!__fnDWORD ()	Unknown    
ntdll.dll!00007fffd9090b74()	Unknown    
win32u.dll!NtUserPeekMessage ()	Unknown    
user32.dll!_PeekMessage()	Unknown    
user32.dll!PeekMessageW()	Unknown    

Answer 1

I created a MFC app and tried to duplicate in it. So far, I haven't crashed. the UIAutomationCore.dll loads into it. However, the cursor indicator is erratic in that app. The default code generated has some docking panes with UI in them and sometimes I see the indicator flash when I am in a control that lets me type text but usually it doesn't show up. I added an edit box to the "About" dialog and it does show up there. If I run file open, it shows up there.

Like our app, once the DLL loads and I click in boxes where it may show up, I get these exceptions:

Exception thrown at 0x00007FFFD6D04FD9 in MFCApplication7.exe: Microsoft C++ exception: wil::ResultException at memory location 0x0000006DFA0FCD30.

Sometimes I have a stream of those output to the debugger window. For this MFC app, if I run the file open dialog (standard Windows dialog), if I click in the edit field and then dismiss the dialog, a number of those exceptions occur. The seem benign. Probably just noise to clutter up my output window so I have a hard time finding my own messages. But, of course, I don't know if they are significant as I don't have the MS code.

Our app is not something I can provide a link too. Way too complicated and it has 25 million+ lines of code. Maybe MS can drop the UIAutomationCore code so I can step thru it and find the point where someone is failing to check for a nullptr as the assembly code is showing (me at least) that someone is trying to access instance data of some object that is sometimes null.

If this is a race condition, the MFC app may not be complex enough to expose that fact. But someone with the code should be easily able to examine the code and find where this AV can occur.

Also, I used google and found a number of posts that indicate this same setting is crashing other apps. So, bug there is and I think it is a simple failure to examine the value of some pointer that is null.

Answer 2

Thanks AnnaXiu,

The article doesn't mention Windows 10 or Windows 11. However, the version of the DLL I have is 7.2.19041.16 and the article says the DLL version is 7.2.9200.xxx (xxx varies). Those versions are all much older than mine.

Sort of funny today though. I have three monitors and am working via RDP and the indicator as I type this on my right most monitor is dutifully displaying way to the left of where this window is. I also see in Visual Studio that scrolling a window leaves the cursor doesn't move. Sometimes I can move or size a window and the indicator doesn't move. Sometimes when I set focus or move click to move the cursor, the indicator doesn't show up but it will show up at some point when I am typing. This feature is quite erratic. Maybe it was hurried into the OS before it was ready for prime time. Smacks of an "Agile" development process :)

I am still debugging the issue on my side and I have found that I can crash the app without shutting down. And, if I have the setting on when I start the app, I crash much more frequently than if I start the app and later turn the setting on. I am crashing with a debug build and now the crash isn't related to PeekMessage at shutdown. Instead, I have windows we destroy and then we delete the memory, which gets poisoned by the debugger. When the crash occurs, the object (MFC CWnd based) is somehow resurrected and we crash quickly as the memory is all 0xdddddd... - poisoned with the "Deleted" memory fill. I'm not crashing at all if I turn the indicator off but now I am looking for issues with memory management. Perhaps this setting has exposed some memory corruption issue in our app or some component we use. Being so random it has eluded me so far and the crash is in a component we don't write but I do have code for. Like UIAutomationCore, it makes use of hooks (extensively) so tracing is complicated. I'm using trace statements to track window and memory allocations and deallocations and I hope to get to the bottom of this. I have a number of dump files from customers and UIAutomationCore.DLL is a common factor.

You link does help as yesterday I was examing crash dumps for crashes we had no fix for and and which have this DLL in them. Some went back much further in time, well before this setting was released. So, it might have been the cause of some of those crashes. These crashes show up on a user's box and then go away when rebuilding the box or recreating the user's profile. That may indicate the fixed DLL in your link was installed. Even now we find a common "fix" is rebuild or recreating the profile. I am reaching out to customers that have done so to ask if they were using this setting or not before the rebuild.

Answer 3

Yet another crash related to Accessible objects. From where does this UIAutomationCore get this VARIANT, which is simply invalid for the call being made?

ToolkitPro2010vc160x64UD.dll!CXTPAccessible::XAccessible::accLocation(long *, long *, long *, long *, tagVARIANT) Line 1289 C++

oleacc.dll!00007fffc3bbb4b0()   Unknown  
oleacc.dll!00007fffc3bbb2b8()   Unknown  
UIAutomationCore.dll!AccUtils::accLocation()    Unknown  
UIAutomationCore.dll!MsaaProxy::GetTempIdString(unsigned short * *) Unknown  
UIAutomationCore.dll!UiaNode::Provider_GetTempIdString(unsigned short * *)  Unknown  
UIAutomationCore.dll!ComInvoker::CallTarget()   Unknown  
UIAutomationCore.dll!InProcClientAPIStub::InvokeInProcAPI(struct ITargetContextInvoker *,enum Protocol_MethodId,...)    Unknown  
UIAutomationCore.dll!RemoteUiaNodeStub::Incoming_GetTempIdString(class UiaNode *,struct ITargetContextInvoker *,class IServerConnection *,class MessageParser &,class MessageBuilder &) Unknown  
UIAutomationCore.dll!RemoteUiaNodeStub::OnMessage() Unknown  
UIAutomationCore.dll!InvokeOnCorrectContext_Callback()  Unknown  
UIAutomationCore.dll!ComInvoker::CallTarget()   Unknown  
UIAutomationCore.dll!ProcessIncomingRequest()   Unknown  
UIAutomationCore.dll!HookBasedServerConnectionManager::HookCallback()   Unknown  
UIAutomationCore.dll!HookUtil<&HookBasedClientConnection::HookCallback(void *,unsigned long,void * *,unsigned long *,void * *),0>::CallOut(void *,unsigned long,void * *,unsigned long *,void * *)    Unknown  
UIAutomationCore.dll!HandleSyncHookMessage()    Unknown  
UIAutomationCore.dll!HookUtil<&HookBasedClientConnection::HookCallback,0>::CallWndProc()  Unknown  
user32.dll!fnHkINLPCWPSTRUCTW() Unknown  
user32.dll!__fnDWORD () Unknown  
ntdll.dll!KiUserCallbackDispatcherContinue ()   Unknown  
win32u.dll!NtUserGetMessage ()  Unknown  
user32.dll!GetMessageW()    Unknown  

In this case this hooker is making calls while we are in the middle of a UI transition and it appears to be working with stale data. We have the Office type of UI - command ribbon and tabs and this index is a tab index - for the UI we destroyed, the tabs are gone and new ones are being created.

Someone please tell me there is a way to stop this thing from injecting itself into our process so I don't have to keep telling customers to turn this thing off for the entire machine!

Answer 4

Now here's an interesting crash while I was running another app and opening and closing a document. This time the MS rich edit control caused an AV:

riched20.dll!00007fff7f854962() Unknown  
riched20.dll!00007fff7f8806b3() Unknown  
riched20.dll!00007fff7f8650b1() Unknown  
UIAutomationCore.dll!RichEditProxy::~RichEditProxy(void)    Unknown  
UIAutomationCore.dll!RichEditProxy::`vector deleting destructor'(unsigned int)  Unknown  
UIAutomationCore.dll!RefcountBase::Release(void)    Unknown  
UIAutomationCore.dll!UiaNode::ProviderInfo::~ProviderInfo(void) Unknown  
UIAutomationCore.dll!`eh vector destructor iterator'(void *,unsigned __int64,unsigned __int64,void (*)(void *)) Unknown  
UIAutomationCore.dll!UiaNode::`vector deleting destructor'(unsigned int)    Unknown  
UIAutomationCore.dll!UiaNode::Release(void) Unknown  
UIAutomationCore.dll!ReleaseOnCorrectContext_Callback() Unknown  
UIAutomationCore.dll!ComInvoker::CallTarget()   Unknown  
UIAutomationCore.dll!ReleaseCollection::DispatchReleases()  Unknown  
UIAutomationCore.dll!ChannelBasedServerConnection::ReleaseObjects() Unknown  
UIAutomationCore.dll!HookBasedServerConnection::`vector deleting destructor'(unsigned int)  Unknown  
UIAutomationCore.dll!RefcountBase::Release(void)    Unknown  
UIAutomationCore.dll!HookBasedServerConnectionManager::HookCallback()   Unknown  
UIAutomationCore.dll!HookUtil<&HookBasedClientConnection::HookCallback(void *,unsigned long,void * *,unsigned long *,void * *),0>::CallOut(void *,unsigned long,void * *,unsigned long *,void * *)    Unknown  
UIAutomationCore.dll!HandleSyncHookMessage()    Unknown  
UIAutomationCore.dll!HookUtil<&HookBasedClientConnection::HookCallback,0>::CallWndProc()  Unknown  
user32.dll!fnHkINLPCWPSTRUCTW() Unknown  
user32.dll!__fnDWORD () Unknown  
ntdll.dll!KiUserCallbackDispatcherContinue ()   Unknown  
win32u.dll!NtUserPeekMessage () Unknown  
user32.dll!_PeekMessage()   Unknown  
user32.dll!PeekMessageW()   Unknown  

mfc140ud.dll!CWinThread::Run() Line 617 C++

mfc140ud.dll!CWinApp::Run() Line 787    C++  

This is the instruction and RAX is 0xdddddddddddddddd - Debug memory poison pill:
mov rax,qword ptr [rax+10h]

So, kaboom.

Answer 5

I have been informed by another programmer that UIAutomation is leaking objects obtained via WM_GETOBJECT. I have not verified that but I was wondering. In the past we have had a terrible time with .NET automation clients. Primarily because .NET doesn't release COM objects until some non-deterministic time when .NET decides (if ever) to run garbage collection. I don't see GC in the call stacks I have observed but does UIAutomation use .NET at all to work with COM objects?