Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Nvda 2010.2/snaps causes Malwarebytes to give errors #1289

Closed
nvaccessAuto opened this issue Dec 25, 2010 · 10 comments
Closed

Nvda 2010.2/snaps causes Malwarebytes to give errors #1289

nvaccessAuto opened this issue Dec 25, 2010 · 10 comments
Labels
bug/app-crash bug/regression bug
Milestone
2011.1

Comments

@nvaccessAuto
Copy link

Reported by briang1 on 2010-12-25 22:44
Since the new version of Malwarebytes has come out. version 1.50 and the latest version has made it worse. Running it with nvda has caused it to crash, and sometimes for nvda to lock up.
Simple way to produce the error.
Install latest version of Malwarebytes free version
tab to the exit button and hit space. an error sound is heard but no sound from nvda. If you hit space blind you will get control of nvda back.
If instead, you reboot nvda, it will read the error, which the log says is..
IO - speech.speakText (22:17:48):
Speaking u"Malwarebytes' Anti-Malware: mbam.exe - Application Error icon 1 of 4"
IO - speech.speakText (22:17:49):
Speaking u'Malwarebytes' Anti-Malware: mbam.exe - Application Error dialog The instruction at "0x04798162" referenced memory at "0x00000020". The memory could not be "written".\r\n\nClick on OK to terminate the program'
IO - speech.speakText (22:17:49):
Speaking u'OK button'
IO - inputCore.InputManager.executeGesture (22:18:04):
Input: kb(desktop):space
IO - speech.speakText (22:18:04):
Speaking u'pressed'
IO - speech.speakText (22:18:04):

If you look at the last log before you rebooted then you see it has nothing of the error, just a window not responding and some watchdog core frozen in stack warning messages. The nvda reboot does not sound the falling tones and the log is incomplete.
The addresses in these errors seem to vary, and whether its a read or write message does too, which makes me think the error is spurious.
These errors occur randomly, sometimes in install, sometimes when moving about the tabs etc, but the exit one is repeatable, hence highlighting it here.
I have reported it to Malwarebytes, but no actual reply about it as yet.
Note that 2010.1 does not cause the problems.

The end of a log looks like this.

Speaking u'Scan button'
IO - inputCore.InputManager.executeGesture (22:41:56):
Input: kb(desktop):tab
IO - speech.speakText (22:41:56):
Speaking u'Exit button'
IO - inputCore.InputManager.executeGesture (22:41:57):
Input: kb(desktop):space
IO - speech._speakSpellingGen (22:41:57):
Speaking character u'space'
IO - speech.speakText (22:41:57):
Speaking u'pressed'
DEBUGWARNING - watchdog._watcher (22:41:58):
Trying to recover from freeze, core stack:
File "nvda.pyw", line 139, in
File "core.pyc", line 263, in main
File "wx_core.pyc", line 8007, in MainLoop
File "wx_core.pyc", line 7303, in MainLoop
File "core.pyc", line 249, in Notify
File "queueHandler.pyc", line 77, in pumpAll
File "queueHandler.pyc", line 47, in flushQueue
File "eventHandler.pyc", line 54, in queueEventCallback
File "eventHandler.pyc", line 130, in executeEvent
File "eventHandler.pyc", line 143, in doPreGainFocus
File "api.pyc", line 104, in setFocusObject
File "baseObject.pyc", line 34, in get
File "baseObject.pyc", line 110, in getPropertyViaCache
File "NVDAObjects\IAccessible__init.pyc", line 845, in _get_parent
File "IAccessibleHandler.pyc", line 443, in accParent

WARNING - watchdog._watcher (22:42:13):
Core frozen in stack:
File "nvda.pyw", line 139, in
File "core.pyc", line 263, in main
File "wx_core.pyc", line 8007, in MainLoop
File "wx_core.pyc", line 7303, in MainLoop
File "core.pyc", line 249, in Notify
File "queueHandler.pyc", line 77, in pumpAll
File "queueHandler.pyc", line 47, in flushQueue
File "eventHandler.pyc", line 54, in queueEventCallback
File "eventHandler.pyc", line 130, in executeEvent
File "eventHandler.pyc", line 143, in doPreGainFocus
File "api.pyc", line 104, in setFocusObject
File "baseObject.pyc", line 34, in get
File "baseObject.pyc", line 110, in getPropertyViaCache
File "NVDAObjects\IAccessible__init.pyc", line 845, in _get_parent
File "IAccessibleHandler.pyc", line 443, in accParent

