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

Home NTDEV

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/


Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

RtlStringCchPrintfExW vs _snwprintf

DWDriverDWDriver Member Posts: 8

HI,
Due to a bug in VS2019, we got many unresolved for _snwprintf_s. I tried to replace all "_snwprintf" with RtlStringCchPrintfExW but it did not work, the error still appears. After doing some Google research I found the solution #define _NO_CRT_STDIO_INLINE // VS2019 JUNE BUG lead to unresolved vswprintf, even if not used at all.
Now I can use again my _snwprintf_s as it was before.

However I want to know your oppinion what you prefer using "_snwprintf_s" or "RtlStringCchPrintfExW " in a kernel driver?

HOpe you can advise,
kind regqards
Dietmar

Comments

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,970

    I don't see how it possibly matters. I've never fully understood why the kernel team reinvented the wheel as it was.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,493
    edited June 9

    This post made me laugh... Just a few weeks back, I had the same wonderful experience, and wound up with:

    I, personally, am over the "safer yet more annoying" string handling variants. If you were to ask me my professional opinion, I'd probably say their use is a best practice. But do I typically use them? No...

    Peter

    ETA: Incidental to that code clip I posted... Why is there no standard define for the length of Config Space? But that's another question entirely...

    Post edited by Peter_Viscarola_(OSR) on

    Peter Viscarola
    OSR
    @OSRDrivers

  • DWDriverDWDriver Member Posts: 8

    Hi,

    Thx for your comments! As I said the problem is solved. A point is that MS is just looking into, but does not inform developers about that issue. After you know what #define you have to use it is easy but it takes time to find

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,436

    OFFS I think I just smacked into this. To be clear: you don't have to 'upgrade' SDK/WDK kits? You just have to update VS2019?

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,493

    It "just showed up" one day. I quite literally have no idea from whence it came. Come to think of it, it wouldn't likely be a SDK/WDK update (I'm still using the Windows 10 2004 WDK)... so it MUST have been prompted by "just" a VS update. You know, one of the ones with 594 steps, that takes 15 minutes to install, and requires you to reboot your system afterwards. For a complier/linker update.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,436

    I've determined it is the VS update, not WDK/SDK. That is actually worse as it it potentially impacts building release branch builds. This is yet another example of why a production CI/CD environment for windows drivers should use the self-contained EWDK toolkits and not rely on the fragile integration of VS and WDK.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,493

    Wisdom! Let us be attentive!

    Peter Viscarola
    OSR
    @OSRDrivers

  • MecanikMecanik Member Posts: 15

    As per your original question:

    _snwprintf_s - Writes formatted data to a string. These are versions of snprintf, _snprintf, _snprintf_l, _snwprintf, _snwprintf_l with security enhancements as described in Security Features in the CRT.

    RtlStringCchPrintfExW - The RtlStringCchPrintfExW and RtlStringCchPrintfExA functions create a character-counted text string, with formatting that is based on supplied formatting information.

    Remarks
    RtlStringCchPrintfExW and RtlStringCchPrintfExA should be used instead of the following functions:

    • sprintf
    • swprintf
    • _snprintf
    • _snwprintf

    In drivers, I personally prefer to use functions like Rtl* (as the docs suggest). Unfortunately, I cannot show you the source code of this from Windows, but ReactOS is nice enough to show us a body:

    NTSTRSAFEVAPI
     RtlStringCchPrintfExW(_Out_writes_(cchDest) _Always_(_Post_z_) NTSTRSAFE_PWSTR pszDest, _In_ size_t cchDest,_Outptr_opt_result_buffer_(*pcchRemaining) NTSTRSAFE_PWSTR *ppszDestEnd,
         _Out_opt_ size_t *pcchRemaining, _In_ STRSAFE_DWORD dwFlags, _In_ _Printf_format_string_ NTSTRSAFE_PCWSTR pszFormat, ...)
     {
         NTSTATUS Status;
         size_t cbDest = cchDest * sizeof(wchar_t);
         va_list argList;
    
         if (cchDest > NTSTRSAFE_MAX_CCH)
         {
             if (cchDest > 0)
                 *pszDest = L'\0';
             return STATUS_INVALID_PARAMETER;
         }
    
         va_start(argList, pszFormat);
         Status = RtlStringVPrintfExWorkerW(pszDest, cchDest, cbDest, ppszDestEnd, pcchRemaining, dwFlags, pszFormat, argList);
         va_end(argList);
    
         return Status;
     }
    

    As you can see this takes advantage of the NTSTRSAFE. The function will use va_list and pass the work onto RtlStringVPrintfExWorkerW -> RtlpStringVPrintfExWorkerW which does everything inside the kernel.

    Using RtlStringCchPrintfExW is most definitely the "safe" and "better" way to go.

    A5EF6AC930666A823A905224B7829A417718CA3360E62B9F890B722B20B8BDA5AE187C20E8F7070EADC6B82998999F02

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,970

    RtlStringCchPrintfExW is no safer than _snwprintf_s. They have identical functionality with different spelling. The key is to use something safe, and not fall back to the old unsafe swprintf habits.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • MecanikMecanik Member Posts: 15

    @Tim_Roberts said:
    RtlStringCchPrintfExW is no safer than _snwprintf_s. They have identical functionality with different spelling. The key is to use something safe, and not fall back to the old unsafe swprintf habits.

    I tend to disagree, as per Microsoft:

    If you use the safe string functions instead of the string manipulation functions that are provided by C-language run-time libraries, you protect your code from buffer overrun errors that can make code untrustworthy.

    Now in real life situations if this is different, it's just Microsoft :D

    A5EF6AC930666A823A905224B7829A417718CA3360E62B9F890B722B20B8BDA5AE187C20E8F7070EADC6B82998999F02

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,600

    If you use the safe string functions instead of the string manipulation functions that are provided by C-language run-time libraries, you protect your code from buffer overrun errors that can make code untrustworthy.

    This is referring to older the CRT functions that are not safe (IOW, the functions not ending in _s). Tim is correct, the RtlStringCch/Cb and RtlUnicodeStringCch/Cb functions all eventually thunk to some variant of the CRT safe function. At least they did when I added all the RtlUnicodeStringCch/Cb functions to ntstrsafe.h

    d
  • MBond2MBond2 Member Posts: 331

    'safe' here is a relative term. Even the most 'unsafe' version of these functions can be completely safe when used properly, but any function that relies on format strings is very hard to use completely correctly.

    now the next thing that someone will say (or think) is 'but the old old functions don't even let you specify the size of the buffer that they will write into' - any they will be right, but you actually don't need to if you are careful. Every kind of things that you might write to a buffer this way, can have a known in advance maximum size. Any can therefore avoid any sort of possible buffer overrun if you analyze the code in minute detail

    the point of these functions is that hardly anyone has the time or attention to analyze these things in enough detail and we want the safety that they provide for infrequently used code paths. The wrong format specifier can still cause an access violation, but buffer size is the most basic and therefore the subject of these safe versions of the function

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!
Developing Minifilters 24 May 2021 Live, Online
Writing WDF Drivers 14 June 2021 Live, Online
Internals & Software Drivers 27 September 2021 Live, Online
Kernel Debugging 15 November 2021 Live, Online