Attachment nvda.log added by aleksey_s on 2010-02-16 05:42
Description:
Log of the failure

Comment 1 by aleksey_s on 2010-02-16 05:43
See last error in the log attached.

Comment 2 by pvagner on 2010-02-16 09:55
I can reproduce this as well, I am on Windows XP SP3. I can't remember happening it previously

Comment 3 by jteh on 2010-02-17 07:08
Guys, can you please make absolutely certain this is a regression? (Test with 2009.1 if necessary.) It still needs to be fixed regardless. However, if it's a regression, we can't seem to think of anything that has changed in the code that should affect this at all. The input lang stuff (which is what has been changed) uses a different hook to the typed character stuff, so the latter shouldn't have been affected.

Mick, they're on XP, so the Win7 hook timeout thing doesn't apply anyway.

Comment 4 by aleksey_s (in reply to comment 3) on 2010-02-17 18:40
Replying to jteh:

Guys, can you please make absolutely certain this is a regression? (Test with 2009.1 if necessary.)

I am using NVDA trunk on the daily basis, and noticed this one just recently.
BTW, today NVDA has worked smoothly without this issue even when resuming from standby.

Comment 5 by jteh on 2010-02-19 02:01
We haven't been able to reproduce this. Keep an eye on it during the beta cycle and let us know if you have any new info.

Comment 6 by aleksey_s (in reply to comment 5) on 2010-02-19 09:24
Replying to jteh:
It has happened for me three times today.
I don't have any clear idea why it is possible. May be adding some better error reporting to NVDA helper? Different return codes, for example.

Comment 7 by aleksey_s on 2010-02-19 10:13
I see, that NVDAHelper remote terminate() function is printing to stderr on error. Is it possible to redirect its stderr to the NVDA log? Othervise, i suggest to implement SetLastErrorString() function and call it from NVDA when helper returns an error code.

Comment 8 by jteh on 2010-02-20 05:41
I know this is annoying, but can you try running for a while with the new inputLangChange stuff commented out; i.e. so the callback in inputLangChange.cpp is just an empty function? I don't see how this could be the cause, as it's a different hook to typedCharacter, but it seems that the issue started after we introduced the new inputLangChange stuff and I'd like to get a solid idea of whether this is indeed the culprit.

Comment 9 by pvagner (in reply to comment 8) on 2010-02-21 08:30
Replying to jteh:

can you try running for a while with the new inputLangChange stuff commented out; i.e. so the callback in inputLangChange.cpp is just an empty function? I don't see how this could be the cause, as it's a different hook to typedCharacter, but it seems that the issue started after we introduced the new inputLangChange stuff and I'd like to get a solid idea of whether this is indeed the culprit.

I have done it a bit differently I have commented out registerhook and unregisterhook calls respectivelly.
The problem is I can no longer reproduce the issue with my compile of the recent NVDAHelper.
Perhaps it might be related to the interface change or something.
I have observed described behaviour only once. Perhaps it will happen again but I am unable to reproduce on demand. I am trying hard by going to stantby mode several times to no avail.

Comment 10 by mdcurran on 2010-02-22 02:57
Jamie managed to reproduce this issue once, on Windows 7.
We were able to prove that nvdaHelper.terminate was throwing an error definitely because nvdaHelper_terminate could not unregister the getMessage hook. This suggests that Windows already unregistered that hook for some reason or another.
The other hooks (callWndProc and the nvdaHelper winEvent hook) were still registered as Windows was still able to report input language changes and use virtualBuffers.

Some further questions:

• Does Windows ask for a password when coming out of standby?
• is an installed copy of NVDA configured to start at Windows logon?
• What is the exact version of NVDA you currently have installed (if any)?
• How long was the computer on standby for?
• How did you put the computer on standby (e.g. specific shortcut key, power button, close lid, Windows did it due to inactivity)?
• How did you wake the computer up (e.g. opened lid, pressed power button, pressed specific keyboard keys)?
• Does NVDA still report input language changes when this occures?
• Do virtualBuffers still work when this occures?

Comment 11 by pvagner (in reply to comment 10) on 2010-02-22 08:19
Replying to mdcurran:

Some further questions:

• Does Windows ask for a password when coming out of standby?

It does not here.

• is an installed copy of NVDA configured to start at Windows logon?

No, NVDA service is installed though.

• What is the exact version of NVDA you currently have installed (if any)?

Currently I am running self-compiled R3596. I can't reproduce this any more. Previously I think I was running R3586 or such and I have seen the problematic behaviour only once.

• How long was the computer on standby for?

For about 2 hours.

• How did you put the computer on standby (e.g. specific shortcut key, power button, close lid, Windows did it due to inactivity)?

I have used shutdown dialog from the start menu or I have simply closed the front pannel on the laptop. I am not 100% sure.

• How did you wake the computer up (e.g. opened lid, pressed power button, pressed specific keyboard keys)?

Pressed power button.

• Does NVDA still report input language changes when this occures?

Yes it does.

• Do virtualBuffers still work when this occures?

They work fine for me.

Comment 12 by jteh on 2010-03-23 01:00
Haven't been able to repro recently and can't repro reliably enough to fix for 2010.1. Moving to 2010.2. However, if this doesn't show up in the 2010.2 cycle, this should be closed.`
Changes:
Milestone changed from 2010.1 to 2010.2

Comment 13 by jteh on 2010-05-18 02:30
Can anyone still reproduce this?

Comment 14 by aleksey_s on 2010-05-18 07:05
It happened to me right now after waking up my laptop from standby mode. very unpleasure.Also, now it seems to affect NVDA keyboard responding as a whole. e.g. I am not able to unload NVDA with NVDA+q, only process kill helps here.

Comment 15 by jteh (in reply to comment 14) on 2010-05-18 07:24
Replying to aleksey_s:

Also, now it seems to affect NVDA keyboard responding as a whole. e.g. I am not able to unload NVDA with NVDA+q, only process kill helps here.

This particular issue is unrelated. If a keyboard hook takes too long to respond (which can happen to any application coming out of standby), Windows will silently unregister it. Windows 7 is especially touchy about this. Note that typed characters is a window message or window proc (can't remember which) in-process hook, so it shouldn't suffer from this.

Unfortunately, noen of this brings us any closer to solving the issue.

Comment 16 by jteh on 2010-07-14 04:44
We'll take a fix, but since we can't readily reproduce or identify what might be dcausing it, there's little point in blocking the release on this.
Changes:
Milestone changed from 2010.2 to 2010.3

Comment 17 by jteh on 2010-09-24 01:09
Still can't reproduce. Of course, we're still interested in taking a fix asap if someone can reproduce it reliably.
Changes:
Milestone changed from 2010.3 to None

This issue hasn't gotten comments during the last seven years, and honestly I've never seen it. May be it should be closed with the note that it can be re-opened at any time?

Closing as worksforme. Please reopen if the problem persists.