经查,系统经常会造成IIS相关进程意外关闭,如:aspnet_wp.exe (PID: 1936)意外停止。
多次操作后,已经是晚上11点,虽然还不能准确定位Bug发生点所在,但已经找到了Bug统计意义上的出现位置。让人惊奇的是调试信息里告知异常位于:System.Web的命名空间里。。。。。
System.NullReferenceException: Object reference not set to an instance of an object.
at System.Web.SessionState.SessionStateModule.PollLockedSessionCallback(Object state)
at System.Threading._TimerCallback.TimerCallback_Context(Object state)
at System.Threading.ExecutionContext.runTryCode(Object userData)
at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading._TimerCallback.PerformTimerCallback(Object state)
这怎么可能嘛,我程序的异常无法定位,居然报系统内部出错?
用Google一查,居然只在英文网页里找到一个相关信息,http://forums.asp.net/t/1132396.aspx,解决方法是:
“I had the exact same issue along with many of the developers on my team. We removed the Security Update for .NET Framework 2.0 (KB928365) from our machines and the problem went away. Your hunch was correct and most helpful! The web is loaded with various issues that this "fix" is causing.”
晕倒了,居然是MS的补丁有Bug,此时我的心情真是高兴,搞定了。。。
但且慢,我系统里的Bug真的是这个KB928365引起的吗?
测试过后确认就是这个补丁的问题了,心情有2种:
从系统不稳定的解决角度来看,我是很高兴,很爱这个KB928365
从引起不稳定的角度来看,我真想日死MS。。。。
第二天去客户那里卸载了KB928365后,经检查系统日志,IIS相关进程一切正常。
随后我查了KB928365相关的网页,居然也有一些系统Over的案例,巧的是,在我常去的论坛里也有类似的案例:http://bbs4.nnsky.com/dispbbs_10_4017891.html
这些系统不稳定的共性是:异步。到此,基本可以得到推论:该安全补丁在判断系统动作时的安全规则有问题。
补充一点,我还查到MS以前出的Dot Net1.1的安全补丁也有类似问题,引起WP进程意外关闭。