Bugzilla – Bug 14478
Desktop freeze after remote desktop session
Last modified: 2015-02-10 02:37:52 UTC
Desktop freezes if R is left running when accessing the computer via remote desktop. Freeze occurs after physically returning to the computer and using R (not during the remote desktop session). This error occurred using this system with R 2.10.0 as well.
Intel Core2 Quad CPU Q9400 @ 2.66GHz
8 GB DDR3
ATI Radeon HD4670
Windows 7 64-bit
I have exactly the same experience with Win 7 (32 bit) and R 2.12.1. Remote laptop is running Win XP.
Any evidence that this is a bug in R (and not in the remote access
Only indirect evidence: The freeze only happens when I'm using R (on the
desktop, after a remote session); if I save the workspace and close R
before ending the remote session, that seems to prevent a freeze-up.
Maybe it's useful to know that the freeze isn't immediate. The typical
scenario is that I'll run an R2Winbugs job overnight. After logging in to
Windows the next day I close Winbugs and start playing with the results in
R, and just when I'm lulled into complacency it all goes to hell. Delay
seems to vary.
The connections are loose--that is, I only connected the freeze-ups with
remote access when I read the earlier bug report, then the penny dropped. I
can't swear that it's a necessary and sufficient condition, but I believe
that to be so. It could be that it only happens after an R/WinBugs job, but
that's almost always the case. This potentially implicates three pieces of
software and their interactions. You have an interestingly difficult job.
Best regards, and thanks for following up--
--On Thursday, February 10, 2011 1:14 PM -0500 firstname.lastname@example.org wrote:
> Brian Ripley <email@example.com> changed:
> What |Removed |Added
> Severity|major |minor
> --- Comment #2 from Brian Ripley <firstname.lastname@example.org> 2011-02-10
13:14:35 EST ---
> Any evidence that this is a bug in R (and not in the remote access
> Configure bugmail:
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
John R. Sutton
Department of Sociology
University of California
Santa Barbara CA 93106-9430
[[alternative HTML version deleted]]
I am glad that someone besides myself experiences this bug. I experience similar conditions to Jack. I work from home frequently in R and I don't experience the lockup immediately when I return to the original computer. It wont lock up until I start using R. The lock up generally occurs between 2-15 minutes after using R again on the host machine (not during the remote desktop session). Usually if I leave R running after returning to the machine, I find that if I restart the software, it prevents the lock up. So for those who accidentally forget to turn R off, could do so when they return to the host machine and avoid the bug.
Brian, I honestly can't say it isn't a bug in the remote desktop software. Regardless, it is a flaw in how R and remote desktop interact. I hope this information helps, because I do not know what the root of this error is.
I should have specified my usual remote desktop client machine:
Intel Core 2 Duo E8500 3.16 GHz
32-bit Windows 7
We still can't reproduce this, so left for a patch or an R-core member who can.
I am seeing this as well. The whole desktop freezes. There is no way out but to switch off the power and turn it back on. Computer Specs:
Windows 7 64 bit
Inten Xeon X5675 processor
9 GB RAM
NVIDIA GeForce GTX 550 Ti graphics
And I recently upgraded from Windows XP 32 bit. The freeze has started after the change to Windows 7 64 bit. So it is probably due to something that does not work the same way on Windows 7. It is very frustrating and can cause a loss of a lot of work. Will post if I get something new.
Sankalp, if a system reboot is needed, that is certainly a problem with the remote desktop software, not R. If it is only R that is freezing, it could be either one.
Just to clarify: As Anthony and I have described it, the desktop freezes up, necessitating a reboot, but ONLY during an R session AFTER using remote desktop. And for what it's worth, I recently upgraded to Win 64 bit and the problem is just the same as it was with Win 32 bit.
Thanks for the clarification. I didn't understand that it was the local
system that froze -- but it still appears to be a bug with Remote
Desktop and/or the regular desktop, not with R. Unless you run R with
elevated privileges, it should not be able to do anything that causes
the desktop to freeze.
In other words: you should take this bug report to Microsoft.
I have exactly the same problem as Anthony, Sankalp and Jack. Did any of you have any success in solving or working around the problem or contacting Microsoft?
I have one thing that may add to the discussion:
When I return to my desktop after a remote desktop session from which I have logged out, I have noted that the login screen says that I'm still logged in remotely to the server. I have tried various ways of exiting the remote desktop session, but the message that I'm logged in prevails.
R 2.15.0 64-bit
Win 7 Professional
Intel Core i7-2600 3.40GHz
I also experience this issue. The PC in question is running R 2.15.0 Patched on Windows 7 64-bit. I occasionally use Remote Desktop from my Mac OS X laptop to access my PC. When I do use R via remote desktop, nothing unusual occurs, and I log out as normal. However, maybe 1 out of 5 times when I return to the PC and start using an R session that was open and being used via remote desktop, the computer will freeze. Note that this only happens when using an R session that was open during the remote desktop session. If I close the R sessions that were being used via remote desktop and reopen R, it never freezes. Also note that I do not run R with elevated privileges.
What's unusual is it truly is a freeze: there is no blue screen or kernel panic, the screen simply freezes at a random time and continues to display whatever was on the screen at the time it froze. There is no remedy except to do a hard restart of the system. Upon restart, there are no crash dumps and Windows logging has nothing unusual to report except error and warning messages pertaining to the hard restart of the system (all timestamped after the system restart).
It's quite possible this is a Microsoft issue, but it definitely occurs only with R and only when the R session is used via remote desktop and subsequently used normally. And it's intermittent, which of course makes it even more difficult to diagnose.
A few months back, I started using rstudio (http://rstudio.org/) as replacement for the standard r windows console. There is no desktop freeze issue with it - remotely or otherwise. And it is light weight enough to not hinder my workflow.
This probably means that the freeze is from the R gui (Rgui.exe) and the core R engine does not have the problem. I am just speculating - I do not have enough knowledge of R internals to know.
Still occurring with R 3.0.2. This has been happening to me for several years now, at different workplaces. Always the same thing -- the freeze happens when working on the physical workstation (with multiple screens) AFTER working via RDP.
It seems this might is an obscure problem in Windows that is tickled by some particular way that Rgui.exe uses Windows. The freeze affects the entire Windows session, and as others have noted, the only recourse is to reboot the machine. Other people I've worked with who were affected by the same bug noted that it seemed to be associated with the re-sizing of the Windows desktop. If this speculation is true, the possible fixes are either to fix the bug in Windows itself, or make some change to the Rgui.exe code to stop tickling the Windows bug. Which is more likely, or easier?
I posted more info here: http://stackoverflow.com/questions/27361398/windows-7-freezes-when-hitting-enter-key-in-rgui-exe
Tony, is that a typo, or are you really reporting about R 3.0.2? It's more than a year old.
Regarding working around Microsoft's bug: we'd be happy to do that, but someone else will have to determine what change is necessary. There appear to be three parties involved here: R Core, Microsoft, and the users seeing this. All three groups have access to the R source code, but only Microsoft has access to their buggy source code, and only the users seeing this know how to trigger it. So it appears that R Core is in the worst position of the three for fixing it. (Not to mention the fact that Microsoft, whose software contains the bug, has a budget that's at least a million times larger than ours.) So why are you complaining here?
I experienced this Windows problem again using R-3.1.2.
Windows 7, multi-screen workstation. Nothing different than previously reported, apart from the R version.
This is not a complaint, and I don't think that R-core has any obligation to do anything about this problem. I'm just trying to leave a little more information for others experiencing this problem.