Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTFSD
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Bug with RtlIsNtDdiVersionAvailable?

Bill_ZissimopoulosBill_Zissimopoulos Member Posts: 117
edited June 1 in NTFSD

The RtlIsNtDdiVersionAvailable DDI fails whenever the passed Version parameter has the LSB byte as non-zero. This makes tests such as RtlIsNtDdiVersionAvailable(NTDDI_WIN10_RS4) useless because they will always return false.

  • Confirmed with WinDbg and Ghidra.
  • NTDDI_WIN10_RS4 is defined as 0x0A000005 and since 5!=0 it fails the test regardless of Windows version. NTDDI_WIN10 is defined as 0x0A000000, which will succeed on a Win10 system.

This looks to me like a bug, but perhaps it is intentional for "compatibility" or other reason. I note that the RtlIsNtDdiVersionAvailable documentation page does not list any of the NTDDI_WIN10_* values as accepted, so perhaps it is intentional.

https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-rtlisntddiversionavailable

Frankly this limitation (intentional or not) makes RtlIsNtDdiVersionAvailable pretty useless for many use cases.

Anyone else has observed something similar?

Bill

Comments

  • Don_BurnDon_Burn Member - All Emails Posts: 1,692

    From a post by Tim Roberts on the Microsoft WDK forum. The code for RtlIsNtDdiVersionAvailable in RS4 is:

    if( version & 0xffff != 0 )
    return FALSE;
    return version <= NTDDI_WIN10_RS4;

  • Bill_ZissimopoulosBill_Zissimopoulos Member Posts: 117

    Don, thanks.

    Yes, this is more or less what I am seeing in Ghidra as well.

    Which makes me wonder how we are supposed to check for the availability of a change that we cannot test via MmGetSystemRoutineAddress. In my case I am looking for a bug fix that happened to windows in NTDDI_WIN10_RS4, so that I can disable my workaround.

  • Bill_ZissimopoulosBill_Zissimopoulos Member Posts: 117

    I guess my one option is to do RtlGetVersion and check against the build number.

    I will write my own version of RtlIsNtDdiVersionAvailable while I am at it, since MSFT cannot deliver one that works.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,853

    Did you try RtlIsServicePackVersionInstalled? That, I think, is designed to match on the lower WORD. I admit... the APIs aresuper confusing.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Bill_ZissimopoulosBill_Zissimopoulos Member Posts: 117

    Peter, I looked at in in Ghidra. Unfortunately this DDI is rather useless in Win10. It just checks that the OSVER is 10 and that the SPVER is 0. It never checks the LSB byte for its value.

    I could post the code from Ghidra, but I am not sure if it is an acceptable use of this forum.

  • rod_widdowsonrod_widdowson Member - All Emails Posts: 1,131

    Its been too long ago since I last looked but I cam to the conclusion that Windows 10 broken enough if these things in enough ways - or at least made them hard for me to understand that I' pretty much stopped using it.

    Instead I recast my problems differently. So not "This function is only available since ", becomes "is this function available() ? use it : simulate it".

    Of course this will break down when the semantics change between release like the ECP who's layout changed between releases (for the same GUID) - although at least there was another API which "did the right thing".

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 15 Jun 2020 LIVE ONLINE
Writing WDF Drivers 22 June 2020 LIVE ONLINE
Internals & Software Drivers 28 Sept 2020 Dulles, VA