问题描述
发生一件很怪异的事，用Timer定时每隔3秒钟进行一次数据同步操作，一开始很正常,但是过了一段时间后Timer中的代码却不运行了，然后查看Timer的状态，确实还是启动状态，但是就是不运行Timer中的事件，这是怎么回事呢，在客户的一台电脑上发生这个现象，其他电脑都没有示例代码privatevoidtmr_work_Tick(objectsender,EventArgse){tmr_work.Enable=false;try{//这里是数据同步操作}catch(Exceptionex){}finally{tmr_work.Enable=true;}}
解决方案
解决方案二：
如果你懒得在开发的机器上来想法重现用户的bug，那么就要在用户的机器上部署一个没有catch{}的版本。可能你没有搞清楚try...catch的目的是什么。如果要发布一个程序，那么也许会在用户面前隐瞒一些bug。但是即使如此，也就是在整个系统的表现层（例如UnhandledException事件处理中）捕获异常并给用户另外一套对应的假提示。而你的代码，如果你在解决bug时也这样写try..catch，那么我相信你就没有负责任地把程序bug“捉出来”。对用户隐瞒信息的伎俩，现在变成糊弄自己了！这里不可能胡乱猜出bug是什么。而是先要学会让bug能够“出来”（而不是带病进行后续操作）的基本开发素质。
解决方案三：
可能你会找到理由说“我只是在一个用户的机器上有bug，其它电脑都没有啊。我只想要猜出来的结果让我试试就行了”。但是程序如果因为开发和测试质量低而又bug时，假设碰上负责任的程序员还这样说，那么这个公司一定会很悲剧的。
解决方案四：
其实很可能是占用的内存未及时释放造成的当内存被耗尽时，程序就会被挂起，甚至退出那么异常处理会生效吗？我看悬！即便能生效，程序都停止了，异常的可能原因还能展示出来吗？只要使用Timer，基本上都会碰到这种问题。估计高手们都不用Timer的
解决方案五：
引用楼主ltaixxx的回复:
代码却不运行了，然后查看Timer的状态，确实还是启动状态，但是就是不运行Timer中的事件，这是怎么回事呢
程序如果崩溃，就不会能够”查看Timer状态是启动状态“了。程序崩溃了，至少代表着你不隐瞒bug，那么在后续debug的操作上才能前进一大步。
解决方案六：
这个诡异的问题，实际上很可能不会是你贴出的”这里是数据同步操作“这里的代码造成的。你贴出的说明不了任何问题。我只是从你贴出代码，看到一个公司的技术经理会怎样让你将所有代码进行整改的问题。