Есть некий процесс-сервис, работающий с железкой. На некоторых единичных
системах он иногда (раз в неделю примерно) наглухо зависает. Да так
зависает, что не снимается с диспетчера задач. В чём может быть причина
того что процесс даже не убить? Может ли антивирус быть причиной?
_>В чём может быть причина того что процесс даже не убить?
Например, запрос ушёл в ядро, но так и не вернулся и чего-то ждёт в состоянии non-alertable, а отменялку поставить забыли. Почему и чего там ждут — отдельный вопрос. Ты чем гадать здесь поди и дамп системы сделай (manully-initiated crash, если это на реальной машине происходит), там уже можно будет посмотреть состояния потоков и так далее, всяко яснее станет.
_>Может ли антивирус быть причиной?
Скорее нет, чем да, ну по крайне мере я такого не замечал за ними. Более вероятно, какой-нибудь другой кривой драйвер-фильтр.
У меня, кстати, похожая ситуация возникает с некоторой периодичностью: при отладке тяжеловесных приложений(может совпадение, но имеющих по 15 — 20 потоков) иногда дебагер виснет при пошаговом выполнении и снять его из диспетчера задач вместе с процесом невозможно + иногда весь GUI начинает так тормозить, что почти невозможно ничего убить, ну или ооочень долго ждать, пока все отрисуется и отреагирует на клавиши/мышь, а потом после убийства дебагера все опять ок. Причем происходило такое как с вижуал студией, так и с олли и на разных машинах. Вобщем много неприятных моментов доставляет, было бы тож интересно понять из-за чего..
x64 wrote: > _>В чём может быть причина того что процесс даже не убить? > > Например, запрос ушёл в ядро, но так и не вернулся и чего-то ждёт в > состоянии non-alertable, а отменялку поставить забыли. Почему и чего там > ждут — отдельный вопрос. Ты чем гадать здесь поди и дамп системы сделай > (manully-initiated crash, если это на реальной машине происходит), там > уже можно будет посмотреть состояния потоков и так далее, всяко яснее > станет.
Значит косяки скорее в драйверах чем в приложении? Дамп сделаю, если
зависнет в следующий раз, только какой делать: ядра или всей памяти?
_>Значит косяки скорее в драйверах чем в приложении?
В контексте данной проблемы косяки всегда бывают только в драйверах, потому что само по себе приложение никак не может сделать так, чтобы его не убили, даже имея админские привилегии.
_>Дамп сделаю, если зависнет в следующий раз, только какой делать: ядра или всей памяти?
Здравствуйте, x64, Вы писали:
_>>Может ли антивирус быть причиной?
x64>Скорее нет, чем да, ну по крайне мере я такого не замечал за ними. Более вероятно, какой-нибудь другой кривой драйвер-фильтр.
На самом деле, может. Лично наблюдал такое поведение после того, как касперовцы однажды выпустили кривое обновление. У Каспера есть драйвер-фильтр для проверки сетевого трафика (почта, веб), и вот в нём приложения, работавшие с сетью (в моём случае это был почтовик), периодически наглухо зависали.
_>x64 wrote: >> _>В чём может быть причина того что процесс даже не убить? >> >> Например, запрос ушёл в ядро, но так и не вернулся и чего-то ждёт в >> состоянии non-alertable, а отменялку поставить забыли. Почему и чего там >> ждут — отдельный вопрос. Ты чем гадать здесь поди и дамп системы сделай >> (manully-initiated crash, если это на реальной машине происходит), там >> уже можно будет посмотреть состояния потоков и так далее, всяко яснее >> станет.
_>Значит косяки скорее в драйверах чем в приложении? Дамп сделаю, если _>зависнет в следующий раз, только какой делать: ядра или всей памяти?
Если Windows приложение, а в данном случае твой процесс, сделал запрос к драйверу и драйвер не возратил запрос
то убить приложения сразу нельзя. Приложение убивается но после ~5 минут даже при незавершенном запросе в драйвере.
Если ситуация повторится то попробуй убить процесс но подожди 5-7 минут. Если через это время процесс исчезнет то значит драйвер
не обеспечил Cancel routine в Irp. Короче, проблема в драйвере.
eagersh wrote:
> Если Windows приложение, а в данном случае твой процесс, сделал запрос к > драйверу и драйвер не возратил запрос то убить приложения сразу нельзя. > Приложение убивается но после ~5 минут даже при незавершенном запросе в > драйвере. Если ситуация повторится то попробуй убить процесс но подожди > 5-7 минут. Если через это время процесс исчезнет то значит драйвер не > обеспечил Cancel routine в Irp. Короче, проблема в драйвере.
Спасибо. Интересно, где нибудь про эти 5 минут официально задокументировано?
Пока переставили винду с нуля и самые свежие дрова установили.
VOID
IoCancelThreadIo(
IN PETHREAD Thread
)
/*++
Routine Description:
This routine cancels all of the I/O operations for the specified thread.
This is accomplished by walking the list of IRPs in the thread IRP list
and canceling each one individually. No other I/O operations can be
started for the thread since this routine has control of the thread itself.
Arguments:
Tcb - Pointer to the Thread Control Block for the thread.
Return Value:
None.
--*/
{
PLIST_ENTRY header;
PLIST_ENTRY entry;
KIRQL irql;
PETHREAD thread;
PIRP irp;
ULONG count;
LARGE_INTEGER interval;
PAGED_CODE();
DBG_UNREFERENCED_PARAMETER( Thread );
thread = PsGetCurrentThread();
header = &thread->IrpList;
if ( IsListEmpty( header )) {
return;
}
//
// Raise the IRQL so that the IrpList cannot be modified by a completion
// APC.
//
KeRaiseIrql( APC_LEVEL, &irql );
entry = header->Flink;
//
// Walk the list of pending IRPs, canceling each of them.
//while (header != entry) {
irp = CONTAINING_RECORD( entry, IRP, ThreadListEntry );
IoCancelIrp( irp );
entry = entry->Flink;
}
//
// Wait for the requests to complete. Note that waiting may eventually
// timeout, in which case more work must be done.
//
count = 0;
interval.QuadPart = -10 * 1000 * 100;
while (!IsListEmpty( header )) {
//
// Lower the IRQL so that the thread APC can fire which will complete
// the requests. Delay execution for a time and let the request
// finish. The delay time is 100ms.
//
KeLowerIrql( irql );
KeDelayExecutionThread( KernelMode, FALSE, &interval );
if (count++ > 3000) {
//
// This I/O request has timed out, as it has not been completed
// for a full 5 minutes. Attempt to remove the packet's association
// with this thread. Note that by not resetting the count, the
// next time through the loop the next packet, if there is one,
// which has also timed out, will be dealt with, although it
// will be given another 100ms to complete.
//
IopDisassociateThreadIrp();
}
KeRaiseIrql( APC_LEVEL, &irql );
}
KeLowerIrql( irql );
}
E>Приложение убивается но после ~5 минут даже при незавершенном запросе в драйвере.
Несмотря на то, что процесс через определённое время таки уничтожается, незавершённые пакеты запросов (IRP) не освобождаются на случай, если драйвер когда-нибудь всё же решит завершить их.
Появилась дополнительная информация. Устройство работает на USB. После
зависания процесса, работающего с устройством, физическое отсоединение
устройства разблокирует процесс. После подключения всё начинает работать
нормально. Варианты:
1) Глючное устройство зависает. Но почему тогда драйвер блокирует запрос?
2) Глючный USB чипсет на материнке.
_>eagersh wrote:
>> Если Windows приложение, а в данном случае твой процесс, сделал запрос к >> драйверу и драйвер не возратил запрос то убить приложения сразу нельзя. >> Приложение убивается но после ~5 минут даже при незавершенном запросе в >> драйвере. Если ситуация повторится то попробуй убить процесс но подожди >> 5-7 минут. Если через это время процесс исчезнет то значит драйвер не >> обеспечил Cancel routine в Irp. Короче, проблема в драйвере.
_>Спасибо. Интересно, где нибудь про эти 5 минут официально задокументировано?
_>Пока переставили винду с нуля и самые свежие дрова установили.
Нет не задокументированно.
