带有FileWatcher的Windows服务无法正常工作

Question

早期运行良好的Windows服务（ viz Email_Tool ）最近无法正常运行。

服务总览

1. Email_Tool是Windows服务，可使用FileWatchers轮询目录。
2. 它一直在监视目录，并在接收到某些文件后向用户发送电子邮件。
3. 它监视的路径是对不同用户具有不同权限的共享路径。 我的服务使用具有读取权限的服务帐户。
4. 文件的接收和电子邮件的发送被记录到文件中（即ServiceLog.txt ）。
5. 一个说明工作流程的示例：在上面提到的位置中创建了名称为21052014的文件夹（已创建名称为当前日期的文件夹）。 在该文件夹中，几个文件到达（Date.txt，InputsLog_20140520.txt，PTool_Start_20-05-2014.txt，PTool_End_20-05-2014.txt）。 该服务因此发送邮件，将每个步骤记录在日志文件中以进行支持操作。

面临的问题

几天以来，Email_Tool一直无法正常工作。 这些步骤未记录到日志文件中，并且电子邮件也未发送出去。

采取的步骤

我们已采取许多步骤来确定问题。 以下是其中一些：

1. 为了证明代码可以正常工作，我们使用较低环境的本地文件路径（F驱动器）作为文件路径。 服务工作正常，邮件已发送。
2. 我们尝试将较低环境中的共享路径用作路径。 服务工作正常，邮件已发送。
3. 我们尝试使用其他较低环境在Production中使用的共享路径，在该环境中我们创建了新文件夹并为其赋予了适当的权限。 这没有解决。

显然，早先使用的服务不适用于生产中使用的共享路径。

值得注意的信息

1. 当我们先停止然后再启动该服务，并尝试通过创建文件夹并移入文件来查看工作流程时（如上面的服务概述中所述），该服务将执行几个步骤，然后开始运行。 我可以确认这一点，因为有时（并非总是）可以在日志文件中看到创建文件夹的步骤。 我无法理解为什么这样做需要几个步骤，然后又无法像在其他文件服务器上一样正常工作。
2. 在该服务开始日趋混乱之前的一天，共享路径已移至其他硬件。 我们几乎可以确定问题是由此引起的。 但是维护此共享路径的团队已确认，在迁移硬件后，权限保持不变。
3. 我试图通过将代码移到表单应用程序中来调试代码，并得出以下数字/代码：

BaseException

基本例外区域给出了以下代码：

错误代码：-2147467259本机错误代码58

上面的本机错误代码58指向以下内容（Google搜索）

ERROR_BAD_NET_RESP 58（0x3A）指定的服务器无法执行请求的操作。

的InnerException

内部异常显示以下代码：

_COMPlusExceptionCode -532459699 int

代码

服务启动事件具有此代码段

   m_Watcher = new System.IO.FileSystemWatcher();
            m_Watcher.Filter = "*.*";
            m_Watcher.Path = @filWatcherPath;
            m_Watcher.IncludeSubdirectories = true;



            m_Watcher.NotifyFilter = NotifyFilters.LastAccess | NotifyFilters.LastWrite
                                 | NotifyFilters.FileName | NotifyFilters.DirectoryName;
            m_Watcher.Created += new FileSystemEventHandler(OnChanged);

            //  m_Watcher.Error += new ErrorEventHandler(OnError);

            m_Watcher.EnableRaisingEvents = true;

解决方法是，我们暂时使用了另一台文件服务器，该服务器可以在该服务器上正常工作。 但是我们必须找到解决办法。 如果需要我提供其他信息，请告诉我。 我之前已经发布了这个问题，但是我认为这篇文章提供了更多细节。

Answer 1

文档中有一句话是：

远程计算机必须安装必需的平台之一才能使组件正常运行。

如果更改了硬件，请确保FileSystemWatcher的另一侧仍具有所需的平台之一。

Answer 2

已找到此问题的根本原因。 受监视的目录正与网络驱动器分离，这可能是由于网络故障造成的。 即使在附加目录之后，文件监视程序也无法监视该目录，直到重新启动它为止。

解决方案是在发生此类情况时引发异常，然后自动重新启动观察程序（或其他任何可以妥善处理此情况的方法）

为此有一个标志：EnableRaisingEvents。 必须将其设置为true才能捕获此类错误。 在此处阅读有关EnableRaisingEvents的信息 。