fiddler抓包对分析问题和排查故障来说真的很有用

问题

紧急问题，部署在IIS上的网站出现故障，用户输入用户名密码点击登陆无反应（所有用户均无法正常使用）

思路

之前听说总有人去机房偷偷看服务器，第一反应就是web.config可能出现问题（有可能被人改了），查完发现配置无误，而且udl测试数据库连接也正常。奇怪，莫非被人动了手脚？

既然config配置没有问题，那就从登录页面着手找，下面是登录按钮onclick事件一部分：

//获取传递前台的参数，UName，Pwd，Code
                var postData;
                if ($("#txtPassword").val().length == 32) {
                    postData = {
                        UName: $("#txtUserName").val(),
                        Pwd: $("#txtPassword").val(),
                        Vdate: $("#ValidateName").val(),
                        Pdcs: pdid,
                        Ypxl: ss
                    };
                }
                else {
                    postData = {
                        UName: $("#txtUserName").val(),
                        Pwd: hex_md5($("#txtPassword").val()).toUpperCase(),
                        Vdate: $("#ValidateName").val(),
                        Pdcs: pdid,
                        Ypxl: ss
                    };
                }

                //异步实现登录功能
                $.post("Login.ashx", postData, function (data) {
                    if (data == "OK") {
                        SetPwdAndChk();
						
                        window.location.href = "Index.aspx";
                    } else if (data == "Update") {
                        window.location.href = "LoginUpdate.aspx";
						
                    }
                    else if (data == "") {
                        window.location.href = "Login.aspx";
                    }
                    else {
                        pdid = parseInt(pdid) + 1;
                        setcookievalue("cs", pdid);
                        alert(data);
                        window.location.href = "Login.aspx";
                    }
                });

看上去没有任何问题，在post提交回调事件加入alert("1")调试一下，发现使用正确的用户名密码登录没有弹窗，关于登录的js脚本我确认过了没有问题，难道问题出在一般处理程序上？

打开Login.ashx发现CodeBehind、Class也正常，没有被更改，那会是哪里的问题？既然正确的用户名密码alert不执行，那么使用错误的用户名密码登录会怎么样呢？果然，错误的用户名密码走了回调函数。看到这里你有没有感觉很奇怪？

现在我们将情报整理一下

• 数据库服务及测试连接正常、
• web.config配置文件配置没有问题、
• 关于登录的js脚本没有问题、
• Login.ashx登录一般处理程序没有问题、
• 正确的用户名密码登录不执行post回调、
• 错误的用户名密码登录执行post回调、

这种情况如果是你你会有什么思路去排查？（前提是，你只能远程这台服务器，且服务器没有IDE环境，你又不能打开程序进行代码调试）

那么既然不能调试，看代码又看不出什么端倪来，来试试平常“干坏事儿”用的抓包吧！

关于Fiddler抓localhost，目前知道的有以下几种方法：

• 使用http://localhost.fiddler 代替 http://localhost
• 使用http://localhost. 代替 http://localhost
• 使用http://127.0.0.1. 代替 http://127.0.0.1
• ....

下面是抓取登录按钮事件的数据包：

上图中的返回信息有段文字很醒目，“无法为数据库'HBNetMonitorDB'中的对象'abo.LogRecord'.'PK_LogRecord'分配空间，因为'PRIMARY'文件组已满。请删除不需要的文件、删除文件组中的对象...”

从提示信息中可以看出，原来是表空间满了，so，truncate table tablename，再次登陆，问题解决。

后续

第二天再次出现用户无法登录，检测数据上传失败的情况。。抓包后发现还是提示“无法为数据库'HBNetMonitorDB'中的对象'abo.LogRecord'.'PK_LogRecord'分配空间，因为'PRIMARY'文件组已满。请删除不需要的文件、删除文件组中的对象...”。

解决办法

    USE[master]

    GO

    ALTER DATABASE 要清理的数据库名称 SET RECOVERY SIMPLE WITH NO_WAIT

    GO

    ALTER DATABASE 要清理的数据库名称 SET RECOVERY SIMPLE   --简单模式

    GO

    USE 要清理的数据库名称

    GO

    DBCC SHRINKFILE (N'要清理的数据库名称_log' , 2, TRUNCATEONLY)  --设置压缩后的日志大小为2M，可以自行指定

    GO

    USE[master]

    GO

    ALTER DATABASE 要清理的数据库名称 SET RECOVERY FULL WITH NO_WAIT

    GO

    ALTER DATABASE 要清理的数据库名称 SET RECOVERY FULL  --还原为完全模式

    GO

上述命令做的工作是

• 将数据库属性恢复模式设置为简单模式
• 收缩数据库
• 收缩完毕后还原为完整模式