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

Sysinternals DBGView is slow to respond when NVDA is running under xp #2713

Closed
nvaccessAuto opened this issue Oct 13, 2012 · 6 comments
Closed

Sysinternals DBGView is slow to respond when NVDA is running under xp #2713

nvaccessAuto opened this issue Oct 13, 2012 · 6 comments
Labels
bug close/wontfix

Comments

@nvaccessAuto
Copy link

Reported by tspivey on 2012-10-13 04:09
STR:

  1. Launch DebugView (dbgview.exe).
    If the window appears at all, navigating around is really slow (sometimes can take a minute or so to get any results).

Deleting this line out of nvdaHelper/remote/IA2Support.cpp seems to fix it, though there's probably a better fix:

LOG_DEBUGWARNING(L"Error registering class object, code "<<res);

Which was the one error I saw quite a bit.

I'm assuming that the remote part of nvdaHelper gets injected into all processes, and dbgview isn't expecting itself to call OutputDebugString. I haven't seen this break on win8, though.
@nvaccessAuto
Copy link
Author

Comment 1 by jteh on 2012-10-14 05:43
Mick, I'm wondering whether we should kill our usage of !OutputDebugString, perhaps making it a build option. While it might be useful to us, someone debugging a remote process probably shouldn't see our output unless they explicitly need it. We log it to NVDA now anyway. Thoughts?

@nvaccessAuto
Copy link
Author

Comment 2 by mdcurran on 2012-10-17 00:16
Would you be happy if it was tied to the debugCRT flag in nvdaHelperDebugFlags? or should it be another flag by itself? I'm certainly happy for it to be disabled by default. Certainly if its causing this kind of performance hit.

@nvaccessAuto
Copy link
Author

Comment 3 by jteh on 2012-10-17 00:18
debugCRT sounds fine to me for now. We can always add an additional flag later if needed.

@ehollig
Copy link
Collaborator

ehollig commented Jul 17, 2017

@tspivey is this still an issue?

@tspivey
Copy link
Collaborator

tspivey commented Jul 18, 2017 via email

@ehollig
Copy link
Collaborator

ehollig commented Aug 10, 2017

XP issues are not being addressed anymore. Closing

@ehollig ehollig closed this as completed Aug 10, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug close/wontfix
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@tspivey @nvaccessAuto @ehollig