|
3
|
| BenAlabaster · 技术社区 · 16 年前 |
|
|
1
8
您需要弄清楚生产服务器上发生了什么变化。一开始,负责IT的人会发誓什么都没有改变,但你必须坚持不懈。我经常看到这种情况,我数不清。 这种变化一定是环境造成的。 执行上的差异: 另一个想法是: 由于计时似乎是问题的一部分,请检查机器上的计划任务。也许有一个过程设置为每30分钟进行一次,这会干扰你自己的过程。 |
|
2
3
您可以通过以下方式调试Windows服务: running it interactively within Visual Studio . 这可以帮助您通过设置(可能是有条件的)断点来隔离问题。
你在使用断言吗?如果一个断言在没有被重新定向为写入日志文件的情况下触发,您的服务将挂起。如果代码抛出未经处理的异常,可能是因为内存泄漏,那么您的服务进程将崩溃。如果将服务控制管理器(SCM)设置为在发生崩溃时重新启动进程,则应该能够看到服务已重新启动。由于在这两种环境中运行的代码相同,因此这两种情况似乎不太可能发生。但请记住,您的服务是由SCM托管的,这意味着与您的console应用程序运行的环境截然不同。
另一种可能是某种权限问题,因为该服务可能与控制台的其他本地/域用户一起运行。 sc queryex服务名称 . 这将为您提供服务的当前状态。 |
|
|
3
1
|
|
4
1
你可以试试这些技巧
|
|
|
5
0
微软在这方面提供了很好的资源 debugging a Windows Service 同样,我认为您必须进行一些认真的调试才能发现问题。 |
|
|
6
0
Here 这是一个很好的教程,只是为了确保您设置正确,并使用正确类型的计时器。希望有帮助。 |
|
|
7
0
关于psasik的回答,另一个潜在的问题是,您的应用程序是否依赖于仅在用户模式下运行时可用的东西。
|
|
|
8
0
闻起来像是穿线的问题。是否有任何线程或异步工作正在进行?一个关键问题是“服务是否每次都挂在同一行代码或同一个方法上?”使用日志记录找出挂起之前发生的最后一件事,如果是,发布问题代码。 您可以考虑的另一个工具是一个好的分析器。如果是.NET代码,我相信RedGate ANTS可以监视它,并为您提供任何线程锁场景的良好图片。 |