Всем добрый день! У меня есть вопрос к знающим людям.
Предистория: Есть файл, из которого на прибор идет подача команд. Когда прибор виснет или появляется ошибка, то в журнале ошибок Event Viewer появляется соответствующая запись. Мне нужно отследить момент появления этого сообщения и прекратить подачу команд в прибор. Но не просто прекратить, а и зафиксировать то, какая команда передалась последней, чтобы дальше прогонять предыдущие несколько команд, приближаясь к комбинации, вызвавшей вылет программы или ошибку. Таким образом, научившись программно реагировать на факт добавления сообщения о вылете основной программы в журнал событий, можно вовремя остановить ПО тестирование, и отметить в логе этого ПО, примерно после каких воздействий произошёл вылет.
А теперь сам вопрос: Как программно отслеживать факт добавления сообщения о вылете основной программы в журнал событий? Подскажите, пожалуйста!      

Это сообщение отредактировал(а) PrAviva - 13.11.2009, 18:02

NotifyChangeEventLog

Здравствуйте! Я снова решила вернуться к непонятному мне вопросу. Вот пример, который я нашла относительно работы с журналом событий и фиксации с помощью функции NotifyChangeEventLog() появления сообщения о событии:


Но это только самое начало. Дело в том, что мне нужно фиксировать не просто наличие добавления новой записи в журнад событий, а и отмечать в др. месте (некотором log-файле) список последних, например, 10-ти отосланных кодов нажатия пульта. Это поможет выявить комбинацию, привеждую к вылету прибора. Но тут море вопросов. 
Например, получили мы сообщение "An event has been logged". И что с этим делать? Ведь мне нужно понять не только то, что был сбой, но и какие отсылаемые коды команд к этому сбою привели. Если я беру пересылаемые коды из какого-то файла, то может нужно писать какой-то счетчик, который будет фиксировать порядковый номер кодов?В том смысле, чтобы по вылету можно было в огромном массиве данных файла и кодами выделить именно ту команду, после которой произошел вылет. И как это организовать? Есть ли идеи? Заранее спасибо за помощь!       

Это сообщение отредактировал(а) PrAviva - 30.11.2009, 15:32

ну и в чем же проблема?
http://msdn.microsoft.com/en-us/library/aa363654(VS.85).aspx
не такой большой список функций, чтобы запутаться

Добавлено через 3 минуты и 1 секунду
 + примеры: http://msdn.microsoft.com/en-us/library/bb427356(VS.85).aspx

GremlinProg, спасибо, мне с функциями вцелом ясно. Вопрос в том, как следить за потоком кодов коман? Зависание я при помощи журнала сообщений отловлю, а вот последовательность переданных кодов? Мне нужно после того, как функция NotifyChangeEventLog() укажет на наличие новой записи в журнале событий бежать в др. файл, куда ранее записывалить коды переданных команд и анализировать, например, последние 10-ть. Вопрос в том как это осуществить?Ведь прибор-то висит. Или после перезагрузки данные в этом файле останутся даже без сохранения?       

это зависит от прибора, посмотри его документацию,
либо - воочию убедиться в том, что он делает при сбое,

можно предположить, что если файл используется как очередь(FIFO), и чтение и исполнение команд устройством небуферизировано,
то к сбою привела команда, записанная в этот файл непосредственно перед той командой,
которая расположена в самом начале, т.е. перед первой

т.е. узнать можно следующую команду после сбоя,
но это опять же зависит от самого прибора: если он удаляет команду из FIFO после выполнения этой команды,
то команда, приведшая к сбою прибора будет первой в очереди

вобщем, без документации на прибор можно только гадать

Добавлено через 3 минуты и 47 секунд

скорее даже от драйвера, поставляющемуся с этим прибором

GremlinProg, а если это будет log-файл? Ведь этот тип файлов автоматически сохраняется после вылета прибора. 

Кстати, при сбое прибор последние данные и все-все, что не было "принудительно" сохранено в архиве, не сохраняет. Так что файл, где будет регистрироваться постоянно пополняемая последовательность кодов должен автоматически сохраняться послы вылетов. 

А вообще я читала, что изначально журналов событий три, но можно создавать свои журналы, и регистрировать свои приложения как источники событий для этих журналов (в моем случае - я думаю, может записывать туда последовательность кодов? Ведь журнал событий уж точно после вылета сохранится). 

Может есть путь попроще? есть какая нибудь команда вроде "по вылету закрыть все приложения с автоматическим сохранением"?    Это бы очень упростило задачу, которая сейчас еще на стадии обдумывания.

Это сообщение отредактировал(а) PrAviva - 30.11.2009, 17:44

PrAviva, человеческим языком объясни: что за прибор, как он работает, что за архив, и при чем тут лог файлы?

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

если я вообще правильно въехал в проблему:

1. имеется какое-то устройство
2. это устройство воспринимает последовательность команд
3. для этого устройства есть драйвер (служба)
4. драйвер мониторит определенный файл команд (на диске) и отправляет их (команды) устройству

5. есть приложение, которое пишет в этот файл команды
6. и следит за тем, чтобы устройство их выполнила
7. если происходит зависание устройства, происходит запись в журнал событий
8. программа, при этом, должна прекратить запись в файл
9. и определить, какая команда была выполнена последней (та, что привела к ошибке)

ПО прибора написано не мною, моя же задача - выявление причин вылетов, определение последовательностей действий, приводящих к вылетам, зависаниям и ошибкам. 
Прибор воспринимает последовательность команд от пульта. Я же беру файл с набором кодов этих самых команд, передаю прибору и должна анализировать вылеты и разбираться с теми командами, которые их вызвали (например, с последними 10-ю переданными).  Пункты 7, 8 и 9 - моя глобально задача. Нужно следить за журналом событий, передавая коды команд из файла в файл, после вылета нужно четко знать "что последнее пришло", а дальше уже вручную разбираться с кодами команд и выявлять ошибочную комбинацию.



Это сообщение отредактировал(а) PrAviva - 1.12.2009, 10:59

раз передаешь команды прибору сама, значит порядок этих команд можно спокойно контролировать,
типа такого:

MS - подобрать вручную - это минимальное число мс., за которое сканер точно обработает 1 команду
будет работать медленно, но, по крайней мере, ошибку точно найдешь, если откалибруешь MS

если нет постоянного доступа к сканеру, чтобы подобрать параметры, MS можно вынести в GUI и отлаживать на месте