使用键盘时在 Visual Studio 2010 中调试 Silverlight 冻结
首先我想先解决“等一下”的问题。
- 是的，我已经阅读过有关 SO 及其他主题的类似标题和主题的所有帖子。
- 是的，我正在使用最新版本的 SP1 以及可能与此问题相关的任何潜在修补程序。
因此，具体来说，这是我的问题：
当我调试 Silverlight 应用程序并且它遇到断点时，只要我使用鼠标，一切都会正常工作。我可以继续、单步执行、停止调试、禁用和启用断点，一切都很好——只要我用鼠标执行这些操作。
但当我使用键盘时，Visual Studio 会冻结几秒钟，有时甚至超过一分钟。这是键盘的任何使用。但不久之后，它就开始正常工作，直到调试会话结束。但下一个调试会话（无论我是否使用相同的 Casini 实例）都会执行完全相同的操作。
当我说使用任何键盘时，我是认真的。 F5（继续）、Shift-F5（停止调试）、F10（跳过），以及在立即窗口中键入，甚至按 ALT 键突出显示菜单。
例如，如果我尝试在“立即”窗口中输入某些内容，它会冻结大约 15 秒，然后显示第一个键并重复该模式大约 5 次，直到它释放并且一切正常。
当我说“冻结”时，我指的不仅仅是 Visual Studio，而是它挂起整个操作系统，除了我无法移动鼠标之外。即便如此，无论程序结束如何，鼠标光标仍保持冻结时的状态，例如文本选择器。
它只发生在 Silverlight 中，并且我使用哪个版本并不重要。
以下是我正在运行的系统：
- Windows 7 Professional 64 位，包含所有最新更新，12 GB RAM 和 12 GB RAM。 1.5TB 高清。
- Visual Studio 2010 Ultimate 包含所有最新更新。
所有软件都是合法的，我已经尝试删除和/或禁用几乎所有可以删除或禁用的东西，包括扩展。我已经使用 Sysinternals 的 Process Explorer 来终止或停止我能阻止的一切。我还在一个非常简单的 Silverlight 应用程序上进行了尝试，该应用程序仅包含一行不访问任何内容的代码。
编辑：忘记提及，我也没有让它加载超出“仅我的代码”之外的符号，它通常会加载，并且我也尝试了我能想到的所有调试设置。 Intellitrace 也被关闭（因为我有 Ultimate），但这也没有什么区别。
更新（11/18）：事情变得越来越奇怪。我确定只有当 Visual Studio 具有焦点时才会发生临时冻结。当 VS（在超级简单的 Silverlight 应用程序期间）进入调试模式时，任何键盘访问都会导致相同的效果。所以，它似乎必须（以某种方式）与我的 Windows 设置相关（至少部分），这与我在评论中的断言相反，但我无法理解如何做到这一点。如果其他程序在冻结时正在执行某些操作，则延迟会更长（这对症状有一定的意义）。我仍然完全不知所措。
有人有任何想法或以前见过这个吗？真是令人沮丧。
First I'd like to head off the "wait a minute" questions.
- Yes, I've read every thread with similar titles and subjects on SO and beyond.
- Yes, I'm using the very latest version of SP1 and any potential hotfixes that might be related to this problem.
So, with specificity, here is my problem:
When I'm debugging Silverlight applications and it hits a breakpoint, everything works just fine as long as I use the mouse. I can continue, step, stop debugging, disable and enable breakpoints all just fine -- as long as I do so with the mouse.
But when I use the keyboard, Visual Studio freezes for a number of seconds, sometimes over a minute. This is any use of the keyboard. But after a short time, it starts to work just fine until that debugging session is over. But the next debugging session (regardless of whether I use the same instance of Casini or not) it will do exactly the same thing.
When I say any keyboard use, I mean it. F5 (Continue), Shift-F5 (Stop Debugging), F10 (Step Over), as well as typing in the Immediate window or even hitting the ALT key to highlight the menu.
For instance, if I try to type something in the Immediate window, it freezes for about 15 seconds and then shows the first key and repeats the pattern about 5 times until it releases and everything is just fine.
When I say "freezes" I'm not talking just Visual Studio but it hangs the entire operating system except for my ability to move the mouse. Even so, the mouse cursor remains what it was when it froze regardless of the program it's over, such as the text selector.
It only happens with Silverlight and it doesn't matter which version I use.
Here's what I'm running:
- Windows 7 Professional 64-bit, all of the latest updates included, 12 GB RAM & 1.5 TB HD.
- Visual Studio 2010 Ultimate with all of the latest updates.
All software is legit and I've already tried removing and/or disabling just about everything that can be removed or disabled, including extensions. I've used Process Explorer from Sysinternals to kill or stop everything I can. I've also tried it on a very simple Silverlight application with nothing more than one line of code that doesn't access anything.
EDIT: Forgot to mention that I also don't have it loading symbols beyond the "Just My Code" that it normally would and I've tried every debug setting that I can think of as well. And Intellitrace is also turned off (since I do have Ultimate), but that makes no difference either.
UPDATE (11/18): It gets more and more odd. I determined that the temporary freeze doesn't occur only when Visual Studio has focus. When VS (during the super-simple Silverlight app) goes into debug mode, any keyboard access AT ALL causes the same effect. SO, it appears that it has to (in some way) be related (at least in part) to my Windows setup, contrary to my assertion in the comments, but I cannot possibly fathom how. And if other programs are doing something when it freezes, the delay is longer (which makes a certain amount of sense with the symptoms). I'm still at a complete loss.
Anyone have any ideas or see this before? It's really frustrating.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我解决了这个问题。
原来是LastPass 工具栏。这是一个非常方便的东西，我已经使用它很多年了，没有任何问题。是的，是的，工具栏是邪恶的，我明白。 :)
在 IE 中禁用它可以完全解决问题。我仍然可以在 FF 中使用它（无论如何，这是我的主要浏览器，除了我使用 IE 的工作），并且一切正常。
即便如此，令我感到奇怪的是，工具栏只有在 SL 调试时才会起作用。我在 ASP.Net 调试方面没有遇到任何问题，并且当 SL 应用程序实际运行时，只有当我遇到断点并在前 15 秒左右按下某个键时，我才遇到任何问题。
无论如何，问题已解决，感谢您的建议。
I solved the problem.
It turned out to be the LastPass toolbar. It's a very handy thing and I've used it for years without issue. Yeah, yeah, toolbars are evil, I get it. :)
Disabling it in IE fixed the problem completely. I can still use it in FF (which is my main browser anyway except for working for which I use IE) and everything works fine.
Even so, it's bizarre to me that the toolbar would only have an effect when SL debugs. I didn't have an issue with ASP.Net debugging and I didn't any issues when the SL app was actually running, only when I hit a breakpoint AND hit a key within the first 15 seconds or so.
In any case, problem solved and thanks for your suggestions.
尝试将注册表设置 LowLevelHooksTimeout 从 5000 更改为较低值，例如 300。
它可以是
或
（Policy 键的第一个设置似乎全局覆盖用户设置）。
Try changing registry setting LowLevelHooksTimeout from 5000 to something low, like 300.
It can be at
or
(first setting at Policy key seems to globally override user setting).