出自： http://blogs.msdn.com/b/apgcdsd/archive/2011/02/01/sql-login-sql-server-password-did-not-match.aspx
问题描述： 在某一台机器上的management studio，始终无法使用SQL login去登陆SQL Server。但是如果在其他的机器上，使用同样的SQL login是可以登陆SQL Server的。
错误信息：'Password did not match '
诊断步骤：
1. 在这台机器上使用SQLCMD连接SQL Server，用同样的SQL login 登陆，是否可以成功？
2. 创建一个新的SQL login 但是使用空密码。然后在出问题的机器上使用新创建的SQL login以及空密码登陆SQL Server，是否可以成功？
如果1和2都可以成功，基本上我们就可以确定问题是由于management studio工具对传过去的密码加密失败导致的了。
Management studio工具把我们在界面上输入的密码传到SQL Server之前，是需要首先做加密的。这个加密的密码存在什么地方呢？
我们可以在run中运行%appdata%这个环境变量来检查路径。通常这个路径设置为的是%USERPROFILE%\AppData\Roaming。在这个路径下面，继续找到microsoft\protect 目录。
所有加密的cache就存放这个目录下面了。
接下来我们看导致这个问题的几个原因：
1. 可以尝试清空protect目录下所有的文件和文件夹，然后重试。
2. 直接运行%appdata%报错，无法打开指定的路径，这种情况通常是对%appdata%指向的路径没有权限，或者%appdata%指向路径是错误的。%appdata%是存储在如下注册表键值中的，我们可以通过访问注册表来确认这个路径是否有效：HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\AppData.
3. 对于注册表键值HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\AppData.没有访问权限。这个也很容易通过访问注册表键值来确认。
只要我们当前用户确认对注册表键值有访问的权限，注册表键值中所存储的路径有效，当前用户对注册表键值所存储的路径有访问和写权限，这个问题就可以解决了。
有时候我们会发现这个目录下的Microsoft子目录下找不到protect文件夹，只要上述三个前提检查，修改并确保满足以后，这个protect目录在management studio使用加密的时候会自动创建，所以protect文件夹不存在并不是问题的原因。
