Can any API raise an exception?

NTFSD
1

Time for me to ask one now…

Is it true that all documented APIs in the IFSKIT (filesystem and
otherwise) that can raise a software exception are documented as being
able to do so? Or is any API fair game? The DDK is mum on the topic as
far as I can tell.

I’m trying to reduce stack usage in my code by removing unnecessary
__try/__finally constructs wherever possible. If I have to assume that
any kernel routine can raise, this means that I have to put a lot more
intra-function cleanup code in __finally constructs then I’m currently
doing.

–
Nick Ryan (MVP for DDK)

2

Nick Ryan wrote:

Time for me to ask one now…

Is it true that all documented APIs in the IFSKIT (filesystem and
otherwise) that can raise a software exception are documented as being
able to do so? Or is any API fair game? The DDK is mum on the topic as
far as I can tell.

I’m trying to reduce stack usage in my code by removing unnecessary
__try/__finally constructs wherever possible. If I have to assume that
any kernel routine can raise, this means that I have to put a lot more
intra-function cleanup code in __finally constructs then I’m currently
doing.

More generally, I’m interested in the approach people take towards
exception handling in their code. In my drivers, I do not raise or
re-throw exceptions for my own purposes, in contrast to a driver like
FastFat. Therefore, my goal is to identify and firewall all external
calls that can generate software exceptions. If the list of such calls
is definite and documented, I can encase them in wrappers that simply
transform the exceptions that the call is documented to raise into an
NTSTATUS return code. I’ll be able to do away with the existing
__finally and __except constructs around many of my own functions and
entry points today.

Nagar alludes to the value of trying to guard against ‘unexpected
errors’ as a reason for widespread use of SEH in a driver, but I don’t
see what these could be. If I can firewall the software exceptions as
described above, those are handled. And as far as hardware exceptions
go, most that I’ve seen are transformed into bugchecks by the
first-chance handler anyways (such as page faults on unallocated > 2GB
memory). Aside from faults on user-mode memory ranges, are there any
other categories of hardware exceptions that make it past the
first-chance handler that my driver should do something intelligent in
reaction to?

–
Nick Ryan (MVP for DDK)

3

There are only a few cases where we use a __try block. Most notably we wrap
access to user-memory in IOCTL calls and such.

I once ran a driver in distribution where I wrapped the dispatch entry point
in a __try block. I do not think I ever saw it handle an exception that was
not related to messing with user buffers in an IOCTL before or during
probing and locking.

Jamey Kirby, Windows DDK MVP
StorageCraft Inc.
xxxxx@storagecraft.com
http://www.storagecraft.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Nick Ryan
Sent: Monday, September 08, 2003 6:24 PM
To: File Systems Developers
Subject: [ntfsd] Can any API raise an exception?

Time for me to ask one now…

Is it true that all documented APIs in the IFSKIT (filesystem and
otherwise) that can raise a software exception are documented as being
able to do so? Or is any API fair game? The DDK is mum on the topic as
far as I can tell.

I’m trying to reduce stack usage in my code by removing unnecessary
__try/__finally constructs wherever possible. If I have to assume that
any kernel routine can raise, this means that I have to put a lot more
intra-function cleanup code in __finally constructs then I’m currently
doing.

–
Nick Ryan (MVP for DDK)

You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

Debugging purposes! I’ve had cases where things other than user memory
access has caused exceptions, and instead of bug checking (without a
proper stack trace virtually), instead I get an exception and know where
to look at. It’s useful.

Regards, Dejan.

Nick Ryan wrote:

Time for me to ask one now…

Is it true that all documented APIs in the IFSKIT (filesystem and
otherwise) that can raise a software exception are documented as being
able to do so? Or is any API fair game? The DDK is mum on the topic as
far as I can tell.

I’m trying to reduce stack usage in my code by removing unnecessary
__try/__finally constructs wherever possible. If I have to assume that
any kernel routine can raise, this means that I have to put a lot more
intra-function cleanup code in __finally constructs then I’m currently
doing.

–
Nick Ryan (MVP for DDK)

You are currently subscribed to ntfsd as: xxxxx@alfasp.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32
developers.
Alfa File Monitor - File monitoring library for Win32 developers.

5

Almost all Cc APIs can raise exceptions. the documentation is inconclusive
on this,
and do not document all cases when an exception is raised.

Dan

----- Original Message -----
From: “Nick Ryan”
Newsgroups: ntfsd
To: “File Systems Developers”
Sent: Tuesday, September 09, 2003 4:24 AM
Subject: [ntfsd] Can any API raise an exception?

