There's a rumor that's been around for a while that says that there are some Windows DDIs that can raise exceptions, instead of (or in addition to) returning status or output values. When this issue once again reared its ugly head, developer Nick Ryan used his resources to chase down real answer. Nick can be regularly found sharing his insights and expertise on the NTDEV and NTFSD lists.
It seems that the DDK and IFS kit at one time failed to mention a number of the functions that could raise. Most of those omissions have been fixed, however. Nick says the folks at Microsoft that he contacted agreed that any functions that raise an exception should be documented (with the exception of functions that raise as a result of bad input -- such as the exception caused by dereferencing a bad pointer -- or other similar situations). He provides the list of functions that are currently documented as raising exceptions below.
Microsoft has confirmed that a Structured Exception Handler is only needed by a driver to handle exceptions raised by kernel APIs documented to raise, or around accesses to user-mode memory ranges (such as when calling ProbeForRead/Write). Any other case where an exception is raised is due to coding bugs in the driver or as a result of the driver deliberately raising an exception via the provided DDIs.
Our thanks to Nick for being pro-active in helping out the community!
CcCopyWrite
CcFastCopyWrite
CcCopyRead
CcMdlRead
CcZeroData
CcInitializeCacheMap
PsReturnPoolQuota
PsChargePoolQuota
IoCreateStreamFileObjectLite
IoCreateStreamFileObjectEx
IoCreateStreamFileObject
FsRtlSplitLargeMcb
FsRtlRemoveLargeMcbEntry
FsRtlNotifyInitializeSync
FsRtlAreNamesEqual
FsRtlAllocatePoolWithTag
FsRtlAllocatePoolWithQuotaTag
FsRtlAddLargeMcbEntry
FsRtlInitializeLargeMcb
ProbeForRead
ProbeForWrite
ExRaiseDatatypeMisalignment
ExRaiseAccessViolation
ExAllocatePoolWithQuotaTag
MmMapLockedPagesSpecifyCache
MmProbeAndLockPages
Post Your Comment
