Служба Windows с FileWatcher не работает должным образом

1

Служба Windows (например, 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 drive) более низкой среды в качестве пути к файлу. Служба работала нормально, и почта была отправлена.
  2. Мы попытались использовать общий путь в нижней среде в качестве пути. Служба работала нормально, и почта была отправлена.
  3. Мы попытались использовать общий путь, который используется в Production из других более низких сред, где мы создали новые папки и предоставили им соответствующие разрешения. Это не сработало.

Как ясно, служба, которая работала ранее, не работает для общих путей, которые использовались в Production.

Полезная информация

  1. Когда мы остановимся, а затем запустите службу и попытайтесь увидеть рабочий процесс, создав папку и перемещая файлы (как упоминается в обзоре сервиса выше), служба работает на несколько шагов, а затем переходит в режим haywire. Я могу подтвердить это, так как иногда я вижу шаги для создания папок в файле журнала (не всегда). Я не могу понять, почему это работает на пару шагов, а затем перестает работать, как на других файловых серверах, он отлично работает.
  2. Всего за день до того, как служба пошла на уступку, общий путь был перенесен в другое приложение. Мы почти уверены, что проблема была вызвана этим. Но команды, поддерживающие этот общий путь, подтвердили, что разрешения были сохранены без изменений после аппаратных перенастроек.
  3. Я попытался отладить код, переместив код в приложение форм и придумал следующие номера/коды:

BaseException

Базовая область исключений дала следующие коды:

ErrorCode: -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;

В качестве обходного решения мы часто использовали другой файловый сервер, на котором служба работает нормально. Но мы должны найти исправление. Пожалуйста, дайте мне знать, есть ли какая-либо другая информация, которую я должен предоставить. Ранее я разместил этот вопрос, но я думаю, что этот пост содержит более подробную информацию.

Теги:
windows-services
filesystems
service

2 ответа

0
Лучший ответ

Он нашел основную причину этой проблемы. Наблюдаемый каталог был отсоединен от сетевого диска, возможно, из-за сетевых сбоев. Даже после того, как каталог подключился, наблюдатель за файлом не смог просмотреть этот каталог до его перезапуска.

Решение заключалось бы в том, чтобы возбуждать исключение, когда такое происходит, и затем автоматически перезапускать наблюдателя (или любой другой метод, чтобы изящно обрабатывать ситуацию)

Для этого есть флаг: EnableRaisingEvents. Это должно быть верно для захвата таких ошибок. Подробнее о EnableRaisingEvents читайте здесь.

0

Существует предложение в документации, которая гласит:

На удаленных компьютерах должна быть установлена одна из необходимых платформ для правильной работы компонента.

Если ваше оборудование изменилось, убедитесь, что у вас все еще есть одна из необходимых платформ с другой стороны FileSystemWatcher.

  • 0
    Итак, если я правильно понял, то на удаленном файловом сервере должно быть одно из следующих: Windows 8.1, Windows Server 2012 R2, Windows 8, Windows Server 2012, Windows 7, Windows Vista SP2, Windows Server 2008 (Server Core Роль не поддерживается), Windows Server 2008 R2 (роль сервера Core поддерживается с пакетом обновления 1 (SP1) или более поздней версии; Itanium не поддерживается)
  • 0
    Да, похоже так. Никогда сам не пробовал.
Показать ещё 2 комментария

Ещё вопросы

Сообщество Overcoder
Наверх
Меню