ObQueryNameString crash

NTDEV
1

All,

I’m trying to use ObQueryNameString to simply print out the device name for the driver object above me. I will see all the trace statements then the crash. Sometimes I only get through one of the trace statements.

I’m mostly ignoring the status’ since this is debug only right now. I can see that the strings are equal so I know the name is being returned.

One thing I had tried was to allocate the buffer for the Unicode string in OBJECT_NAME_INFO, this has no effect and the documentation for this function states the buffer will contain the pointer to the string which tells me I don’t need to allocate the buffer since there is no copy involved.

Code:
EXTERN_C NTSTATUS NTAPI
ObQueryNameString(
PVOID Object,
POBJECT_NAME_INFORMATION ObjectNameInfo,
ULONG Length,
PULONG ReturnLength);

static NTSTATUS
DeviceAttachToStack(
IN PDEVICE_OBJECT pDevObj
)
{
PAGED_CODE();

NTSTATUS status = STATUS_UNSUCCESSFUL;
ULONG ReturnLength;
ULONG Length;
OBJECT_NAME_INFORMATION objName = {0};
PWCHAR ptemp = L"\Device\Harddisk0\DR0";

ObQueryNameString((PVOID)pDevObj, NULL, NULL, &ReturnLength);
Length = ReturnLength;

status = ObQueryNameString((PVOID)pDevObj,
&objName,
Length,
&ReturnLength);

BOOLEAN equal = MyUtilIsStringEqual(objName.Name.Buffer, ptemp);

MyTrace(TRACE_LEVEL_WARNING, DRV_DBG_DEVICE_SUPPORT,
“%s: Strings %wZ and %ws are equal: %d\n”, FUNCTION,
&objName.Name, ptemp, equal);

MyTrace(TRACE_LEVEL_INFORMATION, DRV_DBG_DEVICE_SUPPORT,
“%s: Attached Device Name %wZ for device %p w/status 0x%x.\n”,
FUNCTION, &objName.Name, pDevObj, status);

return status;

In this case, I only see the first trace statement:

DeviceAttachToStack: Strings \Device\Harddisk0\DR0 and \Device\Harddisk0\DR0 are equal: 1

Then a bugcheck …

Unknown bugcheck code (0)
Unknown bugcheck description
Arguments:
Arg1: 0000000000000000
Arg2: 0000000000000000
Arg3: 0000000000000000
Arg4: 0000000000000000

Debugging Details:

PROCESS_NAME: System

FAULTING_IP:
mydriver!DeviceAttachToStack+13a [mydriver.cpp @ 155]
fffff880`01badada 488b4018 mov rax,qword ptr [rax+18h]

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_PARAMETER1: 0000000000000000

EXCEPTION_PARAMETER2: ffffffffffffffff

READ_ADDRESS: ffffffffffffffff

FOLLOWUP_IP:
fffff880`01badada 488b4018 mov rax,qword ptr [rax+18h]

BUGCHECK_STR: ACCESS_VIOLATION

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 005c006500630069 to fffff88001badada

STACK_TEXT:
fffff880021f49e0 005c006500630069 : 0064007200610048 006b007300690064 00520044005c0030 fffff88000000030 : MyDriver!DeviceAttachToStack+0x13a [mydriver.cpp @ 155]
fffff880021f4a60 0064007200610048 : 006b007300690064 00520044005c0030 fffff88000000030 0000000000000000 : 0x005c006500630069 fffff880021f4a68 006b007300690064 : 00520044005c0030 fffff88000000030 0000000000000000 fffffa8303805d10 : 0x0064007200610048
fffff880021f4a70 00520044005c0030 : fffff88000000030 0000000000000000 fffffa8303805d10 fffffa8303800e00 : 0x006b007300690064 fffff880021f4a78 fffff88000000030 : 0000000000000000 fffffa8303805d10 fffffa8303800e00 fffffa83037f28a0 : 0x00520044005c0030
fffff880021f4a80 0000000000000000 : fffffa8303805d10 fffffa8303800e00 fffffa83037f28a0 fffffa83037f2800 : 0xfffff880`00000030

2

Your OBJECT_NAME_INFORMATION variable must contain storage for the
UNICODE_STRING plus the buffer in one contigious block. Do not declare a
OBJECT_NAME_INFORMATION on the stack but declare a pointer and allocate a
chunk of memory from the pool to hold the string.

Like:
POBJECT_NAME_INFORMATION pObjName = ExAllocatePool…

//Daniel

3

Without walking through the code, the doc on it appears to suggest that the buffer needs to be large enough to contain the UNICODE_STRING and the buffer appended, so you should be allocating a new buffer of ReturnLength before calling it again. That would explain your stack corruption.

Phil
Not speaking for LogRhythm

Phil Barila | Senior Software Engineer
720.881.5364 (w)
LogRhythm, Inc.
A LEADER 2012 SIEM Magic Quadrant
WINNER of SC Magazine’s 2012 SIEM Best Buy

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Speer, Kenny
Sent: Thursday, January 24, 2013 4:19 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] ObQueryNameString crash

All,

I’m trying to use ObQueryNameString to simply print out the device name for the driver object above me. I will see all the trace statements then the crash. Sometimes I only get through one of the trace statements.

I’m mostly ignoring the status’ since this is debug only right now. I can see that the strings are equal so I know the name is being returned.

One thing I had tried was to allocate the buffer for the Unicode string in OBJECT_NAME_INFO, this has no effect and the documentation for this function states the buffer will contain the pointer to the string which tells me I don’t need to allocate the buffer since there is no copy involved.

Code:
EXTERN_C NTSTATUS NTAPI
ObQueryNameString(
PVOID Object,
POBJECT_NAME_INFORMATION ObjectNameInfo,
ULONG Length,
PULONG ReturnLength);

static NTSTATUS
DeviceAttachToStack(
IN PDEVICE_OBJECT pDevObj
)
{
PAGED_CODE();

NTSTATUS status = STATUS_UNSUCCESSFUL;
ULONG ReturnLength;
ULONG Length;
OBJECT_NAME_INFORMATION objName = {0};
PWCHAR ptemp = L"\Device\Harddisk0\DR0";

ObQueryNameString((PVOID)pDevObj, NULL, NULL, &ReturnLength);
Length = ReturnLength;

status = ObQueryNameString((PVOID)pDevObj,
&objName,
Length,
&ReturnLength);

BOOLEAN equal = MyUtilIsStringEqual(objName.Name.Buffer, ptemp);

MyTrace(TRACE_LEVEL_WARNING, DRV_DBG_DEVICE_SUPPORT,
“%s: Strings %wZ and %ws are equal: %d\n”, FUNCTION,
&objName.Name, ptemp, equal);

MyTrace(TRACE_LEVEL_INFORMATION, DRV_DBG_DEVICE_SUPPORT,
“%s: Attached Device Name %wZ for device %p w/status 0x%x.\n”,
FUNCTION, &objName.Name, pDevObj, status);

return status;

In this case, I only see the first trace statement:

DeviceAttachToStack: Strings \Device\Harddisk0\DR0 and \Device\Harddisk0\DR0 are equal: 1

Then a bugcheck …

Unknown bugcheck code (0)
Unknown bugcheck description
Arguments:
Arg1: 0000000000000000
Arg2: 0000000000000000
Arg3: 0000000000000000
Arg4: 0000000000000000

Debugging Details:

PROCESS_NAME: System

FAULTING_IP:
mydriver!DeviceAttachToStack+13a [mydriver.cpp @ 155]
fffff880`01badada 488b4018 mov rax,qword ptr [rax+18h]

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_PARAMETER1: 0000000000000000

EXCEPTION_PARAMETER2: ffffffffffffffff

READ_ADDRESS: ffffffffffffffff

FOLLOWUP_IP:
fffff880`01badada 488b4018 mov rax,qword ptr [rax+18h]

BUGCHECK_STR: ACCESS_VIOLATION

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 005c006500630069 to fffff88001badada

STACK_TEXT:
fffff880021f49e0 005c006500630069 : 0064007200610048 006b007300690064 00520044005c0030 fffff88000000030 : MyDriver!DeviceAttachToStack+0x13a [mydriver.cpp @ 155]
fffff880021f4a60 0064007200610048 : 006b007300690064 00520044005c0030 fffff88000000030 0000000000000000 : 0x005c006500630069 fffff880021f4a68 006b007300690064 : 00520044005c0030 fffff88000000030 0000000000000000 fffffa8303805d10 : 0x0064007200610048
fffff880021f4a70 00520044005c0030 : fffff88000000030 0000000000000000 fffffa8303805d10 fffffa8303800e00 : 0x006b007300690064 fffff880021f4a78 fffff88000000030 : 0000000000000000 fffffa8303805d10 fffffa8303800e00 fffffa83037f28a0 : 0x00520044005c0030
fffff880021f4a80 0000000000000000 : fffffa8303805d10 fffffa8303800e00 fffffa83037f28a0 fffffa83037f2800 : 0xfffff880`00000030

NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

4

Thanks, I’ve tried that also and got the same results.

I’ve also added an allocation after the first call to acquire the length, also same result.

But I’ll try it again to be safe.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@resplendence.com
Sent: Thursday, January 24, 2013 3:31 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] ObQueryNameString crash

