Following installation "run as administrator" neither runing OpenOffice as administrator or user enabled the AT.

The accprobe.exe utility became non-functional and had to be restarted. But evan after restart would not see the AOO session.  No affect on NVDA--except that it also would not register any elements of the AOO session except the frame.

System reboot was required for Accprobe.exe to again be stable. But no change in accessing the AOO session.

I cannot reproduce this. This build works just as well as the previous build for me.

You note that you did a clean install, but I'm curious as to how clean. Apparently, uninstalling previous builds didn't unregister UAccCOM.dll properly, which can cause all sorts of trouble, particularly as the new build doesn't register UAccCOM.dll at all (because it no longer needs to). If you suspect this might be the case, I'd recommend you install the old build, regsvr32 /u UAccCOM.dll, then reinstall the new build.

(In reply to James Teh from comment #2)
> If you suspect this might be the case, I'd recommend you install the old
> build, regsvr32 /u UAccCOM.dll, then reinstall the new build.
Correction: uninstall the new build, install the old build, regsvr32 /u UaccCOM.dll, uninstall the old build, install the new build.

Jamie, Steve

(In reply to James Teh from comment #3)
> > If you suspect this might be the case, I'd recommend you install the old
> > build, regsvr32 /u UAccCOM.dll, then reinstall the new build.
> Correction: uninstall the new build, install the old build, regsvr32 /u
> UaccCOM.dll, uninstall the old build, install the new build.

I can not get this to resolve. Getting no IAccessible2 response on two different Windows 7 sp1 64bit systems. 

When AOO ia2 r1538508 is open, I am only getting MSAA details for the Window frame nothing from the AOO components.

Just to be sure, with r1538508 still installed, I first searched the registry

Only UAccCOM.dll was:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\0ABC43CE8D1C1E270D11495A5463AF98]
"51B671DF629B09A4991526437BFBBBE1"="C:\\Program Files (x86)\\OpenOffice 4\\program\\UAccCOM.dll"

None the less, uninstalled (using Revo). Reinstalled the r1536988 build, and had a slew of UAccCOM.dll registry entries. But Accprobe showed IAccessibile2 events firing, and NVDA fully rendered all AOO componnets. 

Then ran regsvr32 /u against the UAccCOM.DLL.
Then full uninstall (using Revo with Advanced scan).

Reinstalled r1538508 build. Check the registry again and only the installer component entry as above.

Before first use, clear per-user configuration from %APPDATA% for my account and Administrator account.  So starting as clean as I can--NVDA 2013.2 active.  Run first time as Administrator. Tools --> Options --> Accessibility and check "Support Assistive Technology tools".  OK and File --> Exit.  Launch again verify check box had checked. CLose. Launch Accprobe.exe. Launch AOO as Administrator, Accprobe only shows MSAA detail for the Windows frame. NVDA announces only frame buttons--internal components all are "unknown".

Same results if run with user account with "Support Assistive Technology tools" checked.

Something is just not right.

I just uninstalled, cleaned up and then reinstalled and still can't reproduce this. However, it occurred to me that the old OO build might have broken MSAA. You can fix this by registering c:\windows\system32\oleacc.dll and c:\windows\system32\oleaut32.dll. You may need to unregister and then register if it complains that it's already registered.

(In reply to V Stuart Foote from comment #4)
> Jamie, Steve
> 
> (In reply to James Teh from comment #3)
> > > If you suspect this might be the case, I'd recommend you install the old
> > > build, regsvr32 /u UAccCOM.dll, then reinstall the new build.
> > Correction: uninstall the new build, install the old build, regsvr32 /u
> > UaccCOM.dll, uninstall the old build, install the new build.
> 
> I can not get this to resolve. Getting no IAccessible2 response on two
> different Windows 7 sp1 64bit systems. 
> 
> When AOO ia2 r1538508 is open, I am only getting MSAA details for the Window
> frame nothing from the AOO components.
> 
> Just to be sure, with r1538508 still installed, I first searched the registry
> 
> Only UAccCOM.dll was:
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserD
> ata\S-1-5-18\Components\0ABC43CE8D1C1E270D11495A5463AF98]
> "51B671DF629B09A4991526437BFBBBE1"="C:\\Program Files (x86)\\OpenOffice
> 4\\program\\UAccCOM.dll"
> 
> None the less, uninstalled (using Revo). Reinstalled the r1536988 build, and
> had a slew of UAccCOM.dll registry entries. But Accprobe showed
> IAccessibile2 events firing, and NVDA fully rendered all AOO componnets. 
> 
> Then ran regsvr32 /u against the UAccCOM.DLL.
> Then full uninstall (using Revo with Advanced scan).
> 
> Reinstalled r1538508 build. Check the registry again and only the installer
> component entry as above.
> 
> Before first use, clear per-user configuration from %APPDATA% for my account
> and Administrator account.  So starting as clean as I can--NVDA 2013.2
> active.  Run first time as Administrator. Tools --> Options -->
> Accessibility and check "Support Assistive Technology tools".  OK and File
> --> Exit.  Launch again verify check box had checked. CLose. Launch
> Accprobe.exe. Launch AOO as Administrator, Accprobe only shows MSAA detail
> for the Windows frame. NVDA announces only frame buttons--internal
> components all are "unknown".
> 
> Same results if run with user account with "Support Assistive Technology
> tools" checked.
> 
> Something is just not right.

Hi Stuart,

I doubt that the oleacc.dll is not registered correctly on your systems. This issue shold be caused by the old UAccCOM.dll. 

Solution: enter the system folder such as "C:\windows\system32\" from console and type "regsvr32 oleacc.dll".

Jamie, Steve

(In reply to James Teh from comment #5)

> ... However, it occurred to me that the old OO build might have
> broken MSAA. 

That seems to have been the issue!

>You can fix this by registering c:\windows\system32\oleacc.dll
> and c:\windows\system32\oleaut32.dll. You may need to unregister and then
> register if it complains that it's already registered.

I first registered oleacc.dll -- regsvr32 oleacc.dll, no complaint that it was already registered.

Launch of AOO 4.1.0 ia2 r1538508 comes up clean and is being rendered by NVDA and Accprobe shows MSAA and IAccessible2 content.

Then also registered oleaut32.dll -- regsvr32 oleaut32.dll, no complaint there either.

A review of the system log did not show any error events from oleacc during prior sessions, but guess that makes sense if the library was not registered. Would the broken MSAA manifest in some other log?

I'm fine with closing resolved--but if removal of older ia2 caused the mangled MSAA is it fixed or not-a-bug.  Potentially some other beta testers will have the same experience. At least a note in the ia2 branch tips: https://cwiki.apache.org/confluence/display/OOOUSERS/Tips+for+branch+ia2

@Jamie,

(In reply to James Teh from comment #5)
> I just uninstalled, cleaned up and then reinstalled and still can't
> reproduce this. However, it occurred to me that the old OO build might have
> broken MSAA. You can fix this by registering c:\windows\system32\oleacc.dll
> and c:\windows\system32\oleaut32.dll. You may need to unregister and then
> register if it complains that it's already registered.

I know this issue of mine is correctly closed especially given a clean experience with a r1539225 load. But do you think that some of the issues with "corrupt" systems commonly reported by folks on the NVDA support lists (nvda@freelist and nvda-devel@lists.sourceforge) could be this issue with oleacc.dll and oleaut32.dll registration?

The recent tone on both lists has been to stay away from ia2 beta testing as it has just gotten too painful. Is it worth it and can you think of a way to coax them to resume testing?

(In reply to V Stuart Foote from comment #8)
> do you think that some of the issues
> with "corrupt" systems commonly reported by folks on the NVDA support lists
> (nvda@freelist and nvda-devel@lists.sourceforge) could be this issue with
> oleacc.dll and oleaut32.dll registration?
Very possibly. However, I'm pretty sure Symphony had this bug as well, and while I did see brokenness for the current session, a reboot seemed to fix it, suggesting Windows somehow restored the oleacc registration itself.

> The recent tone on both lists has been to stay away from ia2 beta testing as
> it has just gotten too painful. Is it worth it and can you think of a way to
> coax them to resume testing?
I did try to do this with my suggestion on our lists that new builds should have resolved this issue. If it broke someone's system, they probably would have asked for ideas on how to fix it already, so I don't think it's worth posting general recovery instructions unless people ask. The important thing is to make users aware that this is now fixed.

That said, bug 123643 is a fairly big obstacle to wider testing. It's very difficult for screen reader users to enable AT support manually. It can be done with a registry patch, but the patch needs to be somewhere easy for users to find and download and the whole process tends to make many users shy away.