> Being “not document” means its not meant to be called by drivers in any case.
Actually, the only thing that “undocumented” means is that it is not supposed to be called by the
third-party drivers, because MSFT may change implementation in the future.However, MSFT-provided drivers are just fine with calling it. As long as this undocumented function is one of NTOSKRNL’s exports, in most cases you are able to link to it directly, without having to obtain its address by other means and calling it by the address. All the problems that one may encounter with it are mainly of theoretical nature,i.e. fall into “what happens if implementation gets changed in some future OS version” class.
However, if function is exported via SSDR, but NTOSKRNL’s export section does not export it in
either Nt… or Zw… form, the function is not supposed by any KM component. First of all, you are unable to link to it, in the first place - you have to call it either by the address or by your own
Zw… stub, i.e.via INT0x2E. No matter which option you choose you are more than likely to get into a serious trouble right on the spot with it, because the function expects a userland caller.
Therefore, my question is in which class NtShutdownSytem() falls - I think it belongs in the latter one (which is, probably, of zero importance in this particular case anyway)…
I’m not sure what that means, but it sounds very scary and ominous.
Well, I meant exactly what I said - in some cases BSOD may leave you with destroyed user data, which is, indeed, “scary and ominous”. The file in itself will still be there, but its contents will be destroyed and overwritten with some gibberish. For example, I managed to successfully destroy C files that were opened in VisualStudio at the time of BSOD, and managed to do so on multiple occasions.The first one was an “accidentental discovery”, so that I decided to check if it was reproducible. In terms of predictability the whole thing worked just in “clock-like fashion”. The FS per se was perfectly fine due to the transactional nature of the way NTFS handles its metadata, but open C files were destroyed and overwritten with plain binary gibberish (IIRC,it was fillled with all zeroes, but I may be wrong here)…
The file system, and its associated user data, will be consistent as of the points of the last flush.
It might not be UP TO DATE. But it will be consistent. Thus guarantees NTFS. Perhaps
that’s what you meant…
You should realize that “first-generation” transactional filesystems like NTFS and Ext3/4 do NOT
guarantee anything in respect of user data. If you want such guarantees you need something more serious, i.e. something like ZFS or BTRFS. These file systems never overwrite anything - they first record new data, change pointers to it in the filesystem all the way to the root, and then update the root. Until FS root gets updated all this FS update is nothing more than just an exercise in scratching on a free space. If something gets wrong you are left with the previous state of FS and user data as if nothing had happened. I think the concept of such approach originates in so-called
“dancing trees” of ReiserFS…
Anton Bassov