Resharper 5 is causing loss of mouse

Our company recently upgraded to Visual Studio 2010 and have installed ReSharper
5 and everyone is experiencing an intermitent problem where all of a suddon,
mouse clicks stop having any effect in certain Visual Studio windows.  Sometimes
it will happen to a small window (such as the Find Usages window), but other
times it will happen to one of the code windows as well.  When it happens,
the mouse still works fine in all other VS windows, but in this one window,
clicking inside of the window has no effect.  If you click anywhere in the
window, that window will get focus, but nothing inside of the window will
respond to clicks.  If it happens to a code window, its very interesting
because the keyboard continues to respond, but the mouse clicks do not (though
the mouse still moves around just fine).  If the window is a floating window,
you cannot even click on the 'x' in the upper right.  The entire window simply
does not respond to the mouse click.  The only way to fix it seems to be
to restart Visual Studio.

I was using ReSharper 5 in Visual Studio 2008 for a couple weeks and did
not encounter this problem.  However, it happens to me several times a day
using VS 2010.  A couple people experiencing the problem have suspended ReSharper
and the problem has not occurred since then, so it seems that ReSharper is
somehow causing the problem.  This problem happens when no other VS Addins
are installed.

Has anyone else encountered this issue?  Our main solution contains an ASP.NET
Website project (not Web Application Project) that has a reference to System.Web.Mvc
(some of the site is Mvc, some is not).  I don't know if that is relevent
or not, but I thought I would mention it.

This problem is significantly impeding our development team.  Please help
us find a solution or we may have to all uninstall it.  That would be a shame
because ReSharper has so many useful features.

Thanks,

~Andy


6 comments
Comment actions Permalink

Hello,

I know about two things possibly causing this behavior.

The first one seems to be a bug in the Windows Forms popup menu implementation.
If you open a drop-down button on a Windows Forms toolbar (eg in Find Results
or Unit Test Sessions window, etc), and dismiss it without actually selecting
an item (by clicking someplace else), then mouse remains captured by the
toolbar and does not affect other windows. This bug is easy to avoid, just
take care using the drop-down buttons.

The second issue is a probable bug in the Windows code. If you're running
a 32-bit application on more than 2 GB of virtual memory, then getting the
mouse cursor position fails when you allocate memory above the first two
gigs. Visual Studio is a 32-bit process and, when run on a 64-bit OS, can
access something about 3.5 GB of memory. WPF uses GetCursorPos to see where
you clicked. Sometimes it allocates memory below 2GB, sometimes above. In
the latter case, you lose. Mouse clicks, that is. We were experiencing these
problems on VS 2008 as well, but there's just so little WPF code, and other
things would not usually rely on getting the mouse position explicitly.

If our assumptions are correct, ReSharper is not causing these problems directly.
It just adds to the memory usage, which "pushes" new allocations over the
2GB limit, and it starts failing. As for the possible fixes or workarounds, —
This issue is known to be fixed in Windows 7. In Windows Vista, Microsoft
is currently not planning to ship a KB because it's a bit too complicated
to push it though all of the testings and approvals (as far as I've heard).
This issue does not manifest itself on 32-bit systems (unless you use something
like the /3GB boot key).
This issue will go away if you restrict Visual Studio to the lower two gigabytes
of memory space. It's currently marked as a "Large Address Aware" application,
which is, after all, not quite correct. This will decrease the available
amount of memory, though.
We're also working on an experimental utility to force these allocations
into the lower 2GB of memory, but it is not ready yet.

PS it could also be something else, but the second reason seems to be the
most probable so far.


Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”


0
Comment actions Permalink

Hello Serge,

The second explanation sounds very plausible.  Thanks so much for the detailed
explanation.  We are currently running Windows Server 2008 (similar to Vista).
If they fixed it in Windows 7, should I also be able to assume that it has
been fixed in Windows Server 2008 R2?

If you get the utility you are working on done, it would be very useful to
know.  In the meantime, I'll try making VS not large address aware and see
if I can get away with that (without getting Out of Memory Exceptions :))

