代码之家  ›  专栏  ›  技术社区  ›  BenAlabaster

当控制台应用程序使用完全相同的基本库执行完全相同的操作时,什么会导致Windows服务挂起?

  •  3
  • BenAlabaster  · 技术社区  · 16 年前

    背景: 我有一个DLL,它是一个定时进程应用程序的核心。我的计时器接收其运行时间间隔的配置,以及在时间间隔结束时应运行的委托。我有另一个DLL,其中包含我注入的进程。

    问题: N 几周后,在使用Windows服务的生产环境中,一切正常。今天,Windows服务将运行约20-30分钟并挂起(计时器间隔为30秒),但控制台应用程序运行时没有问题,在过去4小时内没有问题。详细的日志记录并不表示有任何故障。这就好像Windows服务只是……悄无声息地死去——没有停止。

    考虑到我的Windows服务和控制台应用程序正在做完全相同的事情,我只能认为是某种原因导致Windows服务进程挂起,但我不知道是什么原因导致了挂起。我已经检查了配置文件,它们都是相同的——我甚至复制并粘贴了其中一个文件的内容到另一个文件中,只是为了确定。没有骰子。

    谢谢大家的帮助-还在挖。

    8 回复  |  直到 16 年前
        1
  •  8
  •   Paul Sasik    16 年前

    您需要弄清楚生产服务器上发生了什么变化。一开始,负责IT的人会发誓什么都没有改变,但你必须坚持不懈。我经常看到这种情况,我数不清。 这种变化一定是环境造成的。

    执行上的差异:

    另一个想法是: 由于计时似乎是问题的一部分,请检查机器上的计划任务。也许有一个过程设置为每30分钟进行一次,这会干扰你自己的过程。

        2
  •  3
  •   HTTP 410    16 年前

    您可以通过以下方式调试Windows服务: running it interactively within Visual Studio . 这可以帮助您通过设置(可能是有条件的)断点来隔离问题。

    你在使用断言吗?如果一个断言在没有被重新定向为写入日志文件的情况下触发,您的服务将挂起。如果代码抛出未经处理的异常,可能是因为内存泄漏,那么您的服务进程将崩溃。如果将服务控制管理器(SCM)设置为在发生崩溃时重新启动进程,则应该能够看到服务已重新启动。由于在这两种环境中运行的代码相同,因此这两种情况似乎不太可能发生。但请记住,您的服务是由SCM托管的,这意味着与您的console应用程序运行的环境截然不同。

    另一种可能是某种权限问题,因为该服务可能与控制台的其他本地/域用户一起运行。

    sc queryex服务名称 . 这将为您提供服务的当前状态。

        3
  •  1
  •   Joe Phillips    16 年前

        4
  •  1
  •   Raj More    16 年前

    你可以试试这些技巧

    • 登录中

    • 本地或远程将带有代码的调试器附加到正在运行的服务,设置适当的断点(可以基于从日志记录中收集的数据)

    • 性能监视器 运行此实用程序并收集有关运行服务的机器的信息,以获取任何其他线索(CPU峰值高、IO峰值高、分页过多等)

        5
  •  0
  •   JasCav    16 年前

    微软在这方面提供了很好的资源 debugging a Windows Service

    同样,我认为您必须进行一些认真的调试才能发现问题。

        6
  •  0
  •   SwDevMan81    16 年前

    Here 这是一个很好的教程,只是为了确保您设置正确,并使用正确类型的计时器。希望有帮助。

        7
  •  0
  •   Brett Allen    16 年前

    关于psasik的回答,另一个潜在的问题是,您的应用程序是否依赖于仅在用户模式下运行时可用的东西。

        8
  •  0
  •   Daniel    16 年前

    闻起来像是穿线的问题。是否有任何线程或异步工作正在进行?一个关键问题是“服务是否每次都挂在同一行代码或同一个方法上?”使用日志记录找出挂起之前发生的最后一件事,如果是,发布问题代码。

    您可以考虑的另一个工具是一个好的分析器。如果是.NET代码,我相信RedGate ANTS可以监视它,并为您提供任何线程锁场景的良好图片。

    推荐文章