> Time for me to ask one now…
>
> Is it true that all documented APIs in the IFSKIT (filesystem and
> otherwise) that can raise a software exception are documented as being
> able to do so? Or is any API fair game? The DDK is mum on the topic as
> far as I can tell.
>
> I’m trying to reduce stack usage in my code by removing unnecessary
> try/ finally constructs wherever possible. If I have to assume that
> any kernel routine can raise, this means that I have to put a lot more
> intra-function cleanup code in __finally constructs then I’m currently
> doing.
>
> –
> Nick Ryan (MVP for DDK)
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

6

OK, I’m going to assume all Cc and FsRtl calls can raise, and will also
assume that no other kernel APIs will raise unless documented so. I
think this is a valid assumption because the standard kernel APIs are
widely used outside the filesystem space, and Microsoft’s non-filesystem
samples use exception handling rarely.

Dan Partelly wrote:

Almost all Cc APIs can raise exceptions. the documentation is inconclusive
on this,
and do not document all cases when an exception is raised.

Dan

----- Original Message -----
From: “Nick Ryan”
> Newsgroups: ntfsd
> To: “File Systems Developers”
> Sent: Tuesday, September 09, 2003 4:24 AM
> Subject: [ntfsd] Can any API raise an exception?
>
>
>
>>Time for me to ask one now…
>>
>>Is it true that all documented APIs in the IFSKIT (filesystem and
>>otherwise) that can raise a software exception are documented as being
>>able to do so? Or is any API fair game? The DDK is mum on the topic as
>>far as I can tell.
>>
>>I’m trying to reduce stack usage in my code by removing unnecessary
>> try/ finally constructs wherever possible. If I have to assume that
>>any kernel routine can raise, this means that I have to put a lot more
>>intra-function cleanup code in __finally constructs then I’m currently
>>doing.
>>
>>–
>>Nick Ryan (MVP for DDK)
>>
>>
>>—
>>You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>
>
>
>

–
Nick Ryan (MVP for DDK)

7

I’ve seen in ntoskrnl.exe that some of the functions tries to set up the
__try block ie. accessing fs: or may be for getting to TEB, also by
looking
thru the IDA debugger tools that some functions explicitly raise exceptions
by calling KiRaiseEx*, did not look at the __catch or __finally side though.

-prokash
from the Desk of Dirty Harry

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Nick Ryan
Sent: Tuesday, September 09, 2003 10:21 AM
To: File Systems Developers
Subject: [ntfsd] Re: Can any API raise an exception?

OK, I’m going to assume all Cc and FsRtl calls can raise, and will also
assume that no other kernel APIs will raise unless documented so. I
think this is a valid assumption because the standard kernel APIs are
widely used outside the filesystem space, and Microsoft’s non-filesystem
samples use exception handling rarely.

Dan Partelly wrote:

Almost all Cc APIs can raise exceptions. the documentation is inconclusive
on this,
and do not document all cases when an exception is raised.

Dan

----- Original Message -----
From: “Nick Ryan”
> Newsgroups: ntfsd
> To: “File Systems Developers”
> Sent: Tuesday, September 09, 2003 4:24 AM
> Subject: [ntfsd] Can any API raise an exception?
>
>
>
>>Time for me to ask one now…
>>
>>Is it true that all documented APIs in the IFSKIT (filesystem and
>>otherwise) that can raise a software exception are documented as being
>>able to do so? Or is any API fair game? The DDK is mum on the topic as
>>far as I can tell.
>>
>>I’m trying to reduce stack usage in my code by removing unnecessary
>> try/ finally constructs wherever possible. If I have to assume that
>>any kernel routine can raise, this means that I have to put a lot more
>>intra-function cleanup code in __finally constructs then I’m currently
>>doing.
>>
>>–
>>Nick Ryan (MVP for DDK)
>>
>>
>>—
>>You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>
>
>
>

–
Nick Ryan (MVP for DDK)

—
You are currently subscribed to ntfsd as: xxxxx@vormetric.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

8

>>and will also

> assume that no other kernel APIs will raise unless documented so.

Dont. This really do not holds true. Ms usually ommits to document all cases
in which an API can raise, and in some cases totally ommit to say an API can
raise at all. I have a list with almost all APIs which can raise somehwere,
there aint too many of them, but some are important.

----- Original Message -----
From: “Nick Ryan”
Newsgroups: ntfsd
To: “File Systems Developers”
Sent: Tuesday, September 09, 2003 8:20 PM
Subject: [ntfsd] Re: Can any API raise an exception?