Thanks again for the detailed explanation.

~Andy

Hello,

I know about two things possibly causing this behavior.

The first one seems to be a bug in the Windows Forms popup menu
implementation. If you open a drop-down button on a Windows Forms
toolbar (eg in Find Results or Unit Test Sessions window, etc), and
dismiss it without actually selecting an item (by clicking someplace
else), then mouse remains captured by the toolbar and does not affect
other windows. This bug is easy to avoid, just take care using the
drop-down buttons.

The second issue is a probable bug in the Windows code. If you're
running a 32-bit application on more than 2 GB of virtual memory, then
getting the mouse cursor position fails when you allocate memory above
the first two gigs. Visual Studio is a 32-bit process and, when run on
a 64-bit OS, can access something about 3.5 GB of memory. WPF uses
GetCursorPos to see where you clicked. Sometimes it allocates memory
below 2GB, sometimes above. In the latter case, you lose. Mouse
clicks, that is. We were experiencing these problems on VS 2008 as
well, but there's just so little WPF code, and other things would not
usually rely on getting the mouse position explicitly.

If our assumptions are correct, ReSharper is not causing these
problems directly.
It just adds to the memory usage, which "pushes" new allocations over
the
2GB limit, and it starts failing. As for the possible fixes or
workarounds, -
This issue is known to be fixed in Windows 7. In Windows Vista,
Microsoft
is currently not planning to ship a KB because it's a bit too
complicated
to push it though all of the testings and approvals (as far as I've
heard).
This issue does not manifest itself on 32-bit systems (unless you use
something
like the /3GB boot key).
This issue will go away if you restrict Visual Studio to the lower two
gigabytes
of memory space. It's currently marked as a "Large Address Aware"
application,
which is, after all, not quite correct. This will decrease the
available
amount of memory, though.
We're also working on an experimental utility to force these
allocations
into the lower 2GB of memory, but it is not ready yet.
PS it could also be something else, but the second reason seems to be
the most probable so far.

-
Serge Baltic
JetBrains, Inc - http://www.jetbrains.com
"Develop with pleasure!"



0
Comment actions Permalink

I've seen that with VS2008 running on 32-bit WinXP with 3G of RAM and R# v5.0. But I see it only with one specific window - the Pending Changes window. Even there I can click such things as checkboxes and that works fine. But sometimes the Check In button won't accept a mouse click. If I Alt-Tab to something else and Alt-Tab right back to VS2008 the Check In button then works fine. This of course might not be related to R# at all but I never had the problem until I started testing R# v5. It happened with beta, RC, and now RTM builds. It never happened with R# v4.5.

0
Comment actions Permalink

Hello,

If they fixed it in Windows 7, should I also be able to assume that
it has been fixed in Windows Server 2008 R2?


I have no explicit information on that, but this seems to be a reasonable
assumption.

In the meantime, I'll try making VS not large address aware


According to the user content on the MSDN toipc for GetCursorPos Function,
you can use the editbin.exe utility for that. I used CFF Explorer for checking/setting
file properties like this in GUI.

If you get the utility you are working on done, it would be very useful

to know.

Sure!


Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”


0
Comment actions Permalink

I am starting to see this behavior on m,multiple computers with VS 2019 and the latest Resharper.

0
Comment actions Permalink

Hello Dennis,

 

thank you for the feedback.

The behavior is caused by one of the latest Windows updates - https://developercommunity.visualstudio.com/content/problem/937767/cannot-use-mouse-for-secondary-windows.html.

We've provided a patch for this issue in ReSharper 2020.1 EAP 6 build - https://www.jetbrains.com/resharper/nextversion/#section=windows. You are welcome to try it.

More detailed information about our fix - https://youtrack.jetbrains.com/issue/RSRP-478671#focus=streamItem-27-4036982.0-0.

Thank you.

0

Please sign in to leave a comment.