CODEWITHSUNDEEP
c#.netservicewindows-servicesfilesystems
AnkitMittal
AnkitMittal

Reputation: 164

Windows service with FileWatcher not working as expected

A windows service (viz Email_Tool), which was working fine earlier, has not been working properly lately.

Service Overview

  1. Email_Tool is a windows service which polls a directory using FileWatchers.
  2. It keeps watching the directory and upon receiving certain files it sends out emails to the users.
  3. The path it watches is a shared path with different permissions for different users. My service uses a service account with Read permissions.
  4. The receipt of files and sending of emails get logged to a file (viz ServiceLog.txt).
  5. An example to explain the workflow: The folder with the name 21052014 (a folder with the name as current date is created) is created in the location mentioned above. In that folder few files arrive(Date.txt, InputsLog_20140520.txt, PTool_Start_20-05-2014.txt, PTool_End_20-05-2014.txt) . The service thus sends a mail, logging every step in a log file for support operations.

Problem faced

The Email_Tool has not been working as expected since few days. The steps are not getting logged in the log file and the emails are not being sent out.

Steps Taken

We have taken many steps to identify the problem. The following are few of them:

  1. To prove that the code is working, we used the local file path(F drive) of lower environment as the file path. The service worked fine and the mail was sent.
  2. We tried using the shared path on a lower environment as the path. The service worked fine and mail was sent.
  3. We tried using the shared path which is used in Production from other lower environments , where we created new folders and gave them appropriate permissions. This didn’t work out.

As is clear, the service, which was working earlier, is not working for the shared paths which were used in Production.

Information worth Noting

  1. When we STOP and then START the service, and try to see the workflow by creating folder and moving in files(as mentioned in the service overview above), the service works for a couple of steps and then goes haywire. I can confirm this as I can see the steps for folder creation in the log file sometimes(not always). I am unable to understand why this works for a couple of steps and then stops to work as on other file servers it works perfectly.
  2. Just a day before the service went haywire, the shared path was moved to a different hadrware. We are almost sure that the problem has been caused by this. But the teams maintaining this shared path have confirmed that the permissions have been kept intact after the hardware migrations.
  3. I tried to debug the code by moving the code into a forms application and came up with the following numbers/codes:

BaseException

Base exception area gave the following codes:

ErrorCode: -2147467259 Native Error code : 58

The above native error code 58 points to the following(google search)

ERROR_BAD_NET_RESP 58 (0x3A) The specified server cannot perform the requested operation.

InnerException

The inner exception showed the following code:

_COMPlusExceptionCode -532459699 int

Codes

the service start event has this code snippet

   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;

As a workaround, we have used another file server temprarily which on which the service is working fine. But we have to find a fix. Please let me know if there is any other information that I must provide. I had posted this question earlier, but I think this post provides more details.

Upvotes: 1

Views: 2431

Answers (2)

AnkitMittal
AnkitMittal

Reputation: 164

Had found the root cause of this issue. The watched directory was getting detached from the network drive, maybe due to network glitches. Even after the directory was getting attached, the file watcher could not watch this directory until it was restarted.

The solution would be to raise an exception when such a thing happens and then restart the watcher automatically(or any other method to gracefully handle the situation)

There is a flag for this: EnableRaisingEvents. This has to set to true to capture such errors. Read about EnableRaisingEvents here.

Upvotes: 1

nvoigt
nvoigt

Reputation: 77364

There is a sentence in the documentation that reads:

Remote computers must have one of the required platforms installed for the component to function properly.

If your hardware changed, make sure you still have one of the required platforms on the other side of the FileSystemWatcher.

Upvotes: 0

Related Questions