Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ObQueryNameString: new behavior (no error) on Windows 10 build 17133 for registry key objects (buffer too small) #36

kITerE opened this issue Mar 29, 2018 — with · 5 comments


Copy link

@kITerE kITerE commented Mar 29, 2018 — with

Source code:
Status = ObQueryNameString(pObject, pObjInfo, uBufSize, &uResLen);


1: kd> dv
        pObject = 0x86a00420
         Status = 0n0
       uBufSize = 0x10
       pObjInfo = 0x8c2c4d30
        uResLen = 0x9e
1: kd> dx pObjInfo
pObjInfo         : 0x8c2c4d30 [Type: _OBJECT_NAME_INFORMATION *]
    [+0x000] Name             : "\RE" [Type: _UNICODE_STRING]
1: kd> !object 0x86a00420
Object: 86a00420  Type: (869169d0) Key
    ObjectHeader: 86a00408 (new version)
    HandleCount: 1 PointerCount: 33

That is: STATUS_SUCCESS is returned, but the name is not full and ReturnLength > Length

Windows 10 Kernel build 16299 return expected error - STATUS_INFO_LENGTH_MISMATCH:

0: kd> dv
        pObject = 0xffffce8b`b4a66c40
         Status = 0xc0000004
       uBufSize = 0x10
       pObjInfo = 0xffffce8b`b4d492e0
        uResLen = 0xa6

Document Details

Do not edit this section. It is required for ➟ GitHub issue linking.

@kITerE kITerE changed the title New behavior (no error) on Windows 10 build 17133 for registry key objects (buffer too small) ObQueryNameString: new behavior (no error) on Windows 10 build 17133 for registry key objects (buffer too small) Mar 29, 2018
Copy link

@AndrewHarryKim AndrewHarryKim commented Apr 26, 2018

Hello @kITerE,

Thanks for reaching out to the Windows Driver Developer Documentation team. Unfortunately, we don’t have the resources to offer individual technical advice to the broad array of customers who use the driver documentation.
You may have success posting your question in the following forums, where other driver developers and Microsoft engineers can be found. The community there is quite responsive.
• MSDN Windows Hardware WDK and Driver Development forum
• NTDEV forum at OSR Online
Again, thanks for reaching out. Best of luck with this issue.

Copy link

@madcoder3000 madcoder3000 commented Jun 10, 2018 — with

@AndrewHarryKim, @kITerE pointed out how the function behavior no longer matches the documentation. It no longer returns STATUS_INFO_LENGTH_MISMATCH which it is supposed to. Why would this not be a documentation issue? The documentation needs to be updated to reflect this change in behavior.

Copy link

@EliotSeattle EliotSeattle commented Jun 10, 2018

Thanks, @kITerE for staying on this. Unfortunately, Andrew is no longer working on these docs. @aahill can you please look into this and work with @kITerE to address any discrepancy between the docs and actual behavior?

@EliotSeattle EliotSeattle reopened this Jun 10, 2018
Copy link

@aahill aahill commented Jun 16, 2018

Hi @kITerE, @madcoder3000, @EliotSeattle

I've reached out to the development team for comment. Once they respond back I'll update the thread.


Copy link

@aahill aahill commented Jun 25, 2018

Hi all,

This looks to be a bug - the expected behavior should be STATUS_INFO_LENGTH_MISMATCH as you say. I've passed this along to the development team, so hopefully this will get fixed soon.

Thanks for finding this!

@aahill aahill closed this Jun 25, 2018
v-trisshores added a commit to v-trisshores/windows-driver-docs-ddi that referenced this issue Jul 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants