FsRtlIsNtstatusExpected / FsRtlNormalizeNtstatus

NTFSD
1

Hi,

Currently when I need to wrap some functionality that might raise (Either user buffer access or Cc routines), I use the following generic code:

__try
{
…
}
__except ( EXCEPTION_EXECUTE_HANDLER )
{
Status = GetExceptionCode();

goto Done;
}

Prefast complains about me catching all exceptions. What is the “correct” way of handling this? Does it involve the use of FsRtlIsNtstatusExpected / FsRtlNormalizeNtstatus?

Thanks,
Matt

2

Yes
it is good to use FsRtlIsNtstatusExpected because it will tell you whether Cc function etc,. returns you expected status value like STATUS_INSUFFICIENT_RESOURCES if CC does not get memory to complete operation. But if use catch all exceptions in exception handler then it will suppress your bugs in your code. for example page fault in paged pool if give offset more that filesize in cc function.

You can refer filesys\fastfat code for better use of FsRtlIsNtstatusExpected.

3

xxxxx@yahoo.com wrote:

Yes
it is good to use FsRtlIsNtstatusExpected because it will tell you whether Cc function etc,. returns you expected status value like STATUS_INSUFFICIENT_RESOURCES if CC does not get memory to complete operation. But if use catch all exceptions in exception handler then it will suppress your bugs in your code. for example page fault in paged pool if give offset more that filesize in cc function.

You can refer filesys\fastfat code for better use of FsRtlIsNtstatusExpected.

The original post implied this was being done when touching untrusted
user buffers.

FsRtlIsNtstatusExpected returns TRUE for everything except nasty
conditions that “should never happen” (eg access violation, misaligned
data, etc) If calling into Cc, not handling these is a good thing - any
AV will not be handled, and will bugcheck the machine with meaningful
context.

Unfortunately when accessing user buffers these conditions can occur
and need to be handled. However, when accessing user buffers the status
should not be set to STATUS_ACCESS_VIOLATION (or whatever exception was
raised) and should be set to STATUS_INVALID_USER_BUFFER.

Since the handling of user buffers and everything else is so different,
keeping exception handlers as targeted as possible is generally a good idea.

  • M

–
This posting is provided “AS IS” with no warranties, and confers no rights.