GetCursorPos fails with large addresses in Large-Address-Aware 32-bit process (WPF) - by EpicDarkVeil

Status : 

  External<br /><br />
		This item may be valid but belongs to an external system out of the direct control of this product team.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


17
0
Sign in
to vote
ID 381683 Comments
Status Closed Workarounds
Type Bug Repros 7
Opened 11/13/2008 7:30:03 AM
Access Restriction Public

Description

Calls to GetCursorPos always fail with ERROR_NOACCESS when passed an LPPOINT at a memory address higher than 2 GB.  This is a common occurrence when running a 32-bit process that is Large Address Aware.

Windows Presentation Foundation uses GetCursorPos when handling window activation events and will throw a Win32Exception if GetCursorPos fails (returns 0.)  This exception prevents WPF applications from receiving mouse focus!  The WPF window will remain in an inactive state.

Attached is a repro case that demonstrates WPF becoming unresponsive due to GetCursorPos failing in a large-address-aware client.

The application allocates 2 GB of memory on the native heap and then loads a WPF DLL and displays a user interface.  Every time the user clicks on the large button in the interface, thousands of items will be added to the list box.  After a dozen clicks or so, when you resize the window WPF will pass a large address to GetCursorPos while handling an activation event.  This call fails and WPF will throw an exception.  The app will remain unreponsive to mouse input after that.
Sign in to post a comment.
Posted by Yuhong Bao on 5/17/2014 at 2:21 PM
Tested and it does.
Posted by Yuhong Bao on 8/30/2013 at 2:36 PM
Just found this:
http://support.microsoft.com/kb/979288
Does it fix this bug?
Posted by Esle on 4/28/2010 at 12:39 AM
This issue impacts not on the the RC of Visual Studio 2010, but the final version as well...
How the issue be escalated so that it can be fixed in Vista as well???
Posted by Ken Muse on 3/22/2010 at 3:23 PM
This issue also impacts the new Visual Studio 2010 RC (also a 32-bit app). This can make it very difficult to work with moderate to large projects on Vista x64. As the memory usage grows, eventually the ability to use the IDE can be lost. There are some workarounds, but it is ideal to be able to continue working on a project without risking the mouse functionality becoming disabled when your memory usage grows.
Posted by David Heffernan on 10/28/2009 at 5:22 PM
It's a bit disappointing that this fix won't be included in Vista. I suffer from the bug quite a bit. As it happens I'm building a native Delphi app and am able to replace calls to GetCursorPos with calls to GetCursorInfo which doesn't suffer from the large address bug.

Where I get bitten is by the HTML help viewer. Because that runs in an OCX (hhctrl.ocx) loaded into my process it inherits the large address aware setting and suffers a variety of problems which I presume are to do with this GetCursorPos bug. I suppose I could try and hook it but that seems a little dicey.

Incidentally and off-topic, the decision to implement the HTML help viewer in-process has some odd side-effects. The HTML help viewer component isn't theme aware and so when my help file is displayed by my app it does look a bit funny in places. When the help file is displayed outside my app (e.g. double-click the .chm) then the host (hh.exe) displays in classic mode. It would be nice if a future release of the HTML help viewer was theme-aware.
Posted by Microsoft on 2/17/2009 at 2:16 PM
EpicDarkVeil,

This bug is due to an issue in Windows. We have worked with the Win7 team to get this fixed in Win7, but unfortunately the Windows Serviceability Team (WinSE) rejected our request to downport this fix to Vista. You can try to escalate this issue to WinSE to get a downport.

Thanks!
Samantha
Program Manager, WPF Tree Services & Controls
Posted by Microsoft on 2/11/2009 at 2:54 AM
Thanks for your feedback. We are escalating this bug to the product unit who works on that specific feature area. The team will review this issue and make a decision on whether they will fix it or not for the next release.

Thank you,
Visual Studio Product Team