1, 最简单的情况就是所有用户的所有session都丢了。这种情况一般发生在In-Proc的session mode上。原因就是appdomain挂了。看appdomain有没有recycle, 跟或asp.net process有没有crash. 直接看perfmon就可以了

2, 稍微麻烦一点的就是一个用户的session丢了，不是所有用户的session丢。首先是要在session start里面做log. 把每一个session id的创建时间都记录到log里面。这样问题发生的时候session丢了session id总还在吧，比较log看看这个session 是不是刚刚建立的。如果是，很有可能是客户端的原因导致session id丢了，其实就是cookie丢了。如果不是，那我们继续在session start里面记录一个我们自定义session value, 看看这个测试用的session value是不是丢。如果这个也丢，9成是用户调了Session.Clear.

3. 如果我们这个session value没有丢，情况就变成一个用户的session里面的一部分value丢了。这9成还是由于用户的代码导致的。唯一的解决的方法+最有效的方法只有加log. 加log的技巧是:

1) 在session start里面把这个session创建时间记录到session里面
2) 在代码中对session操作的地方，写log到以sessionid为文件名的文件里面去
3) log记录对什么session做操作，当前是什么页面什么函数，存在的session是些什么东西，操作的时间
4) 当检查到session丢失的时候，在event log中记录下session id和丢失的key

这样，问题发生的时候，根据event log里面的session id找到log文件，一下子就可以看出来了。

最后，根据解决过的各种奇怪session 丢失的经验，所有的session丢失奇怪问题都是客户端导致的。所以特别检查:

1. 如果用户开两个ie访问一个url, 其实是两个session的。也就说，session的maintain是依靠session id cookie,而这个cookie完全是由client控制的。开发人员设计的时候根本没有考虑到开两个ie访问的情况，用户在一个ie里面去写session, 在另外一个ie里面去读，当然不成功

2. 用户依靠client script来维护web page的执行持续。client script是不可靠的，所以...

3. 最容易忽视的情况就是这个session其实timeout掉了。可以在session end里面加log看到

最后，思路就是:
1. 看sessionid是否变化。变了，就是客户端或者防火墙问题，只跟设定有关系，跟代码没关系
2. 没变，就是代码问题，注意看是不小心清掉了呢，还是开发人员根本没有考虑有客户端的各种行为

 

路过的人添砖加瓦阿