Your OBJECT_NAME_INFORMATION variable must contain storage for the UNICODE_STRING plus the buffer in one contigious block. Do not declare a OBJECT_NAME_INFORMATION on the stack but declare a pointer and allocate a chunk of memory from the pool to hold the string.

Like:
POBJECT_NAME_INFORMATION pObjName = ExAllocatePool…

//Daniel

NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

5

I have never used this api, I have not done FS work either>

The way I read the API and the way OBJECT_NAME_INFORMATION is used, you are telling the API that your POBJECT_NAME_INFORMATION pointer is bigger than it truly is. It looks like the api expects the buffer for the UNICODE_STRING to reside immediately after the OBJECT_NAME_INFORMATION, ie conceptually like this

typedef struct _OBJECT_NAME_INFORMATION {
UNICODE_STRING Name;
WCHAR BufferForName[0];
} OBJECT_NAME_INFORMATION, *POBJECT_NAME_INFORMATION;

So your initial call to the API gives a ReturnLength which you then just pass to the API again without validating if ReturnLength > sizeof(OBJECT_NAME_INFORMATION), which I am guessing it is. So the API thinks it has ReturnLength number of bytes to part on, while in reality it only has sizeof(OBJECT_NAME_INFORMATION) and since you passed a pointer to a stack variable, you have a classic case of stack corruption.