> OK, I’m going to assume all Cc and FsRtl calls can raise, and will also
> assume that no other kernel APIs will raise unless documented so. I
> think this is a valid assumption because the standard kernel APIs are
> widely used outside the filesystem space, and Microsoft’s non-filesystem
> samples use exception handling rarely.
>
> Dan Partelly wrote:
>
> > Almost all Cc APIs can raise exceptions. the documentation is
inconclusive
> > on this,
> > and do not document all cases when an exception is raised.
> >
> > Dan
> >
> > ----- Original Message -----
> > From: “Nick Ryan”
> > Newsgroups: ntfsd
> > To: “File Systems Developers”
> > Sent: Tuesday, September 09, 2003 4:24 AM
> > Subject: [ntfsd] Can any API raise an exception?
> >
> >
> >
> >>Time for me to ask one now…
> >>
> >>Is it true that all documented APIs in the IFSKIT (filesystem and
> >>otherwise) that can raise a software exception are documented as being
> >>able to do so? Or is any API fair game? The DDK is mum on the topic as
> >>far as I can tell.
> >>
> >>I’m trying to reduce stack usage in my code by removing unnecessary
> >> try/ finally constructs wherever possible. If I have to assume that
> >>any kernel routine can raise, this means that I have to put a lot more
> >>intra-function cleanup code in __finally constructs then I’m currently
> >>doing.
> >>
> >>–
> >>Nick Ryan (MVP for DDK)
> >>
> >>
> >>—
> >>You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> >>To unsubscribe send a blank email to xxxxx@lists.osr.com
> >>
> >
> >
> >
> >
>
> –
> Nick Ryan (MVP for DDK)
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

9

Ouch. Then Microsoft should make it clear to the community what we
should be doing, as driver developers, to handle exceptions cleanly in
our own code. I’ll try to see if I can get a more direct response from
someone at MS on this issue.

Dan Partelly wrote:

>>and will also
>>assume that no other kernel APIs will raise unless documented so.

Dont. This really do not holds true. Ms usually ommits to document all cases
in which an API can raise, and in some cases totally ommit to say an API can
raise at all. I have a list with almost all APIs which can raise somehwere,
there aint too many of them, but some are important.

----- Original Message -----
From: “Nick Ryan”
> Newsgroups: ntfsd
> To: “File Systems Developers”
> Sent: Tuesday, September 09, 2003 8:20 PM
> Subject: [ntfsd] Re: Can any API raise an exception?
>
>
>
>>OK, I’m going to assume all Cc and FsRtl calls can raise, and will also
>>assume that no other kernel APIs will raise unless documented so. I
>>think this is a valid assumption because the standard kernel APIs are
>>widely used outside the filesystem space, and Microsoft’s non-filesystem
>>samples use exception handling rarely.
>>
>>Dan Partelly wrote:
>>
>>
>>>Almost all Cc APIs can raise exceptions. the documentation is
>
> inconclusive
>
>>>on this,
>>>and do not document all cases when an exception is raised.
>>>
>>>Dan
>>>
>>>----- Original Message -----
>>>From: “Nick Ryan”
>>>Newsgroups: ntfsd
>>>To: “File Systems Developers”
>>>Sent: Tuesday, September 09, 2003 4:24 AM
>>>Subject: [ntfsd] Can any API raise an exception?
>>>
>>>
>>>
>>>
>>>>Time for me to ask one now…
>>>>
>>>>Is it true that all documented APIs in the IFSKIT (filesystem and
>>>>otherwise) that can raise a software exception are documented as being
>>>>able to do so? Or is any API fair game? The DDK is mum on the topic as
>>>>far as I can tell.
>>>>
>>>>I’m trying to reduce stack usage in my code by removing unnecessary
>>>> try/ finally constructs wherever possible. If I have to assume that
>>>>any kernel routine can raise, this means that I have to put a lot more
>>>>intra-function cleanup code in __finally constructs then I’m currently
>>>>doing.
>>>>
>>>>–
>>>>Nick Ryan (MVP for DDK)
>>>>
>>>>
>>>>—
>>>>You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
>>>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>>>
>>>
>>>
>>>
>>>
>>–
>>Nick Ryan (MVP for DDK)
>>
>>
>>—
>>You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>
>
>
>

–
Nick Ryan (MVP for DDK)

10

And are you holding out to drive us crazy or will you actually post the
list?

Jamey Kirby, Windows DDK MVP
StorageCraft Inc.
xxxxx@storagecraft.com
http://www.storagecraft.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Partelly
Sent: Tuesday, September 09, 2003 1:32 PM
To: File Systems Developers
Subject: [ntfsd] Re: Can any API raise an exception?

>and will also
> assume that no other kernel APIs will raise unless documented so.

Dont. This really do not holds true. Ms usually ommits to document all cases
in which an API can raise, and in some cases totally ommit to say an API can
raise at all. I have a list with almost all APIs which can raise somehwere,
there aint too many of them, but some are important.

----- Original Message -----
From: “Nick Ryan”
Newsgroups: ntfsd
To: “File Systems Developers”
Sent: Tuesday, September 09, 2003 8:20 PM
Subject: [ntfsd] Re: Can any API raise an exception?

