Comment 1 by ScottV on 2013-06-27 19:15
Output from MFCIE when exiting:

'mfcie.exe': Unloaded 'C:\Program Files (x86)\NVDA\lib\VBufBackend_mshtml.dll'
First-chance exception at 0x526e9b77 in mfcie.exe: 0xC0000005: Access violation reading location 0xfeeefefa.
Unhandled exception at 0x76ee15de in mfcie.exe: 0xC0000005: Access violation reading location 0xfeeefefa.

Comment 3 by mdcurran on 2013-12-05 22:02
If this is still an issue, can someone please provide a compiled version of this app? MFC is not free and does not come with VS express or the windows SDK etc.

Comment 4 by ScottV on 2013-12-06 02:53
This is still an issue. You can download a compiled version of MFCIE from here.

http://www.teamsoftwaresolutions.com/other/MFCIE.zip

Comment 5 by mdcurran on 2013-12-06 04:39
I have tried this on both Win7 and win8 and do see the issue (the process stays around after its UI exits). However, while running with windbg, I never saw any access violations, just some unknown firstchance exceptions from rpcrt4.dll. As far as NVDA goes, its nvdahelperRemote inprocMgrThreadFunc was just happily waiting on its event to clean up. When a process exits, Windows would normally simply kill of that NVDAHelper thread and nvdaHelperRemote's dllMain would run... which it does not in this situation... which means although the UI disappeared, exiting some how stopped after that point.
What operating system did you try this on? and, where exactly did you get the output you have provided in comment1? windbg, Visual studio debugger... an error dialog?
For me I get no "output" from mfcie.exe when it exits.

Thanks for providing the compiled version. However, since I have not yet got enough info, would it be possible for you to please provide me with a debug build of mfcie? I'd like to see symbols, for it to use the debug CRT, and have runtime stack checks enabled if possible. (all things I already have for NVDA's dlls). I'm assuming that there'd probably be a default "debug" build option in the project.
Sorry I don't have access to MFC so can't do this myself. But I'm certainly happy to investigate this ticket as it clearly is important.

Comment 6 by ScottV on 2013-12-06 16:23
''where exactly did you get the output you have provided in comment1? windbg, Visual studio debugger... an error dialog?''

The output is from Visual Studio when running MFCIE.

''Thanks for providing the compiled version. However, since I have not yet got enough info, would it be possible for you to please provide me with a debug build of mfcie?''

Here is the debug build:
http://www.teamsoftwaresolutions.com/other/MFCIEd.zip

Comment 7 by ScottV on 2013-12-06 16:27
I have not tried it yet, but it may be possible to duplicate the error in a browser hosting the IE webbrowser control in plain C.

http://www.codeproject.com/Articles/3365/Embed-an-HTML-control-in-your-own-window-using-pla

Comment 8 by mdcurran on 2013-12-09 00:35
Thanks. It tells me I require mfc100d.dll. Plus I'm guessing that I'll also need msvcr100d.dll and msvcp100d.dll. Assuming this was compiled with VS 2010? I think you should find all these in your VS installation possibly under a directory called debug_noredist.

Comment 9 by ScottV on 2013-12-09 01:57
Here is the debug version of the MFCIE Microsoft example compiled with MFC as a static library.

http://www.teamsoftwaresolutions.com/other/MFCIEds.zip

Just in case, you can also get the MFC 10 run time library from here.

http://www.microsoft.com/en-us/download/details.aspx?id=5555

Comment 10 by mdcurran on 2013-12-09 05:03
Further testing for me shows that this issue is not specific to NVDA, but occurs with some other assistive technologies as well. While not running NVDA, if I start Windows Narrator, then start mfcie, then close mfcie. mfcie.exe stays around. However the post mortum debugger (if one is set) only appears once Narrator is finally closed... at least on my system.
I'm interested if youcan reproduce the issue with Narrator as well?