Instead of declaring your OBJECT_NAME_INFORMATION on the stack, allocate it with the specified ReturnLength from the first call

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Speer, Kenny
Sent: Thursday, January 24, 2013 3:19 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] ObQueryNameString crash

All,

I’m trying to use ObQueryNameString to simply print out the device name for the driver object above me. I will see all the trace statements then the crash. Sometimes I only get through one of the trace statements.

I’m mostly ignoring the status’ since this is debug only right now. I can see that the strings are equal so I know the name is being returned.

One thing I had tried was to allocate the buffer for the Unicode string in OBJECT_NAME_INFO, this has no effect and the documentation for this function states the buffer will contain the pointer to the string which tells me I don’t need to allocate the buffer since there is no copy involved.

Code:
EXTERN_C NTSTATUS NTAPI
ObQueryNameString(
PVOID Object,
POBJECT_NAME_INFORMATION ObjectNameInfo,
ULONG Length,
PULONG ReturnLength);

static NTSTATUS
DeviceAttachToStack(
IN PDEVICE_OBJECT pDevObj
)
{
PAGED_CODE();

NTSTATUS status = STATUS_UNSUCCESSFUL;
ULONG ReturnLength;
ULONG Length;
OBJECT_NAME_INFORMATION objName = {0};
PWCHAR ptemp = L"\Device\Harddisk0\DR0";

ObQueryNameString((PVOID)pDevObj, NULL, NULL, &ReturnLength);
Length = ReturnLength;

status = ObQueryNameString((PVOID)pDevObj,
&objName,
Length,
&ReturnLength);

BOOLEAN equal = MyUtilIsStringEqual(objName.Name.Buffer, ptemp);

MyTrace(TRACE_LEVEL_WARNING, DRV_DBG_DEVICE_SUPPORT,
“%s: Strings %wZ and %ws are equal: %d\n”, FUNCTION ,
&objName.Name, ptemp, equal);

MyTrace(TRACE_LEVEL_INFORMATION, DRV_DBG_DEVICE_SUPPORT,
“%s: Attached Device Name %wZ for device %p w/status 0x%x.\n”,
FUNCTION , &objName.Name, pDevObj, status);

return status;

In this case, I only see the first trace statement:

DeviceAttachToStack: Strings \Device\Harddisk0\DR0 and \Device\Harddisk0\DR0 are equal: 1

Then a bugcheck …

Unknown bugcheck code (0)
Unknown bugcheck description
Arguments:
Arg1: 0000000000000000
Arg2: 0000000000000000
Arg3: 0000000000000000
Arg4: 0000000000000000

Debugging Details:
------------------

PROCESS_NAME: System

FAULTING_IP:
mydriver!DeviceAttachToStack+13a [mydriver.cpp @ 155]
fffff88001badada 488b4018 mov rax,qword ptr [rax+18h]<br><br>ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.<br><br>EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.<br><br>EXCEPTION_PARAMETER1: 0000000000000000<br><br>EXCEPTION_PARAMETER2: ffffffffffffffff<br><br>READ_ADDRESS: ffffffffffffffff <br><br>FOLLOWUP_IP: <br>fffff88001badada 488b4018 mov rax,qword ptr [rax+18h]

BUGCHECK_STR: ACCESS_VIOLATION

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 005c006500630069 to fffff88001badada

STACK_TEXT:
fffff880021f49e0 005c006500630069 : 0064007200610048 006b007300690064 00520044005c0030 fffff88000000030 : MyDriver!DeviceAttachToStack+0x13a [mydriver.cpp @ 155]
fffff880021f4a60 0064007200610048 : 006b007300690064 00520044005c0030 fffff88000000030 0000000000000000 : 0x005c006500630069<br>fffff880021f4a68 006b007300690064 : 00520044005c0030 fffff88000000030 0000000000000000 fffffa8303805d10 : 0x0064007200610048
fffff880021f4a70 00520044005c0030 : fffff88000000030 0000000000000000 fffffa8303805d10 fffffa8303800e00 : 0x006b007300690064<br>fffff880021f4a78 fffff88000000030 : 0000000000000000 fffffa8303805d10 fffffa8303800e00 fffffa83037f28a0 : 0x00520044005c0030
fffff880021f4a80 0000000000000000 : fffffa8303805d10 fffffa8303800e00 fffffa83037f28a0 fffffa83037f2800 : 0xfffff880`00000030

—
NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

6

> One thing I had tried was to allocate the buffer for the Unicode string in OBJECT_NAME_INFO, this has no effect and the documentation for this function states the buffer will contain the pointer to the string which tells me I don’t need to allocate the buffer since there is no copy involved.

You should allocate the buffer for ObjectNameInfo, not for UNICODE string inside. Buffer size should be the ReturnLength returned by the first call. You pass it to the second call as Length parameter and your ObjectNameInfo has just UNICODE_STRING size and is allocated on the stack. No wonder it crashes, it probably rewrites the stack.

I don’t remember it exactly but I guess ObQueryNameString copies the string just behind the OBJECT_NAME_INFO and sets pointer of UNICODE buffer string there. I found a following piece of code in my old driver:

struct {
OBJECT_NAME_INFORMATION NameInfo;
WCHAR Buffer[64]; // 64 chars must be enough for everybody :slight_smile:
} InfoBuffer;

if (NT_SUCCESS(Status = ObQueryNameString(DeviceObject, &InfoBuffer.NameInfo, sizeof(InfoBuffer), &ReturnedLength))) {
…

Well, you should use the dynamic memory, instead. I knew that the device name will be short enough and also that I have enough stack when this code was called.

Michal

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-524615-
xxxxx@lists.osr.com] On Behalf Of Speer, Kenny
Sent: Friday, January 25, 2013 12:19 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] ObQueryNameString crash

All,

I’m trying to use ObQueryNameString to simply print out the device name for
the driver object above me. I will see all the trace statements then the crash.
Sometimes I only get through one of the trace statements.

I’m mostly ignoring the status’ since this is debug only right now. I can see that
the strings are equal so I know the name is being returned.

One thing I had tried was to allocate the buffer for the Unicode string in
OBJECT_NAME_INFO, this has no effect and the documentation for this
function states the buffer will contain the pointer to the string which tells me I
don’t need to allocate the buffer since there is no copy involved.

Code:
EXTERN_C NTSTATUS NTAPI
ObQueryNameString(
PVOID Object,
POBJECT_NAME_INFORMATION ObjectNameInfo,
ULONG Length,
PULONG ReturnLength);

static NTSTATUS
DeviceAttachToStack(
IN PDEVICE_OBJECT pDevObj
)
{
PAGED_CODE();

NTSTATUS status = STATUS_UNSUCCESSFUL;
ULONG ReturnLength;
ULONG Length;
OBJECT_NAME_INFORMATION objName = {0};
PWCHAR ptemp = L"\Device\Harddisk0\DR0";

ObQueryNameString((PVOID)pDevObj, NULL, NULL, &ReturnLength);
Length = ReturnLength;

status = ObQueryNameString((PVOID)pDevObj,
&objName,
Length,
&ReturnLength);

BOOLEAN equal = MyUtilIsStringEqual(objName.Name.Buffer, ptemp);

MyTrace(TRACE_LEVEL_WARNING, DRV_DBG_DEVICE_SUPPORT,
“%s: Strings %wZ and %ws are equal: %d\n”, FUNCTION,
&objName.Name, ptemp, equal);

MyTrace(TRACE_LEVEL_INFORMATION, DRV_DBG_DEVICE_SUPPORT,
“%s: Attached Device Name %wZ for device %p w/status
0x%x.\n”,
FUNCTION, &objName.Name, pDevObj, status);

return status;

In this case, I only see the first trace statement:

DeviceAttachToStack: Strings \Device\Harddisk0\DR0 and
\Device\Harddisk0\DR0 are equal: 1

Then a bugcheck …

Unknown bugcheck code (0)
Unknown bugcheck description
Arguments:
Arg1: 0000000000000000
Arg2: 0000000000000000
Arg3: 0000000000000000
Arg4: 0000000000000000

Debugging Details:

PROCESS_NAME: System

FAULTING_IP:
mydriver!DeviceAttachToStack+13a [mydriver.cpp @ 155]
fffff880`01badada 488b4018 mov rax,qword ptr [rax+18h]

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced
memory at 0x%08lx. The memory could not be %s.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx
referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_PARAMETER1: 0000000000000000

EXCEPTION_PARAMETER2: ffffffffffffffff

READ_ADDRESS: ffffffffffffffff

FOLLOWUP_IP:
fffff880`01badada 488b4018 mov rax,qword ptr [rax+18h]

BUGCHECK_STR: ACCESS_VIOLATION

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 005c006500630069 to fffff88001badada

STACK_TEXT:
fffff880021f49e0 005c006500630069 : 0064007200610048 006b007300690064 00520044005c0030 fffff88000000030 :
MyDriver!DeviceAttachToStack+0x13a [mydriver.cpp @ 155]
fffff880021f4a60 0064007200610048 : 006b007300690064 00520044005c0030 fffff88000000030 0000000000000000 :
0x005c006500630069 fffff880021f4a68 006b007300690064 : 00520044005c0030 fffff88000000030 0000000000000000 fffffa8303805d10 : 0x0064007200610048
fffff880021f4a70 00520044005c0030 : fffff88000000030 0000000000000000
fffffa8303805d10 fffffa8303800e00 : 0x006b007300690064 fffff880021f4a78 fffff88000000030 : 0000000000000000 fffffa8303805d10 fffffa8303800e00 fffffa83037f28a0 : 0x00520044005c0030
fffff880021f4a80 0000000000000000 : fffffa8303805d10 fffffa8303800e00
fffffa83037f28a0 fffffa83037f2800 : 0xfffff880`00000030

NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

NOTE: The information in this message is intended for the personal and confidential use of the designated recipient(s) named above. To the extent the recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an obligation of confidentiality, with AuthenTec, then this message and/or any attachments shall be considered confidential information and subject to the confidentiality terms of that agreement. If the reader of this message is not the intended recipient named above, you are notified that you have received this document in error, and any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this document in error, please delete the original message and notify the sender immediately.
Thank You!
AuthenTec, Inc. http://www.authentec.com/

7

/sigh


Thanks Dan, Phil, Doron, and Michal … stupid mistake … I allocated sizeof(OBJECT_NAME_INFORMATION) + Length and voila … no more corruption …

Problem resolved … off to finish this now … thanks again.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Vodicka, Michal
Sent: Thursday, January 24, 2013 3:39 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] ObQueryNameString crash