WARNING - watchdog.watcher (22:42:28):
Core frozen in stack:
File "nvda.pyw", line 139, in
File "core.pyc", line 263, in main
File "wx_core.pyc", line 8007, in MainLoop
File "wx_core.pyc", line 7303, in MainLoop
File "core.pyc", line 249, in Notify
File "queueHandler.pyc", line 77, in pumpAll
File "queueHandler.pyc", line 47, in flushQueue
File "eventHandler.pyc", line 54, in queueEventCallback
File "eventHandler.pyc", line 135, in executeEvent
File "eventHandler.pyc", line 84, in init
File "eventHandler.pyc", line 90, in next
File "NVDAObjects__init.pyc", line 769, in event_gainFocus
File "NVDAObjects__init__.pyc", line 713, in reportFocus
File "speech.pyc", line 272, in speakObject
File "speech.pyc", line 205, in speakObjectProperties
File "baseObject.pyc", line 34, in get
File "baseObject.pyc", line 110, in getPropertyViaCache
File "NVDAObjects\IAccessible__init_.pyc", line 799, in get_keyboardShortcut
File "comtypes__init_.pyc", line 795, in call
@nvaccessAuto
Copy link
Author

Comment 1 by briang1 on 2010-12-26 15:44
Having done some more testing, I feel the problem was introduced between snaps
nvda_snapshot_main-3517_portable.exe
nvda_snapshot_main-3575_portable.exe
There are significant changes of the display hooking in this space of a couple of months.
I feel that the real problem is probably Mlawarebytes not releasing things its hooked into correctly. The way I tested this was to creat the error, reboot nvda, then attempt to delete the files in the old previously running version of nvda. Reasoning that if the problem was the core frozen, the handles should still be stuck, so to speak. pointing to the culprits.
I got the following.

mbam.exe Path locked: C:\nvda release candidates\lib\NVDAHelperRemote.dll, PID: 3904, Handle: DLL, Process Path: C:\Program Files\Malwarebytes' Anti-Malware\mbam.exe
mbam.exe Path locked: C:\nvda release candidates\lib\minHook.dll, PID: 3904, Handle: DLL, Process Path: C:\Program Files\Malwarebytes' Anti-Malware\mbam.exe

mbam.exe Path locked: C:\nvda release candidates\lib\IAccessible2Proxy.dll, PID: 3904, Handle: DLL, Process Path: C:\Program Files\Malwarebytes' Anti-Malware\mbam.exe

Hope this helps. above courtesy of Unlocker assistant.
This was all in the latter snap above but the errors are the same in the current snaps, but not tested that as yet.

@nvaccessAuto
Copy link
Author

Comment 2 by briang1 on 2010-12-26 16:26
Well now I have and it seems that sometimes, Windows explorer gets caught up as well.

explorer.exe Path locked: C:\nvda release candidates\lib\NVDAHelperRemote.dll, PID: 1124, Handle: DLL, Process Path: C:\WINDOWS\explorer.exe
explorer.exe Path locked: C:\nvda release candidates\lib\minHook.dll, PID: 1124, Handle: DLL, Process Path: C:\WINDOWS\explorer.exe

explorer.exe Path locked: C:\nvda release candidates\lib\IAccessible2Proxy.dll, PID: 1124, Handle: DLL, Process Path: C:\WINDOWS\explorer.exe

mbam.exe Path locked: C:\nvda release candidates\lib\NVDAHelperRemote.dll, PID: 3856, Handle: DLL, Process Path: C:\Program Files\Malwarebytes' Anti-Malware\mbam.exe

mbam.exe Path locked: C:\nvda release candidates\lib\minHook.dll, PID: 3856, Handle: DLL, Process Path: C:\Program Files\Malwarebytes' Anti-Malware\mbam.exe

mbam.exe Path locked: C:\nvda release candidates\lib\IAccessible2Proxy.dll, PID: 3856, Handle: DLL, Process Path: C:\Program Files\Malwarebytes' Anti-Malware\mbam.exe

Snap 93

@nvaccessAuto
Copy link
Author

Comment 3 by jteh on 2010-12-27 01:35
Changes:
Milestone changed from None to 2011.1

@nvaccessAuto
Copy link
Author

