IoGetDeviceObjectPointer BSoD

NTDEV
21

“The problem is, you didn’t PROVIDE “the entire code”… you provided a jumble of pseudo-code and a poorly phrased question:”
That’s wrong, everything is in the first post.
As stated by Ntdev geek: “From the beginning it was easy to understand that you were trying to use IoGetDeviceObjectPointer as a (much too long) detour to the undocumented ObOpenObjectByName”

This is just people are too lazy to read everything, and they stop at the first sentence.

“And you failed to clarify this on any of the follow-ups to your post”
By telling to re-read one more time? Come one, we’re not here to teach how to read a short text…

“It is unwise to insult the people who are trying to help you.”
As well as insulting people that asking help. It applies to everyone.

“Have you considered calling ObReferenceObjectByName?”
As said before (!), " I have another method iterating the Driver directory instead and using ObOpenObjectByName, but it’s used only if the previous failed."

Ok, let’s forget those communication issues…
I was concerned about the fact that it’s undocumented, but if you experimented guys tell me that it’s pretty safe to use it across all OS’s, then I think I’ll switch the order of the calls (put that one in 1st position).

However, just out of curiosity, any idea WHY this BSoD is happening?

22

Your TrueSight!GetDriverByDeviceDirectory wastes about 2K of stack space. Then there is sonypvt3.sys on the stack which wastes another almost 4K one one stack location. That’s why you do eventually get stack overflow.

23

On a simple virtual machine, the path leading to the \Driver\ATAPI object is very short.

Opening a handle to the root of the CDROM drive (D:) and walking the file object’s
device stack downward is sufficient.

Here is the output of the function below:

\Driver\atapi found with device 0xFFFFFA8001D6D060

Here is the function code:

NTSTATUS NTAPI TestFileObject(VOID){
NTSTATUS Status;
OBJECT_ATTRIBUTES Object;
UNICODE_STRING Path;
HANDLE File;
PFILE_OBJECT FileObject = NULL;
IO_STATUS_BLOCK IoStatusBlock = {0};
PDEVICE_OBJECT LowerDevice, UpperDevice;

// D: is the CDROM drive
RtlInitUnicodeString(&Path,L"\??\D:\");
InitializeObjectAttributes(&Object,&Path,OBJ_CASE_INSENSITIVE|OBJ_KERNEL_HANDLE,NULL,NULL);

Status = ZwOpenFile(
&File,
GENERIC_READ|SYNCHRONIZE|FILE_LIST_DIRECTORY|FILE_TRAVERSE,
&Object,
&IoStatusBlock,
FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE,
FILE_DIRECTORY_FILE|FILE_SYNCHRONOUS_IO_NONALERT);

if(!NT_SUCCESS(Status)){
DbgPrint(“ZwOpenFile failed with status 0x%08X\n”,Status);
return Status;
}

Status = ObReferenceObjectByHandle(
File,
GENERIC_READ|SYNCHRONIZE|FILE_LIST_DIRECTORY|FILE_TRAVERSE,
*IoFileObjectType,
KernelMode,
(PVOID*)&FileObject,
NULL);

// Not needed now
ZwClose(File);

if(!NT_SUCCESS(Status)){
DbgPrint(“ObReferenceObjectByHandle failed with status 0x%08X\n”,Status);
return Status;
}

// Walk the device stack downward
if(FileObject->DeviceObject){
ObReferenceObject(FileObject->DeviceObject);
UpperDevice = FileObject->DeviceObject;
LowerDevice = IoGetLowerDeviceObject(UpperDevice);
DbgPrint(“=================================================================\n”);
while(LowerDevice){
UpperDevice = LowerDevice;
DbgPrint(“%wZ found with device 0x%p\n”,&LowerDevice->DriverObject->DriverName,LowerDevice);
LowerDevice = IoGetLowerDeviceObject(UpperDevice);
ObDereferenceObject(UpperDevice);
}
DbgPrint(“=================================================================\n”);
ObDereferenceObject(FileObject->DeviceObject);
}

ObDereferenceObject(FileObject);
return Status;
}

24

Alex: “Your TrueSight!GetDriverByDeviceDirectory wastes about 2K of stack space. Then there is sonypvt3.sys on the stack which wastes another almost 4K one one stack location. That’s why you do eventually get stack overflow.”

May I ask you how you found this? Especially the size of the stack used for each driver.

Ntdev Geek: Thanks for the code, however it looks very specific to a given system. What happen if one box doesn’t have any CD drive? I think I’ll go with ObReferenceObjectByName in first position as it looks like that function is quite stable across all OSs

25

The left column in the stack dump is ESP.

26

Thank you Alex, that helps a lot!
http://blogs.msdn.com/b/ntdebugging/archive/2008/02/01/kernel-stack-overflows.aspx