Ошибка при получении имени HANDLE'а

Перехватил через sst NtClose, и хочу посмотреть имена всех закрываемых объектов, но драйвр каждый раз выпадает

Код (Text):

1. POBJECT_NAME_INFORMATION
2. GetHandleName(
3.               IN HANDLE ObjectHandle
4.               )
5. {
6.     NTSTATUS Status;
7.     PVOID Object;
8.     POBJECT_NAME_INFORMATION ObjectName;
9.  
10.     // получаем объект связанный с описателем
11.     if (!NT_SUCCESS(Status = ObReferenceObjectByHandle(ObjectHandle,
12.         GENERIC_READ, NULL, KernelMode, &Object, NULL)))
13.     {
14.         IFDEBUG(DbgPrint("GetHandleName: Status=0x%x\n", Status));
15.         return NULL;
16.     }
17.  
18.     ObjectName = GetObjectName(Object);
19.     ObDereferenceObject(Object);
20.     //DbgPrint("GetHandleName: Name=%S\n",ObjectName->Name.Buffer);
21.     return ObjectName;
22. }

А так я его вывожу на экран

Код (Text):

1. NTSTATUS __stdcall MyNtClose( IN HANDLE  Handle)
2. {
3. POBJECT_NAME_INFORMATION ObjectName = GetHandleName(Handle);
4. DbgPrint("ObjectName %S", (ObjectName->Name).Buffer);
5. return pNtClose(Handle);
6. }

в чем проблема? в нулевых строках или в чем то еще? pNtClose - оригинальный оработчик

 

ну как бы минидамп обычно помогает.

 

А где код GetObjectName? Предположу, что валится именно там. К тому же, далеко не все объекты ядра именованные.
Давай сюда код и !analyze -v.

 

В нежелании научится пользоваться отладчиком. Я тут ничего советовать не буду. Проблема настолько простая, что ты легко разберёшься самостоятельно при помощи отладчика. Удачи.

 

UNICODE_STRING?

 

Юникод строчки как правило не нуль-терминированы, и выводятся через %wZ. Но мало ли, автор у себя обнуляет буфер. А вообще х64 прав.

 

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