Comment 4 by jteh on 2011-02-22 02:40
I was able to reproduce this, though not as easily as just hitting the Exit button. I have to go to the Update tab, check for updates (even if there isn't a new update) and then hit the Exit button.

It looks like the crash is in nvdaHelperRemote. Unfortunately, using a debug build of nvdaHelper results in a stack full of loops due to trying to display a CRT message box, which is very unhelpful.

@nvaccessAuto
Copy link
Author

Comment 5 by jteh on 2011-02-23 02:24
Okay. I disabled the debug CRT. Here's the stack trace now:

(abc.acc): Access violation - code c0000005 (!!! second chance !!!)
eax=044a6da1 ebx=00000000 ecx=00000020 edx=045901a0 esi=00d51fa5 edi=00d52e39
eip=04597bdd esp=0012eeec ebp=0012eef0 iopl=0         nv up ei ng nz ac po cy
cs=001b  ss=0023  ds=0023  es=0023  fs=0038  gs=0000             efl=00000293
04597bdd 015904          add     dword ptr [ds:0023:00000024=????????
0:000> kb
ChildEBP RetAddr  Args to Child              
WARNING: Frame IP not in any known module. Following frames may be wrong.
0012eef0 044a6daf 00000020 41f7afc0 0012ef0c 0x4597bdd
0012ef20 044a5f9c 00000020 04594cbc 0012ef58 nvdaHelperRemote!std::basic_ios<wchar_t,std::char_traits<wchar_t> >::widen+0x6f [c:\program files (x86)\microsoft visual studio 9.0\vc\include\ios @ 126](ecx+4],ebx)
0012ef30 044a40b4 04594c74 00000000 41f7afb8 nvdaHelperRemote!std::basic_ios<wchar_t,std::char_traits<wchar_t> >::init+0x2c [files (x86)\microsoft visual studio 9.0\vc\include\ios @ 135](c:\program)
0012ef58 044a2ccc 04594c74 00000000 00000000 nvdaHelperRemote!std::basic_ostream<wchar_t,std::char_traits<wchar_t> >::basic_ostream<wchar_t,std::char_traits<wchar_t> >+0x84 [files (x86)\microsoft visual studio 9.0\vc\include\ostream @ 54](c:\program)
0012ef84 044a1c02 00000002 00000001 41f7b090 nvdaHelperRemote!std::basic_ostringstream<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >::basic_ostringstream<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >+0x6c [files (x86)\microsoft visual studio 9.0\vc\include\sstream @ 420](c:\program)
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\WINDOWS\system32\USER32.dll - 
0012f070 77d8906d 0026008d 00000003 00220122 nvdaHelperRemote!injection_winEventCallback+0xa2 [@ 182](d:\src\nvda\mbamcrash\nvdahelper\build\x86\remote\injection.cpp)
0012f0a0 7c90eae3 0012f0b0 00000020 044a1b60 USER32!DdeConnectList+0xf96
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\WINDOWS\system32\MSVBVM60.DLL - 
0012f0e0 734388af 00000002 00d51e94 73530518 ntdll!KiUserCallbackDispatcher+0x13
0012f0f8 73437166 00d51fa4 00d51e94 73530470 MSVBVM60!TipUnloadProject+0xdff
00000000 00000000 00000000 00000000 00000000 MSVBVM60!EbResetProjectNormal+0x1d65

I think the part relevant to us is line 182 of nvdaHelper/remote/injection.cpp, which reads:

        LOG_ERROR(L"inproc manager thread died prematuraly");

It looks like the process is exiting, so our manager thread has already been killed off, so we try to log an error. (There were no other threads.) The question is why logging an error causes a crash. I'm wondering whether the CRT has already been terminated or something like that. Mick, does that make any sense?

I'm about to try this again with logging completely disabled. In theory, it shouldn't crash.

@nvaccessAuto
Copy link
Author

Comment 6 by jteh on 2011-02-23 02:36
... But it does, somewhere else:

(dd4.dd8): Access violation - code c0000005 (!!! second chance !!!)
eax=00000004 ebx=00000000 ecx=00000000 edx=0450f4b8 esi=00d51fa4 edi=00d52e38
eip=044ae187 esp=0012ef60 ebp=0012ef6c iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=0038  gs=0000             efl=00000202
nvdaHelperRemote!std::_Tree<std::_Tmap_traits<void (__stdcall*)(HWINEVENTHOOK__ *,unsigned long,HWND__ *,long,long,unsigned long,unsigned long),unsigned int,std::less<void (__stdcall*)(HWINEVENTHOOK__ *,unsigned long,HWND__ *,long,long,unsigned long,unsigned long)>,std::allocator<std::pair<void (__stdcall*const)(HWINEVENTHOOK__ *,unsigned long,HWND__ *,long,long,unsigned long,unsigned long),unsigned int> >,0> >::_Copy+0x17:
044ae187 8b10            mov     edx,dword ptr [ ds:0023:00000004=????????
0:000> kb
ChildEBP RetAddr  Args to Child              
0012ef6c 044ac382 0450f4b8 a46ffcbc 00d52e38 nvdaHelperRemote!std::_Tree<std::_Tmap_traits<void (__stdcall*)(HWINEVENTHOOK__ *,unsigned long,HWND__ *,long,long,unsigned long,unsigned long),unsigned int,std::less<void (__stdcall*)(HWINEVENTHOOK__ *,unsigned long,HWND__ *,long,long,unsigned long,unsigned long)>,std::allocator<std::pair<void (__stdcall*const)(HWINEVENTHOOK__ *,unsigned long,HWND__ *,long,long,unsigned long,unsigned long),unsigned int> >,0> >::_Copy+0x17 [c:\program files (x86)\microsoft visual studio 9.0\vc\include\xtree @ 1063](eax])
0012efa4 044ac243 0450f4b8 0012efd4 0012f000 nvdaHelperRemote!std::_Tree<std::_Tmap_traits<void (__stdcall*)(HWINEVENTHOOK__ *,unsigned long,HWND__ *,long,long,unsigned long,unsigned long),unsigned int,std::less<void (__stdcall*)(HWINEVENTHOOK__ *,unsigned long,HWND__ *,long,long,unsigned long,unsigned long)>,std::allocator<std::pair<void (__stdcall*const)(HWINEVENTHOOK__ *,unsigned long,HWND__ *,long,long,unsigned long,unsigned long),unsigned int> >,0> >::_Tree<std::_Tmap_traits<void (__stdcall*)(HWINEVENTHOOK__ *,unsigned long,HWND__ *,long,long,unsigned long,unsigned long),unsigned int,std::less<void (__stdcall*)(HWINEVENTHOOK__ *,unsigned long,HWND__ *,long,long,unsigned long,unsigned long)>,std::allocator<std::pair<void (__stdcall*const)(HWINEVENTHOOK__ *,unsigned long,HWND__ *,long,long,unsigned long,unsigned long),unsigned int> >,0> >+0x72 [files (x86)\microsoft visual studio 9.0\vc\include\xtree @ 531](c:\program)
0012efb4 044ac13f 0450f4b8 a46fe318 0012f02c nvdaHelperRemote!std::map<void (__stdcall*)(HWINEVENTHOOK__ *,unsigned long,HWND__ *,long,long,unsigned long,unsigned long),unsigned int,std::less<void (__stdcall*)(HWINEVENTHOOK__ *,unsigned long,HWND__ *,long,long,unsigned long,unsigned long)>,std::allocator<std::pair<void (__stdcall*const)(HWINEVENTHOOK__ *,unsigned long,HWND__ *,long,long,unsigned long,unsigned long),unsigned int> > >::map<void (__stdcall*)(HWINEVENTHOOK__ *,unsigned long,HWND__ *,long,long,unsigned long,unsigned long),unsigned int,std::less<void (__stdcall*)(HWINEVENTHOOK__ *,unsigned long,HWND__ *,long,long,unsigned long,unsigned long)>,std::allocator<std::pair<void (__stdcall*const)(HWINEVENTHOOK__ *,unsigned long,HWND__ *,long,long,unsigned long,unsigned long),unsigned int> > >+0x13
0012f000 044a10e2 00b900ab 00000003 001b0144 nvdaHelperRemote!inProcess_winEventCallback+0x3f [@ 139](d:\src\nvda\mbamcrash\nvdahelper\build\x86\remote\inprocess.cpp)
0012f040 044a163c 00b900ab 00000003 001b0144 nvdaHelperRemote!inproc_winEventCallback+0xe2 [@ 65](d:\src\nvda\mbamcrash\nvdahelper\build\x86\remote\injection.cpp)
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\WINDOWS\system32\USER32.dll - 
0012f070 77d8906d 01a3008b 00000003 001b0144 nvdaHelperRemote!injection_winEventCallback+0xfc [@ 209](d:\src\nvda\mbamcrash\nvdahelper\build\x86\remote\injection.cpp)
WARNING: Stack unwind information not available. Following frames may be wrong.
0012f0a0 7c90eae3 0012f0b0 00000020 044a1540 USER32!DdeConnectList+0xf96
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\WINDOWS\system32\MSVBVM60.DLL - 
0012f0e0 734388af 00000002 00d51e94 73530518 ntdll!KiUserCallbackDispatcher+0x13
0012f0f8 73437166 00d51fa4 00d51e94 73530470 MSVBVM60!TipUnloadProject+0xdff
00000000 00000000 00000000 00000000 00000000 MSVBVM60!EbResetProjectNormal+0x1d65

This time, it looks like the part that matters is line 139 of remote/inProcess.cpp, where we copy a map:

    //Hookprocs may unregister or register hooks themselves, so we must copy the hookprocs before executing
    winEventHookRegistry_t hookProcs=inProcess_registeredWinEventHooks;

Looks like more CRT problems. Ug.

In any case, it also looks like we're creating a new manager thread even though the previous one died because the process is exiting. We really need to be able to determine that the process is exiting and do nothing in this case. I haven't got any bright ideas just yet...

@nvaccessAuto
Copy link
Author

Comment 7 by jteh on 2011-02-23 05:26
This is definitely due to the process exiting. Here's a better stack trace. The win event in question is a destroy win event. Windows really shouldn't execute win event callbacks while the process is dying, but it does. Arrrg!

...
0012f070 77d8906d 00500039 00000003 002c0134 nvdaHelperRemote!injection_winEventCallback+0xa2 [@ 182](d:\src\nvda\mbamcrash\nvdahelper\build\x86\remote\injection.cpp)
0012f0a0 7c90eae3 0012f0b0 00000020 044a1b60 USER32!__ClientCallWinEventProc+0x2a
0012f0cc 77d4e672 7345ee6d 00360152 00d51fa4 ntdll!KiUserCallbackDispatcher+0x13
0012f0e0 734388af 00000002 00d51e94 73530518 USER32!NtUserDestroyWindow+0xc
0012f0f8 73437166 00d51fa4 00d51e94 73530470 MSVBVM60!InitTermUIThread+0x89
...
0012f13c 73421b21 73420000 00000000 00000001 MSVBVM60!DllMain+0xfb
0012f15c 7c9011a7 73420000 00000000 00000001 MSVBVM60!_DllMainCRTStartup+0x66
0012f17c 7c923f31 73421ae8 73420000 00000000 ntdll!LdrpCallInitRoutine+0x14
0012f200 7c81ca3e 00000001 00000001 00000000 ntdll!LdrShutdownProcess+0x14f
0012f2f4 7c81cab6 00000000 77e8f3b0 ffffffff kernel32!_ExitProcess+0x42
*** ERROR: Module load completed but symbols could not be loaded for C:\Program Files\Malwarebytes' Anti-Malware\mbam.exe
0012f308 004522e6 00000000 00000000 00000000 kernel32!ExitProcess+0x14
...

@nvaccessAuto
Copy link
Author

Comment 8 by jteh on 2011-02-24 07:14
Fixed for me in 7f6f876.

Btw, an easier way to reproduce this on my system was to start the program, hit the Register button, alt+f4, then hit the Exit button.

I'm not sure when next snapshot will go up, so I've provided a build of the dll for you to test here. Copy it into the lib directory of a recent 2011.1 snapshot (obviously while that copy is not running).
Changes:
State: closed

@nvaccessAuto
Copy link
Author

Comment 9 by briang1 on 2011-02-25 09:36
Yes it seems to have fixed the problem, but be aware that even putting the dll in a non running copy then running it does not make it work, you appear to have to reboot windows with the dll in the version that loads at startup.
This begs the question of does the helper unload when you rebootnvda to another version?
However its fixed the original problem.

@nvaccessAuto
Copy link
Author

Comment 10 by jteh (in reply to comment 9) on 2011-02-27 23:15
Replying to briang1:

Yes it seems to have fixed the problem, but be aware that even putting the dll in a non running copy then running it does not make it work, you appear to have to reboot windows with the dll in the version that loads at startup.

This is not true. I replaced nvdaHelperRemote.dll many times in a test portable copy without restarting while I was debugging and fixing this problem. Each time, it picked up the new copy.

This begs the question of does the helper unload when you rebootnvda to another version?

In most cases, it does. However, there are some cases where the previous copy may not unload correctly from all applications if Windows refuses to release it. However, it will not load an old copy into a new application. So, for example, when testing this with MBAM, it is best to restart MBAM each time you start a copy of NVDA with a different nvdaHelperRemote.dll.

@nvaccessAuto nvaccessAuto added this to the 2011.1 milestone Nov 10, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug/app-crash bug/regression bug
Projects
None yet
Milestone
2011.1
Development

No branches or pull requests
1 participant
@nvaccessAuto