With either NVDa or Narrator running, I get an access violation with the following stack in thread 0:
0034ef1c 67b014e8 mfc100!AFX_MAINTAIN_STATE2::AFX_MAINTAIN_STATE2+0x3d
0034ef54 67b0387c mfc100!CWnd::XAccessibleServer::SetProxy+0x1a
0034ef68 67b03786 mfc100!CMFCComObjectATL::CAccessibleProxy::`vector deleting destructor'+0x32
0034ef78 75e2bd44 mfc100!CMFCComObjectATL::CAccessibleProxy::Release+0x1c
0034efb8 75e2a71d ole32!CStdIdentity::ReleaseCtrlUnk(void)+0x55 @ 1149
0034efe4 75e14a77 ole32!CStdMarshal::Disconnect(unsigned long dwType = 1)+0x298 @ 3454
0034eff8 75e14a40 ole32!CStdMarshal::HandlePendingDisconnect(HRESULT hr = 0x00000000)+0x4d @ 3082
0034f048 75e148d5 ole32!CRemoteUnknown::RemReleaseWorker(unsigned short cInterfaceRefs = 1, struct tagREMINTERFACEREF * InterfaceRefs = 0x004818e0, int fTopLevel = 0n1)+0x1ca @ 1078
0034f05c 758e592c ole32!CRemoteUnknown::RemRelease(unsigned short cInterfaceRefs = 1, struct tagREMINTERFACEREF * InterfaceRefs = 0x004818e0)+0x15 @ 855
0034f07c 759605f1 RPCRT4!Invoke+0x2a
0034f480 75f2d7e6 RPCRT4!NdrStubCall2+0x2ea
0034f4c8 75f2d876 ole32!CStdStubBuffer_Invoke(struct IRpcStubBuffer * This = 0x00475420, struct tagRPCOLEMESSAGE * prpcmsg = 0x00443db8, struct IRpcChannelBuffer * pRpcChannelBuffer = 0x0044dde0)+0xb6 @ 1590
0034f510 75f2ddd0 ole32!SyncStubInvoke(struct tagRPCOLEMESSAGE * pMsg = 0x00443db8, struct _GUID * riid = 0x0044bcb0 {00000134-0000-0000-c000-000000000046}, class CIDObject * pID = 0x00000000, void * pVtableAddress = 0x75e46f14, struct IRpcChannelBuffer * pChnl = 0x0044dde0, struct IRpcStubBuffer * pStub = 0x00475420, unsigned long * pdwFault = 0x0034f6bc)+0x3c @ 1187
0034f55c 75e48a43 ole32!StubInvoke(struct tagRPCOLEMESSAGE * pMsg = 0x00443db8, class CStdIdentity * pStdID = 0x00478ef8, struct IRpcStubBuffer * pStub = 0x00475420, struct IRpcChannelBuffer * pChnl = 0x0044dde0, struct tagIPIDEntry * pIPIDEntry = 0x80004021, unsigned long * pdwFault = 0x0034f6bc)+0xb9 @ 1396
0034f638 75e48938 ole32!CCtxComChnl::ContextInvoke(struct tagRPCOLEMESSAGE * pMessage = 0x00000000, struct IRpcStubBuffer * pStub = 0x00475420, struct tagIPIDEntry * pIPIDEntry = 0x0044e048, unsigned long * pdwFault = 0x0034f6bc)+0xfa @ 1262
0034f654 75e4950a ole32!MTAInvoke(struct tagRPCOLEMESSAGE * pMsg = 0x00443db8, unsigned long CallCatIn = 1, struct IRpcStubBuffer * pStub = 0x00475420, class IInternalChannelBuffer * pChnl = 0x0044dde0, struct tagIPIDEntry * pIPIDEntry = 0x0044e048, unsigned long * pdwFault = 0x0034f6bc)+0x1a @ 2105

It looks like mfc has some kind of custom accessibility implementation, which obviously only gets used by ATs such as NVDA or Narrator. However, perhaps there is a bug in its cleanup code. When the AT goes away or drops its reference to the MSAA COM object, an access violation occurs. And I guess stops the exit in its tracks.
If I am correct, (and you can reproduce this with Narrator) all I can suggest is that you try with MSVC 2012 (I assume there is a newer version of MFC as well?) and if its still not resolved, report the issue to Microsoft.

finally: The last build you gave me (the one you said was statically linked) still requires mfc100d.dll. Perhaps the crt is now statically linked, but mfc is not. The link you gave to the MVC runtime also won't help in this situation as Microsoft does not redistribute debug dlls. It only comes with Visual Studio itself.

According to @michaelDCurran's #3306 (comment), this issue seems to take place with Narrator as well, suggesting that it isn't an inherent NVDA problem. Additionally, Mick requested the original author of this ticket, who is now out-of-reach, to perform testing with Narrator and revert with results, which unfortunately hasn't been done. Unless Mick has any feedback or recommends otherwise, I suggest closing. @ehollig

@michaelDCurran is there any update on this issue?

@scottv is this still reproducible with NVDA 2019.1.1?

I'm closing this because of lack of response. If this is still an issue, we can always reopen.