> One thing I had tried was to allocate the buffer for the Unicode string in OBJECT_NAME_INFO, this has no effect and the documentation for this function states the buffer will contain the pointer to the string which tells me I don’t need to allocate the buffer since there is no copy involved.

You should allocate the buffer for ObjectNameInfo, not for UNICODE string inside. Buffer size should be the ReturnLength returned by the first call. You pass it to the second call as Length parameter and your ObjectNameInfo has just UNICODE_STRING size and is allocated on the stack. No wonder it crashes, it probably rewrites the stack.

I don’t remember it exactly but I guess ObQueryNameString copies the string just behind the OBJECT_NAME_INFO and sets pointer of UNICODE buffer string there. I found a following piece of code in my old driver:

struct {
OBJECT_NAME_INFORMATION NameInfo;
WCHAR Buffer[64]; // 64 chars must be enough for everybody :slight_smile:
} InfoBuffer;

if (NT_SUCCESS(Status = ObQueryNameString(DeviceObject, &InfoBuffer.NameInfo, sizeof(InfoBuffer), &ReturnedLength))) { …

Well, you should use the dynamic memory, instead. I knew that the device name will be short enough and also that I have enough stack when this code was called.

Michal

> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:bounce-524615-
> xxxxx@lists.osr.com] On Behalf Of Speer, Kenny
> Sent: Friday, January 25, 2013 12:19 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] ObQueryNameString crash
>
> All,
>
> I’m trying to use ObQueryNameString to simply print out the device
> name for the driver object above me. I will see all the trace statements then the crash.
> Sometimes I only get through one of the trace statements.
>
> I’m mostly ignoring the status’ since this is debug only right now. I
> can see that the strings are equal so I know the name is being returned.
>
> One thing I had tried was to allocate the buffer for the Unicode
> string in OBJECT_NAME_INFO, this has no effect and the documentation
> for this function states the buffer will contain the pointer to the
> string which tells me I don’t need to allocate the buffer since there is no copy involved.
>
> Code:
> EXTERN_C NTSTATUS NTAPI
> ObQueryNameString(
> PVOID Object,
> POBJECT_NAME_INFORMATION ObjectNameInfo,
> ULONG Length,
> PULONG ReturnLength);
>
> static NTSTATUS
> DeviceAttachToStack(
> IN PDEVICE_OBJECT pDevObj
> )
> {
> PAGED_CODE();
>
> NTSTATUS status = STATUS_UNSUCCESSFUL;
> ULONG ReturnLength;
> ULONG Length;
> OBJECT_NAME_INFORMATION objName = {0};
> PWCHAR ptemp = L"\Device\Harddisk0\DR0";
>
> ObQueryNameString((PVOID)pDevObj, NULL, NULL, &ReturnLength);
> Length = ReturnLength;
>
> status = ObQueryNameString((PVOID)pDevObj,
> &objName,
> Length,
> &ReturnLength);
>
> BOOLEAN equal = MyUtilIsStringEqual(objName.Name.Buffer, ptemp);
>
> MyTrace(TRACE_LEVEL_WARNING, DRV_DBG_DEVICE_SUPPORT,
> “%s: Strings %wZ and %ws are equal: %d\n”, FUNCTION ,
> &objName.Name, ptemp, equal);
>
> MyTrace(TRACE_LEVEL_INFORMATION, DRV_DBG_DEVICE_SUPPORT,
> “%s: Attached Device Name %wZ for device %p w/status 0x%x.\n”,
> FUNCTION , &objName.Name, pDevObj, status);
>
> return status;
>
> In this case, I only see the first trace statement:
>
> DeviceAttachToStack: Strings \Device\Harddisk0\DR0 and
> \Device\Harddisk0\DR0 are equal: 1
>
> Then a bugcheck …
>
> Unknown bugcheck code (0)
> Unknown bugcheck description
> Arguments:
> Arg1: 0000000000000000
> Arg2: 0000000000000000
> Arg3: 0000000000000000
> Arg4: 0000000000000000
>
> Debugging Details:
> ------------------
>
>
> PROCESS_NAME: System
>
> FAULTING_IP:
> mydriver!DeviceAttachToStack+13a [mydriver.cpp @ 155]
> fffff88001badada 488b4018 mov rax,qword ptr [rax+18h]<br>&gt; <br>&gt; ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx <br>&gt; referenced memory at 0x%08lx. The memory could not be %s.<br>&gt; <br>&gt; EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx <br>&gt; referenced memory at 0x%08lx. The memory could not be %s.<br>&gt; <br>&gt; EXCEPTION_PARAMETER1: 0000000000000000<br>&gt; <br>&gt; EXCEPTION_PARAMETER2: ffffffffffffffff<br>&gt; <br>&gt; READ_ADDRESS: ffffffffffffffff<br>&gt; <br>&gt; FOLLOWUP_IP:<br>&gt; fffff88001badada 488b4018 mov rax,qword ptr [rax+18h]
>
> BUGCHECK_STR: ACCESS_VIOLATION
>
> DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT
>
> CURRENT_IRQL: 0
>
> LAST_CONTROL_TRANSFER: from 005c006500630069 to fffff88001badada
>
> STACK_TEXT:
> fffff880021f49e0 005c006500630069 : 0064007200610048<br>&gt; 006b007300690064 00520044005c0030 fffff88000000030 :
> MyDriver!DeviceAttachToStack+0x13a [mydriver.cpp @ 155]
> fffff880021f4a60 0064007200610048 : 006b007300690064<br>&gt; 00520044005c0030 fffff88000000030 0000000000000000 :
> 0x005c006500630069<br>&gt; fffff880021f4a68 006b007300690064 : 00520044005c0030
> fffff88000000030<br>&gt; 0000000000000000 fffffa8303805d10 : 0x0064007200610048
> fffff880021f4a70 00520044005c0030 : fffff88000000030 <br>&gt; 0000000000000000
> fffffa8303805d10 fffffa8303800e00 : 0x006b007300690064<br>&gt; fffff880021f4a78 fffff88000000030 : 0000000000000000
> fffffa8303805d10<br>&gt; fffffa8303800e00 fffffa83037f28a0 : 0x00520044005c0030
> fffff880021f4a80 0000000000000000 : fffffa8303805d10 <br>&gt; fffffa8303800e00
> fffffa83037f28a0 fffffa83037f2800 : 0xfffff880`00000030
>
>
> —
> NTDEV is sponsored by OSR
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

NOTE: The information in this message is intended for the personal and confidential use of the designated recipient(s) named above. To the extent the recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an obligation of confidentiality, with AuthenTec, then this message and/or any attachments shall be considered confidential information and subject to the confidentiality terms of that agreement. If the reader of this message is not the intended recipient named above, you are notified that you have received this document in error, and any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this document in error, please delete the original message and notify the sender immediately.
Thank You!
AuthenTec, Inc. http://www.authentec.com/

—
NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

8

Glad to help :slight_smile:

Actually, this is something where sources access would help. Docs is correct but doesn’t say everything. Quick look to sources would confirm it really used the memory just behind ObjectNameInfo. Which is a bit unusual for people who aren’t used to this pattern and don’t read between lines in the docs.

Michal

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-524622-
xxxxx@lists.osr.com] On Behalf Of Speer, Kenny
Sent: Friday, January 25, 2013 12:41 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] ObQueryNameString crash

/sigh

>
> Thanks Dan, Phil, Doron, and Michal … stupid mistake … I allocated
> sizeof(OBJECT_NAME_INFORMATION) + Length and voila … no more
> corruption …
>
> Problem resolved … off to finish this now … thanks again.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:bounce-524621-
> xxxxx@lists.osr.com] On Behalf Of Vodicka, Michal
> Sent: Thursday, January 24, 2013 3:39 PM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] ObQueryNameString crash
>
> > One thing I had tried was to allocate the buffer for the Unicode string in
> OBJECT_NAME_INFO, this has no effect and the documentation for this
> function states the buffer will contain the pointer to the string which tells me I
> don’t need to allocate the buffer since there is no copy involved.
>
> You should allocate the buffer for ObjectNameInfo, not for UNICODE string
> inside. Buffer size should be the ReturnLength returned by the first call. You
> pass it to the second call as Length parameter and your ObjectNameInfo has
> just UNICODE_STRING size and is allocated on the stack. No wonder it crashes,
> it probably rewrites the stack.
>
> I don’t remember it exactly but I guess ObQueryNameString copies the string
> just behind the OBJECT_NAME_INFO and sets pointer of UNICODE buffer string
> there. I found a following piece of code in my old driver:
>
> struct {
> OBJECT_NAME_INFORMATION NameInfo;
> WCHAR Buffer[64]; // 64 chars must be enough for everybody :slight_smile:
> } InfoBuffer;
>
> if (NT_SUCCESS(Status = ObQueryNameString(DeviceObject,
> &InfoBuffer.NameInfo, sizeof(InfoBuffer), &ReturnedLength))) { …
>
> Well, you should use the dynamic memory, instead. I knew that the device
> name will be short enough and also that I have enough stack when this code
> was called.
>
> Michal
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com [mailto:bounce-524615-
> > xxxxx@lists.osr.com] On Behalf Of Speer, Kenny
> > Sent: Friday, January 25, 2013 12:19 AM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] ObQueryNameString crash
> >
> > All,
> >
> > I’m trying to use ObQueryNameString to simply print out the device
> > name for the driver object above me. I will see all the trace statements then
> the crash.
> > Sometimes I only get through one of the trace statements.
> >
> > I’m mostly ignoring the status’ since this is debug only right now. I
> > can see that the strings are equal so I know the name is being returned.
> >
> > One thing I had tried was to allocate the buffer for the Unicode
> > string in OBJECT_NAME_INFO, this has no effect and the documentation
> > for this function states the buffer will contain the pointer to the
> > string which tells me I don’t need to allocate the buffer since there is no copy
> involved.
> >
> > Code:
> > EXTERN_C NTSTATUS NTAPI
> > ObQueryNameString(
> > PVOID Object,
> > POBJECT_NAME_INFORMATION ObjectNameInfo,
> > ULONG Length,
> > PULONG ReturnLength);
> >
> > static NTSTATUS
> > DeviceAttachToStack(
> > IN PDEVICE_OBJECT pDevObj
> > )
> > {
> > PAGED_CODE();
> >
> > NTSTATUS status = STATUS_UNSUCCESSFUL;
> > ULONG ReturnLength;
> > ULONG Length;
> > OBJECT_NAME_INFORMATION objName = {0};
> > PWCHAR ptemp = L"\Device\Harddisk0\DR0";
> >
> > ObQueryNameString((PVOID)pDevObj, NULL, NULL, &ReturnLength);
> > Length = ReturnLength;
> >
> > status = ObQueryNameString((PVOID)pDevObj,
> > &objName,
> > Length,
> > &ReturnLength);
> >
> > BOOLEAN equal = MyUtilIsStringEqual(objName.Name.Buffer, ptemp);
> >
> > MyTrace(TRACE_LEVEL_WARNING, DRV_DBG_DEVICE_SUPPORT,
> > “%s: Strings %wZ and %ws are equal: %d\n”, FUNCTION ,
> > &objName.Name, ptemp, equal);
> >
> > MyTrace(TRACE_LEVEL_INFORMATION, DRV_DBG_DEVICE_SUPPORT,
> > “%s: Attached Device Name %wZ for device %p w/status
> 0x%x.\n”,
> > FUNCTION , &objName.Name, pDevObj, status);
> >
> > return status;
> >
> > In this case, I only see the first trace statement:
> >
> > DeviceAttachToStack: Strings \Device\Harddisk0\DR0 and
> > \Device\Harddisk0\DR0 are equal: 1
> >
> > Then a bugcheck …
> >
> > Unknown bugcheck code (0)
> > Unknown bugcheck description
> > Arguments:
> > Arg1: 0000000000000000
> > Arg2: 0000000000000000
> > Arg3: 0000000000000000
> > Arg4: 0000000000000000
> >
> > Debugging Details:
> > ------------------
> >
> >
> > PROCESS_NAME: System
> >
> > FAULTING_IP:
> > mydriver!DeviceAttachToStack+13a [mydriver.cpp @ 155]
> > fffff88001badada 488b4018 mov rax,qword ptr [rax+18h]<br>&gt; &gt;<br>&gt; &gt; ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx<br>&gt; &gt; referenced memory at 0x%08lx. The memory could not be %s.<br>&gt; &gt;<br>&gt; &gt; EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx<br>&gt; &gt; referenced memory at 0x%08lx. The memory could not be %s.<br>&gt; &gt;<br>&gt; &gt; EXCEPTION_PARAMETER1: 0000000000000000<br>&gt; &gt;<br>&gt; &gt; EXCEPTION_PARAMETER2: ffffffffffffffff<br>&gt; &gt;<br>&gt; &gt; READ_ADDRESS: ffffffffffffffff<br>&gt; &gt;<br>&gt; &gt; FOLLOWUP_IP:<br>&gt; &gt; fffff88001badada 488b4018 mov rax,qword ptr [rax+18h]
> >
> > BUGCHECK_STR: ACCESS_VIOLATION
> >
> > DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT
> >
> > CURRENT_IRQL: 0
> >
> > LAST_CONTROL_TRANSFER: from 005c006500630069 to fffff88001badada
> >
> > STACK_TEXT:
> > fffff880021f49e0 005c006500630069 : 0064007200610048<br>&gt; &gt; 006b007300690064 00520044005c0030 fffff88000000030 :
> > MyDriver!DeviceAttachToStack+0x13a [mydriver.cpp @ 155]
> > fffff880021f4a60 0064007200610048 : 006b007300690064<br>&gt; &gt; 00520044005c0030 fffff88000000030 0000000000000000 :
> > 0x005c006500630069<br>&gt; &gt; fffff880021f4a68 006b007300690064 : 00520044005c0030
> > fffff88000000030<br>&gt; &gt; 0000000000000000 fffffa8303805d10 : 0x0064007200610048
> > fffff880021f4a70 00520044005c0030 : fffff88000000030<br>&gt; &gt; 0000000000000000
> > fffffa8303805d10 fffffa8303800e00 : 0x006b007300690064<br>&gt; &gt; fffff880021f4a78 fffff88000000030 : 0000000000000000
> > fffffa8303805d10<br>&gt; &gt; fffffa8303800e00 fffffa83037f28a0 : 0x00520044005c0030
> > fffff880021f4a80 0000000000000000 : fffffa8303805d10<br>&gt; &gt; fffffa8303800e00
> > fffffa83037f28a0 fffffa83037f2800 : 0xfffff880`00000030
> >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > OSR is HIRING!! See http://www.osr.com/careers
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
>
> NOTE: The information in this message is intended for the personal and
> confidential use of the designated recipient(s) named above. To the extent the
> recipient(s) is/are bound by a non-disclosure agreement, or other agreement
> that contains an obligation of confidentiality, with AuthenTec, then this
> message and/or any attachments shall be considered confidential information
> and subject to the confidentiality terms of that agreement. If the reader of this
> message is not the intended recipient named above, you are notified that you
> have received this document in error, and any review, dissemination,
> distribution or copying of this message is strictly prohibited. If you have
> received this document in error, please delete the original message and notify
> the sender immediately.
> Thank You!
> AuthenTec, Inc. http://www.authentec.com/
>
> —
> NTDEV is sponsored by OSR
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

NOTE: The information in this message is intended for the personal and confidential use of the designated recipient(s) named above. To the extent the recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an obligation of confidentiality, with AuthenTec, then this message and/or any attachments shall be considered confidential information and subject to the confidentiality terms of that agreement. If the reader of this message is not the intended recipient named above, you are notified that you have received this document in error, and any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this document in error, please delete the original message and notify the sender immediately.
Thank You!
AuthenTec, Inc. http://www.authentec.com/