Всем доброго времени суток!

Совершенно случайно столкнулся с интересной проблемой. Есть такая программка- Unlocker. После того, как она получает хендл своего устройства \\??\\Unlocker5, при попытке вызвать ObQueryNameString на полученном объекте приводят к зависанию в кернеле. Нет ли у уважаемого сообщества идей по поводу того, что могло вызвать подобное?

ObReferenceObjectByHandle(hFile,SYNCHRONIZE,*IoFileObjectType,KernelMode,&pObject,NULL);

ObQueryNameString(pObject,Buffer,BufferLength,BytesReturned);

if(pObject)
  ObDereferenceObject(pObject);

Здравствуйте, Аноним, Вы писали:

А>Всем доброго времени суток!

А>на полученном объекте приводят к зависанию в кернеле.
Потрудитесь набрать в поиске РСДН "ObQueryNameString зависает"

Здравствуйте, serg_fork, Вы писали:

_>Потрудитесь набрать в поиске РСДН "ObQueryNameString зависает"

Потрудился. Предположений много, толку мало. Положим, что pipes даже ребёнок знает, а вот что вызывает такие выкрутасы на хендлах устройств, похоже, не знает никто.

Здравствуйте, Аноним, Вы писали:

А>Потрудился. Предположений много, толку мало. Положим, что pipes даже ребёнок знает, а вот что вызывает такие выкрутасы на хендлах устройств, похоже, не знает никто.

Например, доставка APC отключена в момент выхова.

Здравствуйте, Sergey Storozhevykh, Вы писали:

SS>Например, доставка APC отключена в момент выхова.

Интересно. А как это детектировать по PFILE_OBJECT устройства?

Здравствуйте, Аноним, Вы писали:

SS>>Например, доставка APC отключена в момент выхова.

А>Интересно. А как это детектировать по PFILE_OBJECT устройства?

По PFILE_OBJECT — никак, будет ли доставлятся APC потоку или нет зависит от свойств потока и текущего IRQL. В данном случае, зависание может произойти по причине того, что потоку не может быть доставлен special kernel APC, сигнализирующий о завершении операции ввода/вывода (IopCompleteRequest).