Вход/контроль всех вызовов функции из приложения

Вы получаете повторяющиеся записи, потому что вы выполняете запрос дважды. Первый раз с db.ExecuteNonQuery, а затем второй с cmd.ExecuteScalar();.

Удалить первую db.ExecuteNonQuery строку. Тогда это будет отлично работать.

6
задан 30 September 2008 в 07:54
поделиться

6 ответов

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

Если бы это был я, то я попытался бы запустить программу на другом ПК - это могли бы быть облупленные аппаратные средства или драйверы, вызывающие проблему. Прикладная программа "не должна" мочь снизить систему.

2
ответ дан 9 December 2019 в 22:42
поделиться

Вход функциональных записей/выходов является подходом низкого уровня к Вашей проблеме. Я предложил бы использовать автоматический инструментарий отладчика (использующий ключ Отладчика под Опциями Выполнения Файла изображения с regedit или использующий gflags от пакета, на который я предоставляю ссылку ниже), и пробующий к репродукции проблема, пока это не отказывает. Кроме того, Вы можете иметь историю вызова функции журнала отладчика подозреваемого модуля (модулей) с помощью сценария или иметь, собирают любую другую информацию.
Но не зная детали Вашего приложения очень трудно предложить решение. Действительно ли это - пользовательское приложение, сервис или драйвер? Что делает "катастрофические отказы при запуске", среднем - при запуске окон или запуск приложения?
Используйте этот пакет отладчика для поиска и устранения неисправностей.

3
ответ дан 9 December 2019 в 22:42
поделиться

Несколько Идей -
Существует хороший шанс что только до Вашего катастрофического отказа в приложении существует своего рода исключение. если Вы устанавливаете Вас обработчик для всего использования необработанных исключений SetUnhandledExceptionFilter () и пишете отслеживание стека в Ваш файл журнала, у Вас мог бы быть шанс поймать катастрофический отказ в действии.
Просто не забудьте сбрасывать файл после каждой записи.

Другая опция состоит в том, чтобы использовать инструмент, такой как strace, который регистрирует все системные вызовы в ядро (существует несколько разновидностей и реализаций для этого, так выберите своего фаворита). при рассмотрении журнала непосредственно перед катастрофическим отказом, Вы могли бы найти преступника

2
ответ дан 9 December 2019 в 22:42
поделиться

GCC (включая версию MingGW для разработки Windows) назвали переключатель генерации кода - finstrument-функции, который говорит компилятору испускать специальные вызовы к функциям, вызванным __ cyg_profile_func_enter и __ cyg_profile_func_exit вокруг каждого вызова функции. Для Visual C++ существуют подобные опции, названные/GH и/Gh. Они заставляют компилятор испускать вызовы к __ вздыхатель и __ pexit вокруг вызовов функции.

Эти режимы инструментария могут использоваться для реализации системы регистрации с Вами реализующий вызовы, которые компилятор генерирует для вывода к локальной файловой системе или к другому компьютеру в сети.

Если возможно, я также попытался бы выполнить Вашу систему с помощью valgrind или подобный инструмент проверки. Это могло бы поймать Вашу проблему, прежде чем она выйдет из-под контроля.

0
ответ дан 9 December 2019 в 22:42
поделиться

Вы рассмотрели использование второй машины как удаленного отладчика (через сеть)? Когда приложение (и система) катастрофические отказы, вторая машина должна все еще показать немного полезной информации, если не реальная точка проблемы. Я полагаю, что VC ++ имеет ту способность, по крайней мере, в некоторых версиях.

2
ответ дан 9 December 2019 в 22:42
поделиться

Для Visual C++ _penter () и _pexit () может использоваться для оснащения кода.

См. также Перехват Вызова метода в C++.

2
ответ дан 9 December 2019 в 22:42
поделиться
Другие вопросы по тегам:

Похожие вопросы: