#c #windows-xp-embedded
#c #windows-xp-embedded
Вопрос:
У нас есть приложение, работающее на нескольких тысячах идентичных компьютеров. Та же ОС, то же оборудование, та же установка приложения. В очень редких случаях компьютер блокируется. Alt tab, ctrl-alt-del, приложение не отвечает. После проверки файла журнала наших приложений серия символов null записывается в конец, как последние данные перед сбоем.
Я надеюсь использовать этот факт как средство для отладки блокировки. Я предполагаю, что количество записанных символов null эквивалентно пространству, которое мне нужно выделить для моей инструкции log, но содержимое на самом деле никогда не записывается на диск. Я также предполагаю, что возникла проблема с дисковым вводом-выводом, предотвращающая запись и, конечно, блокировку ОС. Я не могу подтвердить это. Итак, я предполагаю, что мой вопрос заключается в следующем: вы когда-нибудь сталкивались с подобным состоянием, как это произошло, и как вы могли бы устранить его?
Комментарии:
1. У вас есть утечка памяти в коде? т. Е. процесс продолжает увеличиваться.
2. Я бы сказал, что это аппаратная блокировка (DMA или SATA); Я действительно не ожидаю, что найденные на диске значения null будут значительными, но вам полезно поспрашивать
3. То, что вы описываете, похоже на взаимоблокировку в режиме ядра. Ваше приложение может взаимодействовать с каким-либо некорректным драйвером.
4. Они всегда «зависают», или машины выходят из строя с разного рода ошибками? Если он всегда «зависает», у вас, вероятно, плохо спроектированное оборудование или драйверы ошибок. Также может быть что-то перегревающееся — сначала я бы проверил температуру графического процессора. Если это разные виды сбоев, это, вероятно, неисправное оборудование. Например, плохая оперативная память может вызывать всевозможные ошибки. ps.: удачи, подобные вещи могут быть действительно неприятными для отслеживания!
5. У нас есть несколько проприетарных драйверов, поэтому мы определенно подозреваем, что они глючат. Только идентификатор, это был bsod с файлом dmp. Перегрев не является проблемой, мы провели обширное тестирование там. Это очень редкая ошибка, вероятно, 1 событие примерно за 3,2 миллиона машинных часов.
Ответ №1:
NTFS не записывает данные (только метаданные), поэтому подобные вещи могут произойти. Причина в том, что во время сбоя / зависания были зафиксированы метаданные (размер файла, распределение блока данных), но не данные (содержимое блока данных). К сожалению, это нормальное поведение с NTFS и не даст вам никакого представления о проблеме, вызывающей зависание.
Итак, ответ таков: сбой в «нужное» время может вызвать это.
Кстати: то же самое, конечно, может произойти с FAT / FAT32.
Комментарии:
1. Есть ли способ проверить, что это было причиной?
Ответ №2:
Я видел, как происходят подобные вещи, я думаю, вы смотрите в правильном направлении.
Когда это произойдет, я полагаю, вы сможете точно определить аппаратное обеспечение? после сбоя я бы рекомендовал запустить memtest (http://www.memtest.org/).
Я видел подобные вещи с блоками питания, неисправными дисковыми контроллерами и т.д. Вы можете сойти с ума, пытаясь отследить их.
Похоже, вы поступаете правильно — посмотрите, сможете ли вы найти способ ускорить решение проблемы, когда это произойдет запустите memtest, запустите chkdsk / R (проверьте журнал событий на наличие ошибок контроллера во время этого)
есть ли шанс, что вы могли бы подключить отладчик ядра?
есть ли вероятность, что был создан %SystemRoot%memory.dmp?
Комментарии:
1. Из-за возраста устройства и окружающей среды у нас возникают сбои почти во всех компонентах компьютера. (Un) к счастью, машина восстанавливается после цикла питания, поэтому мы не можем точно определить сбой. Я порекомендую memtest в следующем случае, который мы увидим. Мы также проверим наличие memory.dmp, но я сомневаюсь, что это было написано, поскольку нет bsod. Chkdsk / r запускается автоматически после загрузки, поэтому мы также проверим журнал событий. Отладчик ядра — это не вариант — это в производственной среде и не может быть надежно воспроизведено в тестировании.