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/
Based on the Storport Miniport example I have created a virtual file backed USB block storage. It works well, when the underlying file is stored in a path, which only contains ascii-like characters.
Now I created a path which contains arabic unicode symbols (e.g to allow for different locales) and try to open the file in the Kernel with ZwOpenFile resulting in NTSTATUS Code STATUS_OBJECT_PATH_NOT_FOUND (0xc000003a).
The file is created in the user space code and visible with i.e. Windows Explorer. Strings in the code are represented as wchar_t arrays.
The user space code then prepends L"\DosDevices\" to the absolute file path and sends it into the Kernel space.
Hexdumps of the UNICODE String Buffer in the Kernel and the wchar_t in the userspace are identical and the path printed with DebugView seems correct.
(If the DebugView output is stored to a log file, a unicode capable editor shows the correct path.)
I am not sure if the "conversion" to a DosDevice is correct. My understanding is that \DosDevices\C: is a link to the C: drive and the I do not need to modify the following path. Is this correct?
Has anyone experience how to deal with UNICODE paths in Kernel space?
|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!|
|Writing WDF Drivers||7 Dec 2020||LIVE ONLINE|
|Internals & Software Drivers||25 Jan 2021||LIVE ONLINE|
|Developing Minifilters||8 March 2021||LIVE ONLINE|