> OK, I’m going to assume all Cc and FsRtl calls can raise, and will also
> assume that no other kernel APIs will raise unless documented so. I
> think this is a valid assumption because the standard kernel APIs are
> widely used outside the filesystem space, and Microsoft’s non-filesystem
> samples use exception handling rarely.
>
> Dan Partelly wrote:
>
> > Almost all Cc APIs can raise exceptions. the documentation is
inconclusive
> > on this,
> > and do not document all cases when an exception is raised.
> >
> > Dan
> >
> > ----- Original Message -----
> > From: “Nick Ryan”
> > Newsgroups: ntfsd
> > To: “File Systems Developers”
> > Sent: Tuesday, September 09, 2003 4:24 AM
> > Subject: [ntfsd] Can any API raise an exception?
> >
> >
> >
> >>Time for me to ask one now…
> >>
> >>Is it true that all documented APIs in the IFSKIT (filesystem and
> >>otherwise) that can raise a software exception are documented as being
> >>able to do so? Or is any API fair game? The DDK is mum on the topic as
> >>far as I can tell.
> >>
> >>I’m trying to reduce stack usage in my code by removing unnecessary
> >> try/ finally constructs wherever possible. If I have to assume that
> >>any kernel routine can raise, this means that I have to put a lot more
> >>intra-function cleanup code in __finally constructs then I’m currently
> >>doing.
> >>
> >>–
> >>Nick Ryan (MVP for DDK)
> >>
> >>
> >>—
> >>You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> >>To unsubscribe send a blank email to xxxxx@lists.osr.com
> >>
> >
> >
> >
> >
>
> –
> Nick Ryan (MVP for DDK)
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

—
You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

11

Ill try to find it and post it. I compiled it long ago, and at first
examination of my HDD I could not locate it.

Dan

----- Original Message -----
From: “Jamey Kirby”
To: “File Systems Developers”
Sent: Wednesday, September 10, 2003 12:13 AM
Subject: [ntfsd] Re: Can any API raise an exception?

And are you holding out to drive us crazy or will you actually post the
list?

Jamey Kirby, Windows DDK MVP
StorageCraft Inc.
xxxxx@storagecraft.com
http://www.storagecraft.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Partelly
Sent: Tuesday, September 09, 2003 1:32 PM
To: File Systems Developers
Subject: [ntfsd] Re: Can any API raise an exception?

>>and will also
>> assume that no other kernel APIs will raise unless documented so.

Dont. This really do not holds true. Ms usually ommits to document all cases
in which an API can raise, and in some cases totally ommit to say an API can
raise at all. I have a list with almost all APIs which can raise somehwere,
there aint too many of them, but some are important.

----- Original Message -----
From: “Nick Ryan”
Newsgroups: ntfsd
To: “File Systems Developers”
Sent: Tuesday, September 09, 2003 8:20 PM
Subject: [ntfsd] Re: Can any API raise an exception?

> OK, I’m going to assume all Cc and FsRtl calls can raise, and will also
> assume that no other kernel APIs will raise unless documented so. I
> think this is a valid assumption because the standard kernel APIs are
> widely used outside the filesystem space, and Microsoft’s non-filesystem
> samples use exception handling rarely.
>
> Dan Partelly wrote:
>
> > Almost all Cc APIs can raise exceptions. the documentation is
inconclusive
> > on this,
> > and do not document all cases when an exception is raised.
> >
> > Dan
> >
> > ----- Original Message -----
> > From: “Nick Ryan”
> > Newsgroups: ntfsd
> > To: “File Systems Developers”
> > Sent: Tuesday, September 09, 2003 4:24 AM
> > Subject: [ntfsd] Can any API raise an exception?
> >
> >
> >
> >>Time for me to ask one now…
> >>
> >>Is it true that all documented APIs in the IFSKIT (filesystem and
> >>otherwise) that can raise a software exception are documented as being
> >>able to do so? Or is any API fair game? The DDK is mum on the topic as
> >>far as I can tell.
> >>
> >>I’m trying to reduce stack usage in my code by removing unnecessary
> >> try/ finally constructs wherever possible. If I have to assume that
> >>any kernel routine can raise, this means that I have to put a lot more
> >>intra-function cleanup code in __finally constructs then I’m currently
> >>doing.
> >>
> >>–
> >>Nick Ryan (MVP for DDK)
> >>
> >>
> >>—
> >>You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> >>To unsubscribe send a blank email to xxxxx@lists.osr.com
> >>
> >
> >
> >
> >
>
> –
> Nick Ryan (MVP for DDK)
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

—
You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
To unsubscribe send a blank email to xxxxx@lists.osr.com