接口服务运行一段时间后,IIS应用池就会突然挂掉,事件查看日志,会有事件日志Event ID为5011的错误
最后直接程序池直接被禁用
查看管理事件
Application Error
错误模块名称: KERNELBASE.dll,版本:
6.1.7601.17514,时间戳: 0x4ce7bafa
异常代码: 0xe0434352 错误偏移量: 0x0000b727 错误进程 ID: 0xc1c 错误应用程序启动时间: 0x01d045ca298f9b3c 错误应用程序路径: C:WindowsSysWOW64inetsrvw3wp.exe 错误模块路径: C:Windowssyswow64KERNELBASE.dll 报告 ID: eb60afd0-b1bd-11e4-9f2d-005056a934bb
.NET Runtime
Description: The process was terminated due to an unhandled exception.
Exception Info: System.AggregateException
Stack:
at System.Threading.Tasks.TaskExceptionHolder.Finalize()
初步排查代码确定有可能的几点
1.项目中使用了dapper ,使用了using,跟踪了源码发现已经有对连接池的处理
int flagNum = new SqlConnection(DBSetting.XXX).Execute("SPS_BookForApp", param, commandType: CommandType.StoredProcedure);
2.由之前的委托异步改为基于任务Task的异步
Func<string, string> func = f => { if (!string.IsNullOrEmpty(orderNo) &&orderNo.IsPositiveInt()) { //记录订单量 } else { return string.Empty; } }; func.BeginInvoke("Logging Order Data", ir => { var ar = (AsyncResult)ir; var fun = (Func<string, string>)ar.AsyncDelegate; string returnValue = fun.EndInvoke(ir); if (!string.IsNullOrEmpty(returnValue)) { //判断是否记录成功 } }, null);
改为
Task.Factory.StartNew(() => { // })
没有去捕获异常,想起之前看过的dudu说过这样的问题 ,于是修改了下
var task = Task.Factory.StartNew(() => { throw new MyCustomException("Task1 faulted."); }) .ContinueWith((t) => { Console.WriteLine("I have observed a {0}", t.Exception.InnerException.GetType().Name); }, TaskContinuationOptions.OnlyOnFaulted);
现运行良好。
Refer:
Exception Handling (Task Parallel Library)
https://msdn.microsoft.com/en-us/library/dd997415.aspx
http://www.cnblogs.com/dudu/archive/2012/04/05/task_unhandled_exception_application_crash.html
Exception Handling with the Task Parallel Library
http://www.ademiller.com/blogs/tech/2010/10/exception-handling-with-the-task-parallel-library/
Exception while running system threading tasks task
http://stackoverflow.com/questions/15804059/exception-while-running-system-threading-tasks-task
http://stackoverflow.com/questions/7883052/a-tasks-exceptions-were-not-observed-either-by-waiting-on-the-task-or-accessi/7883083