次の方法で共有

Explaining 'The Binding Handle Is Invalid'

  • [アーティクル]

Today I want to try to give more insight into the 'Binding Handle Is Invalid' problem that a number of people have reported with the VS 2005 debugger.

First, if all you care about is how to solve the problem: Enable the 'Terminal Services' service and reboot. If you want to know more, read on.

The Terminal Services service

I have seen many users say something like "I don't want to enable the Terminal Services service because it’s a security risk". While I certainly understand this fear, this stems from a misunderstanding of what the Terminal Services service provides.

Enabling the Terminal Services service does NOT automatically enable Remote Desktop. If you want Remote Desktop disabled, then uncheck the remote desktop checkbox on the Remote tab of the properties dialog for My Computer. By default, Remote Desktop is disabled on Window XP, so unless you have gone and enabled it, it should already be disabled on your computer.

So, why is this service enabled by default? The Terminal Services service is enabled by default because in addition to the Remote Desktop functionality, it also provides for Remote Assistance, Fast User Switching, process listing, DCOM support, and probably lots of other stuff that I don't know about because I don't work on the TS team. If you are running with the Terminal Services service disabled, then you are running in a strange and not recommended configuration. You also have a broken Task Manager, and probably a bunch of other things that directly or indirectly rely on this service.

So please, regardless of what you want to do with Visual Studio, don't disable this service.

The Debugger

So why does the debugger rely on the Terminal Services service? The answer: Process listing. It turns out that the TS team provides the best task list API in Windows. Both tasklist.exe and taskmgr.exe use the TS service for this, and so it was natural for the debugger to follow their lead. Previous versions of Visual Studio got their task list through other task list APIs, but it turns out that this only works well if you run your code as LocalSystem. This was fine at the time because we had a service. However, for improved security and stability, the debugger got rid of their service for the 2005 release, so we needed to switch to the TS process listing API.

Why do you have such a lousy error message? Unfortunately, we didn't understand this problem until the very last days of the VS 2005 product cycle, and we didn't understand how many people run this way until after we shipped. At this point, it was too late to do anything about it. As the dev who wrote this code, I can only say that I am sorry that this has been such a hassle for you.

Are you guys going to fix this issue? We won't be able to completely fix the problem because the WTSEnumerateProcess API provides information that we can't get anywhere else. However, we can work around the problem in most of the common scenarios. I hope to see us ship this workaround in the next service pack. Furthermore, I expect to see us ship this work around in the next version of Visual Studio. However, I don't expect us to release this work around as a QFE because at this point at least, we don't think that this action would be in our customer's interest. QFEs are expensive to deploy for both Microsoft and our customers and generally, carry higher risk of potentially breaking other scenarios. The TS team has recommended that the Terminal Services service be enabled, so we believe that this is the right solution to address this issue.

What is affected? Any scenario where the debugger is told to attach to a process that is already running. This includes all ASP.NET scenarios, launching a C#/VB/J# project (unless the Visual Studio hosting process has been disabled), or manually trying to attach via the Attach To Processes dialog.

Comments