RtlInitEmptyUnicodeString(
                (PUNICODE_STRING)&NameControl->smallBuffer,
                (PWCHAR)(NameControl->smallBuffer + sizeof(UNICODE_STRING)),
                (USHORT)(sizeof(NameControl->smallBuffer) - sizeof(UNICODE_STRING)) );

            return (PUNICODE_STRING)&NameControl->smallBuffer;

紧接着他就是吧256的BUFFER当做UNICODE看的

但是毕竟UNICODE_STRING第一、二个成员是USHORT 的类型，这样赋值，并不会赋进Buffer中。

也许他有自己的打算
并没打算把CHAR BUFFER的起始地址当做UNICODE的buffer地址
你尝试WINDBG 调试下  SMALLBUFFER的构成是什么样子并跟踪下 是怎么形成的就清晰多了

感觉想sfilter这样的代码是不会吧CHAR[XX] 只当个指针来用的 否则他一定会声明指针类型。很纠结。。。

完全不用纠结，根本原因是OBJECT_NAME_INFORMATION这个东西，操作系统在处理的时候不太合常规。
正常情况下你提供一个UNICODE_STRING结构，然后系统会把返回数据放在UNICODE_STRING的Buffer成员指向的缓冲区里，通常都是这样的。
但是，这个ObQueryNameString在处理传入的缓冲区时，是把这个缓冲区当作一个整体，以下是wrk中的部分代码，ObjectNameInfo就是传入的缓冲区参数，类型是POBJECT_NAME_INFORMATION。

OriginalBuffer = (PWCH)((PCH)ObjectNameInfo + sizeof( OBJECT_NAME_INFORMATION ));
...
ObjectNameInfo->Name.MaximumLength = (USHORT)BufferLength;
ObjectNameInfo->Name.Length = (USHORT)(BufferLength - sizeof( UNICODE_NULL ));
ObjectNameInfo->Name.Buffer = OriginalBuffer;
...
 RtlMoveMemory(OriginalBuffer, StringBuffer, BufferLength);

注意观察系统对ObjectNameInfo的成员的初始化，就知道这个buffer到底是怎么用的了。系统是把这个buffer作为一个整体，然后在buffer开头保留一个UNICODE_STRING结构，然后把剩下的部分作为了这个UNICODE_STRING的Buffer，也就是说，你只要提供一块足够的缓冲区就行了，系统会自已把这个结构初始化成一个UNICODE_STRING，调用完成后，ObjectNameInfo->Name.Buffer里就是你想要的内容，而不需要你为这个UNICODE_STRING再额外申请缓冲区。

可能会有很多人自己先填充一个UNICODE_STRING结构，自己提供这个结构里的Buffer，这样反而会出错，也许这算是一个特例吧，使用ObQueryNameString/ZwQueryObject查询对象名称时注意就行了，不清楚的自己调试或者看Wrk~~

多谢 catface 和 achillis
achillis讲了ObQueryNameString缓冲区的知识，的确收益匪浅。
经过我反复阅读代码发现CHAR smallBuffer[256]的确只是起到了一个指针的作用，指向一个UNICODE。这样也许就是在填充的时候不在分配缓冲区而简化操作的用途。