I write a lot of code like the following:
__try {
ExAcquireFastMutex(&lock);
if (something) {
…
__leave;
} else {
…
}
}
__finally {
ExReleaseFastMutex(&lock);
}
I like this because the lock will be freed even if an exception occurs.
Is this bad for performance and/or stack usage in a filter?
Thanks,
Jon
If an exception occors in the kernel, don’t count on your handlers doing
a damn thing. Count on a bsod…
Jon Anglin wrote:
I write a lot of code like the following:
__try {
ExAcquireFastMutex(&lock);
if (something) {
…
__leave;
} else {
…
}
}__finally {
ExReleaseFastMutex(&lock);
}I like this because the lock will be freed even if an exception occurs.
Is this bad for performance and/or stack usage in a filter?Thanks,
Jon
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com
No, that’s inaccurate, or at least it is an incomplete and useless response.
Structured exception handling can be used in kernel-mode code, subject to
certain constraints. The most important is that you can only use SEH at
PASSIVE_LEVEL. So, you must never use __try/__except at elevated IRQL
(DISPATCH_LEVEL, device level, etc.).
The second constraint is that you must be aware of the greater impact on
your stack consumption. Using SEH causes the compiler to emit more code,
which uses more stack space, in your driver. Kernel stacks are fixed in
size, and cannot grow dynamically. If you exceed the maximum stack size,
you will crash the system.
By the way, ExAcquireFastMutex raises your current thread to APC_LEVEL. I
don’t know whethe SEH is safe at PASSIVE_LEVEL or not. So you might want to
verify whether or not using __try/__except is safe or not.
DDK 2600 contains an article titled “Handling Exceptions”, that describes
how to deal with SEH in drivers.
– arlie
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of MM
Sent: Monday, December 19, 2005 9:44 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] __try, __finally question
If an exception occors in the kernel, don’t count on your handlers doing a
damn thing. Count on a bsod…
Jon Anglin wrote:
I write a lot of code like the following:
__try {
ExAcquireFastMutex(&lock);
if (something) {
…
__leave;
} else {
…
}
}__finally {
ExReleaseFastMutex(&lock);
}I like this because the lock will be freed even if an exception occurs.
Is this bad for performance and/or stack usage in a filter?Thanks,
Jon
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17You are currently subscribed to ntfsd as: xxxxx@comcast.net To
unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@stonestreetone.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
> The most important is that you can only use SEH at PASSIVE_LEVEL.
DDK 2600 contains an article titled “Handling Exceptions”
That’s something I had to figure out myself.
I checked 3790.1830 (w2k3ssp1) and 3790.2453 (KMDF) DDK’s and found
nothing about __try/__except irql-related limtations there.
In particular, nether of the two most important articles (there is no
article named “Handling Exceptions” in 3790), which are (links are local,
sorry)
and
the 1st being actually a quote from NTFSD FAQs, do not mention irq levels at
all.
The same is true for (that’s online)
“Handling Exceptions” at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/kmarch/hh/kmarch/Other_f7259c51-1557-42e6-8264-ac8dae0177e3.xml.asp
The only vague ref - not to mention my very own blood sweat and tears - came
from a guy nicked as Four-F on a russian-language web site.
Can you do me a favor and forward me (directly) the article you mention?
I kinda doubt whether 3790 > 2600 or not:-)
----- Original Message -----
From: “Arlie Davis”
To: “Windows File Systems Devs Interest List”
Sent: Monday, December 19, 2005 11:48 AM
Subject: RE: [ntfsd] try, finally question
> No, that’s inaccurate, or at least it is an incomplete and useless
> response.
>
> Structured exception handling can be used in kernel-mode code, subject to
> certain constraints. The most important is that you can only use SEH at
> PASSIVE_LEVEL. So, you must never use try/ except at elevated IRQL
> (DISPATCH_LEVEL, device level, etc.).
>
> The second constraint is that you must be aware of the greater impact on
> your stack consumption. Using SEH causes the compiler to emit more code,
> which uses more stack space, in your driver. Kernel stacks are fixed in
> size, and cannot grow dynamically. If you exceed the maximum stack size,
> you will crash the system.
>
> By the way, ExAcquireFastMutex raises your current thread to APC_LEVEL. I
> don’t know whethe SEH is safe at PASSIVE_LEVEL or not. So you might want
> to
> verify whether or not using try/ except is safe or not.
>
> DDK 2600 contains an article titled “Handling Exceptions”, that describes
> how to deal with SEH in drivers.
>
> – arlie
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of MM
> Sent: Monday, December 19, 2005 9:44 AM
> To: Windows File Systems Devs Interest List
> Subject: Re: [ntfsd] try, finally question
>
> If an exception occors in the kernel, don’t count on your handlers doing a
> damn thing. Count on a bsod…
>
> Jon Anglin wrote:
>
>>I write a lot of code like the following:
>>
>>__try {
>> ExAcquireFastMutex(&lock);
>> if (something) {
>> …
>>__leave;
>> } else {
>> …
>> }
>>}
>>
>>__finally {
>> ExReleaseFastMutex(&lock);
>>}
>>
>>I like this because the lock will be freed even if an exception occurs.
>>Is this bad for performance and/or stack usage in a filter?
>>
>>Thanks,
>>Jon
>>
>>
>>
>>—
>>Questions? First check the IFS FAQ at
>>https://www.osronline.com/article.cfm?id=17
>>
>>You are currently subscribed to ntfsd as: xxxxx@comcast.net To
>>unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@stonestreetone.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@bellsouth.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
Yes, it is bad in terms of stack usage. Use “goto” instead.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Jon Anglin”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Monday, December 19, 2005 5:20 PM
Subject: [ntfsd] try, finally question
> I write a lot of code like the following:
>
> __try {
> ExAcquireFastMutex(&lock);
> if (something) {
> …
>__leave;
> } else {
> …
> }
> }
>
> __finally {
> ExReleaseFastMutex(&lock);
> }
>
> I like this because the lock will be freed even if an exception occurs.
> Is this bad for performance and/or stack usage in a filter?
>
> Thanks,
> Jon
>
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
The IFS samples use try/finally in all dispatch routines.
Suggestion is to use try/finally/except wisely (always use if accessing a user
mode buffer or during Cc calls - you DO don’t ya?, no need to use for “simpler”
programming).
ya = you all 
> Yes, it is bad in terms of stack usage. Use “goto” instead.
–
Kind regards, Dejan M.
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.
And don’t forget to wrap calls to MmProbeAndLockPages, MmMapLockedPagesSpecifyCache, etc, etc (who knows what else? no comprehensive list that I can find) with try/except because they throw exceptions.
----- Original Message ----
From: Dejan Maksimovic
To: Windows File Systems Devs Interest List
Sent: Monday, December 19, 2005 14:25:56
Subject: Re: [ntfsd] try, finally question
The IFS samples use try/finally in all dispatch routines.
Suggestion is to use try/finally/except wisely (always use if accessing a user
mode buffer or during Cc calls - you DO don’t ya?, no need to use for “simpler”
programming).
ya = you all
> Yes, it is bad in terms of stack usage. Use “goto” instead.
–
Kind regards, Dejan M.
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.
—
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@yahoo.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Here’s one list of DDIs that raise exceptions:
http://www.osronline.com/article.cfm?article=262. Entirely possible that
there’s more, if so let us know and we’ll add them.
-scott
–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Randy Cook” wrote in message news:xxxxx@ntfsd…
> And don’t forget to wrap calls to MmProbeAndLockPages,
> MmMapLockedPagesSpecifyCache, etc, etc (who knows what else? no
> comprehensive list that I can find) with try/except because they throw
> exceptions.
>
> ----- Original Message ----
> From: Dejan Maksimovic
> To: Windows File Systems Devs Interest List
> Sent: Monday, December 19, 2005 14:25:56
> Subject: Re: [ntfsd] try, finally question
>
>
> The IFS samples use try/finally in all dispatch routines.
> Suggestion is to use try/finally/except wisely (always use if accessing
> a user
> mode buffer or during Cc calls - you DO don’t ya?, no need to use for
> “simpler”
> programming).
>
>
> ya = you all
>
>
>
>> Yes, it is bad in terms of stack usage. Use “goto” instead.
>
> –
> Kind regards, Dejan M.
> 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.
>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@yahoo.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
>
Hi
Just to add, try __finally constructs are SLOWER. I have not done
any performance testing on such constructs, but my observation is based on
the time delay it takes to enter a try _finally block in the debugger (the
slow response is visible).
Q, does viewing the code in the debugger has some variable that add
to the delay of in the try _finally block.
Regards
Faraz Ahmed.
On 12/19/05, Jon Anglin wrote:
>
> I write a lot of code like the following:
>
> __try {
> ExAcquireFastMutex(&lock);
> if (something) {
> …
>__leave;
> } else {
> …
> }
> }
>
> __finally {
> ExReleaseFastMutex(&lock);
> }
>
> I like this because the lock will be freed even if an exception occurs.
> Is this bad for performance and/or stack usage in a filter?
>
> Thanks,
> Jon
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
The list is at least missing some of the obsolete APIs like:
MmMapLockedPages
ExAllocatePoolWithQuota
But, other than that, it has all the ones I know about.
----- Original Message ----
From: Scott Noone
To: Windows File Systems Devs Interest List
Sent: Thursday, December 22, 2005 09:01:56
Subject: Re:[ntfsd] try, finally question
Here’s one list of DDIs that raise exceptions:
http://www.osronline.com/article.cfm?article=262. Entirely possible that
there’s more, if so let us know and we’ll add them.
-scott
–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Randy Cook” wrote in message news:xxxxx@ntfsd…
> And don’t forget to wrap calls to MmProbeAndLockPages,
> MmMapLockedPagesSpecifyCache, etc, etc (who knows what else? no
> comprehensive list that I can find) with try/except because they throw
> exceptions.
>
> ----- Original Message ----
> From: Dejan Maksimovic
> To: Windows File Systems Devs Interest List
> Sent: Monday, December 19, 2005 14:25:56
> Subject: Re: [ntfsd] try, finally question
>
>
> The IFS samples use try/finally in all dispatch routines.
> Suggestion is to use try/finally/except wisely (always use if accessing
> a user
> mode buffer or during Cc calls - you DO don’t ya?, no need to use for
> “simpler”
> programming).
>
>
> ya = you all
>
>
>
>> Yes, it is bad in terms of stack usage. Use “goto” instead.
>
> –
> Kind regards, Dejan M.
> 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.
>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@yahoo.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
>
—
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@yahoo.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
The explanation (I think from Doron?) was that the compiler cannot optimize
within a try/finally block because it could exit anywhere. The results of
that could impact the optimization (or lack thereof) in the rest of the
routine.
Ken
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Faraz Ahmed
Sent: Thursday, December 22, 2005 11:35 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] __try, __finally question
Hi
Just to add, try __finally constructs are SLOWER. I have not done
any performance testing on such constructs, but my observation is based on
the time delay it takes to enter a try _finally block in the debugger (the
slow response is visible).
Q, does viewing the code in the debugger has some variable that add
to the delay of in the try _finally block.
Regards
Faraz Ahmed.
On 12/19/05, Jon Anglin wrote:
I write a lot of code like the following:
__try {
ExAcquireFastMutex(&lock);
if (something) {
…
__leave;
} else {
…
}
}
__finally {
ExReleaseFastMutex(&lock);
}
I like this because the lock will be freed even if an exception
occurs.
Is this bad for performance and/or stack usage in a filter?
Thanks,
Jon
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@gmail.com
To unsubscribe send a blank email to
xxxxx@lists.osr.com
— Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17 You are currently subscribed to
ntfsd as: unknown lmsubst tag argument: ‘’ To unsubscribe send a blank email
to xxxxx@lists.osr.com