What are reasonable stack limits for our drivers on WinXP and Vista?
Thanks,
-Praveen
12KB on 2003 and below, don’t know on Vista
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Praveen Kumar Amritaluru”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Thursday, August 24, 2006 11:05 PM
Subject: [ntdev] What are reasonable stack limits for our drivers on WinXP and
Vista
> What are reasonable stack limits for our drivers on WinXP and Vista?
>
> Thanks,
> -Praveen
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
That’s the maximum stack limit. The stack will be eaten up with I/O
manager code and any other drivers on the stack as well.
In general driver stack usage should be small. If you need large
amounts of memory you should allocate them from pool, either once at
init (and then have a mechanism for safely sharing the buffer) or for
each request.
Avoid recursion and other stack-hogging models if you can help it.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Thursday, August 24, 2006 12:19 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] What are reasonable stack limits for our drivers on
WinXP and Vista
12KB on 2003 and below, don’t know on Vista
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Praveen Kumar Amritaluru”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Thursday, August 24, 2006 11:05 PM
Subject: [ntdev] What are reasonable stack limits for our drivers on
WinXP and Vista
> What are reasonable stack limits for our drivers on WinXP and Vista?
>
> Thanks,
> -Praveen
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
the stack limits have not changed in vista.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
Shatskih
Sent: Thursday, August 24, 2006 12:19 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] What are reasonable stack limits for our drivers on
WinXP and Vista
12KB on 2003 and below, don’t know on Vista
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Praveen Kumar Amritaluru”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Thursday, August 24, 2006 11:05 PM
Subject: [ntdev] What are reasonable stack limits for our drivers on
WinXP and
Vista
> What are reasonable stack limits for our drivers on WinXP and Vista?
>
> Thanks,
> -Praveen
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Peter is correct to correct Maxim. Please do not use 12K of stack in your
driver. However, I will disagree with this statement Peter made:
In general driver stack usage should be small.
It should read “In general driver stack usage should be VERY small.”
You haven’t told us what kind of driver you have. That is an important
piece of information to determine how hard you have to work to be stack
frugal. If it is in the storage stack, please revise the the above
statement to read EXTREMELY small.
The Windows Filesystem team has worked hard to reduce the stack usage of the
filesystems in Vista. Those improvements are not in XP. It is also my
understanding that there has been no effort to reduce the stack usage of I/O
Manager or Win32 in Vista, and they can be almost as piggy as the
filesystems. I’ve seen one dump where the thread in question was doing a
Terminal Server login. Win32 used 8k of the stack before making a
CreateFile call…not bloody likely…
The kernel stack is a limited resource, and while it is possible to
determine how much has been used above you, there is no way to determine how
much is going to be used below you. In my experience, the best you can do
is use as little as possible.
What happens is, a customer has 10 filter drivers, and they’re constantly on
the hairy edge of stack overflow. They add your driver and the system
crashes. Guess who gets blamed? In that situation, it is helpful to do a
kf in windbg (which shows stack usage by call frame) and demonstrate to the
customer that Microsoft drivers are using 8k, random antivirus product is
using 3.9K, and your driver is using 12 bytes. Of course if your driver is
using 1K, they’re right to blame you.
In general use the following rules:
- Use C, not C++, because I’m a well known C bigot, and I don’t know what
C++ does on the stack behind my back. Also, some people think anti-C++
statements make this list “unbearable”, and I enjoy jabbing at the
thin-skinned. - Have a few local scalar local variables. If you need arrays, structures,
etc., don’t put them on the stack. Allocate them from pool. If you need
300 local scalar variables, rethink the meaning of life. - Make your call structure broad, rather than deep.
- If you are not the lowest level driver (few are), make your call to the
next driver as high in your call hierarchy as possible. Don’t call
IoCallDriver 37 levels deep in your driver. - Don’t use recursion.
- You can always go off the deep end and have a single local variable for
each routine, which is a pointer to your local variable structure. I only
recommend you go this far if you ignore #5.
If you haven’t guessed yet, this is a pet peave of mine. The reason is that
it could be my driver, using 12 bytes of stack, that pushes the system over
the limit, where your driver has been using 3k all along. Your fault, I get
blamed. So the short answer to your question is, “As close to zero as
practical.”
- Dan.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Thursday, August 24, 2006 1:40 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] What are reasonable stack limits for our drivers on
WinXP and Vista
That’s the maximum stack limit. The stack will be eaten up with I/O manager
code and any other drivers on the stack as well.
In general driver stack usage should be small. If you need large amounts of
memory you should allocate them from pool, either once at init (and then
have a mechanism for safely sharing the buffer) or for each request.
Avoid recursion and other stack-hogging models if you can help it.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Thursday, August 24, 2006 12:19 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] What are reasonable stack limits for our drivers on
WinXP and Vista
12KB on 2003 and below, don’t know on Vista
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Praveen Kumar Amritaluru”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Thursday, August 24, 2006 11:05 PM
Subject: [ntdev] What are reasonable stack limits for our drivers on WinXP
and Vista
> What are reasonable stack limits for our drivers on WinXP and Vista?
>
> Thanks,
> -Praveen
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
> 2) Have a few local scalar local variables. If you need arrays,
structures,
etc., don’t put them on the stack. Allocate them from pool.
- Use C, not C++
This is the case when elementary C++ (better C, “C with dtors”) might
help a bit.
I wrote a trivial template, allocate in ctor, deallocate in dtor kind of
thing,
that allowed me to replace all my char logBuf[512] - after a BSOD caused
by a stack exhaustion, of course.
This way I don’t eat the stack and, at the same time, deallocations
are automatic as if it were stack-based logBuf’s.
[And no, it is NOT a new discussion of C vs C++.]
On stack limits, from
http://www.microsoft.com/whdc/driver/tips/KMstack.mspx:
“On x86-based platforms, the kernel-mode stack is 12K.
On x64-based platforms, the kernel-mode stack is 24K. (x64-based platforms
include systems with processors using the AMD64 architecture and processors
using the Intel EM64T architecture).
On Itanium-based platforms, the kernel-mode stack is 32K with a 32K backing
store.”
----- Original Message -----
From: “Dan Kyler”
To: “Windows System Software Devs Interest List”
Sent: Thursday, August 24, 2006 9:46 PM
Subject: RE: [ntdev] What are reasonable stack limits for our drivers on
WinXP and Vista
> Peter is correct to correct Maxim. Please do not use 12K of stack in your
> driver. However, I will disagree with this statement Peter made:
>
>>In general driver stack usage should be small.
>
> It should read “In general driver stack usage should be VERY small.”
>
> You haven’t told us what kind of driver you have. That is an important
> piece of information to determine how hard you have to work to be stack
> frugal. If it is in the storage stack, please revise the the above
> statement to read EXTREMELY small.
>
> The Windows Filesystem team has worked hard to reduce the stack usage of
> the
> filesystems in Vista. Those improvements are not in XP. It is also my
> understanding that there has been no effort to reduce the stack usage of
> I/O
> Manager or Win32 in Vista, and they can be almost as piggy as the
> filesystems. I’ve seen one dump where the thread in question was doing a
> Terminal Server login. Win32 used 8k of the stack before making a
> CreateFile call…not bloody likely…
>
> The kernel stack is a limited resource, and while it is possible to
> determine how much has been used above you, there is no way to determine
> how
> much is going to be used below you. In my experience, the best you can do
> is use as little as possible.
>
> What happens is, a customer has 10 filter drivers, and they’re constantly
> on
> the hairy edge of stack overflow. They add your driver and the system
> crashes. Guess who gets blamed? In that situation, it is helpful to do a
> kf in windbg (which shows stack usage by call frame) and demonstrate to
> the
> customer that Microsoft drivers are using 8k, random antivirus product is
> using 3.9K, and your driver is using 12 bytes. Of course if your driver
> is
> using 1K, they’re right to blame you.
>
> In general use the following rules:
> 1) Use C, not C++, because I’m a well known C bigot, and I don’t know what
> C++ does on the stack behind my back. Also, some people think anti-C++
> statements make this list “unbearable”, and I enjoy jabbing at the
> thin-skinned.
> 2) Have a few local scalar local variables. If you need arrays,
> structures,
> etc., don’t put them on the stack. Allocate them from pool. If you need
> 300 local scalar variables, rethink the meaning of life.
> 3) Make your call structure broad, rather than deep.
> 4) If you are not the lowest level driver (few are), make your call to the
> next driver as high in your call hierarchy as possible. Don’t call
> IoCallDriver 37 levels deep in your driver.
> 5) Don’t use recursion.
> 6) You can always go off the deep end and have a single local variable for
> each routine, which is a pointer to your local variable structure. I only
> recommend you go this far if you ignore #5.
>
> If you haven’t guessed yet, this is a pet peave of mine. The reason is
> that
> it could be my driver, using 12 bytes of stack, that pushes the system
> over
> the limit, where your driver has been using 3k all along. Your fault, I
> get
> blamed. So the short answer to your question is, “As close to zero as
> practical.”
>
> - Dan.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
> Sent: Thursday, August 24, 2006 1:40 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] What are reasonable stack limits for our drivers on
> WinXP and Vista
>
>
> That’s the maximum stack limit. The stack will be eaten up with I/O
> manager
> code and any other drivers on the stack as well.
>
> In general driver stack usage should be small. If you need large amounts
> of
> memory you should allocate them from pool, either once at init (and then
> have a mechanism for safely sharing the buffer) or for each request.
>
> Avoid recursion and other stack-hogging models if you can help it.
>
> -p
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
> Sent: Thursday, August 24, 2006 12:19 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] What are reasonable stack limits for our drivers on
> WinXP and Vista
>
>
> 12KB on 2003 and below, don’t know on Vista
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> ----- Original Message -----
> From: “Praveen Kumar Amritaluru”
> Newsgroups: ntdev
> To: “Windows System Software Devs Interest List”
> Sent: Thursday, August 24, 2006 11:05 PM
> Subject: [ntdev] What are reasonable stack limits for our drivers on WinXP
> and Vista
>
>
>> What are reasonable stack limits for our drivers on WinXP and Vista?
>>
>> Thanks,
>> -Praveen
>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>>
>> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
What is the basis/origin for such small stack sizes?
is it a CPU based hardware limitation or is it an arbitrary decision?
-----Original Message-----
From: sh_alex [mailto:xxxxx@comcast.net]
Sent: Thursday, August 24, 2006 10:10 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] What are reasonable stack limits for our drivers on
WinXP and Vista
- Have a few local scalar local variables. If you need arrays,
structures,
etc., don’t put them on the stack. Allocate them from pool.- Use C, not C++
This is the case when elementary C++ (better C, “C with dtors”) might
help a bit.
I wrote a trivial template, allocate in ctor, deallocate in dtor kind of
thing,
that allowed me to replace all my char logBuf[512] - after a BSOD caused
by a stack exhaustion, of course.
This way I don’t eat the stack and, at the same time, deallocations
are automatic as if it were stack-based logBuf’s.
[And no, it is NOT a new discussion of C vs C++.]
On stack limits, from
http://www.microsoft.com/whdc/driver/tips/KMstack.mspx:
“On x86-based platforms, the kernel-mode stack is 12K.
On x64-based platforms, the kernel-mode stack is 24K. (x64-based platforms
include systems with processors using the AMD64 architecture and processors
using the Intel EM64T architecture).
On Itanium-based platforms, the kernel-mode stack is 32K with a 32K backing
store.”
----- Original Message -----
From: “Dan Kyler”
To: “Windows System Software Devs Interest List”
Sent: Thursday, August 24, 2006 9:46 PM
Subject: RE: [ntdev] What are reasonable stack limits for our drivers on
WinXP and Vista
> Peter is correct to correct Maxim. Please do not use 12K of stack in your
> driver. However, I will disagree with this statement Peter made:
>
>>In general driver stack usage should be small.
>
> It should read “In general driver stack usage should be VERY small.”
>
> You haven’t told us what kind of driver you have. That is an important
> piece of information to determine how hard you have to work to be stack
> frugal. If it is in the storage stack, please revise the the above
> statement to read EXTREMELY small.
>
> The Windows Filesystem team has worked hard to reduce the stack usage of
> the
> filesystems in Vista. Those improvements are not in XP. It is also my
> understanding that there has been no effort to reduce the stack usage of
> I/O
> Manager or Win32 in Vista, and they can be almost as piggy as the
> filesystems. I’ve seen one dump where the thread in question was doing a
> Terminal Server login. Win32 used 8k of the stack before making a
> CreateFile call…not bloody likely…
>
> The kernel stack is a limited resource, and while it is possible to
> determine how much has been used above you, there is no way to determine
> how
> much is going to be used below you. In my experience, the best you can do
> is use as little as possible.
>
> What happens is, a customer has 10 filter drivers, and they’re constantly
> on
> the hairy edge of stack overflow. They add your driver and the system
> crashes. Guess who gets blamed? In that situation, it is helpful to do a
> kf in windbg (which shows stack usage by call frame) and demonstrate to
> the
> customer that Microsoft drivers are using 8k, random antivirus product is
> using 3.9K, and your driver is using 12 bytes. Of course if your driver
> is
> using 1K, they’re right to blame you.
>
> In general use the following rules:
> 1) Use C, not C++, because I’m a well known C bigot, and I don’t know what
> C++ does on the stack behind my back. Also, some people think anti-C++
> statements make this list “unbearable”, and I enjoy jabbing at the
> thin-skinned.
> 2) Have a few local scalar local variables. If you need arrays,
> structures,
> etc., don’t put them on the stack. Allocate them from pool. If you need
> 300 local scalar variables, rethink the meaning of life.
> 3) Make your call structure broad, rather than deep.
> 4) If you are not the lowest level driver (few are), make your call to the
> next driver as high in your call hierarchy as possible. Don’t call
> IoCallDriver 37 levels deep in your driver.
> 5) Don’t use recursion.
> 6) You can always go off the deep end and have a single local variable for
> each routine, which is a pointer to your local variable structure. I only
> recommend you go this far if you ignore #5.
>
> If you haven’t guessed yet, this is a pet peave of mine. The reason is
> that
> it could be my driver, using 12 bytes of stack, that pushes the system
> over
> the limit, where your driver has been using 3k all along. Your fault, I
> get
> blamed. So the short answer to your question is, “As close to zero as
> practical.”
>
> - Dan.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
> Sent: Thursday, August 24, 2006 1:40 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] What are reasonable stack limits for our drivers on
> WinXP and Vista
>
>
> That’s the maximum stack limit. The stack will be eaten up with I/O
> manager
> code and any other drivers on the stack as well.
>
> In general driver stack usage should be small. If you need large amounts
> of
> memory you should allocate them from pool, either once at init (and then
> have a mechanism for safely sharing the buffer) or for each request.
>
> Avoid recursion and other stack-hogging models if you can help it.
>
> -p
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
> Sent: Thursday, August 24, 2006 12:19 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] What are reasonable stack limits for our drivers on
> WinXP and Vista
>
>
> 12KB on 2003 and below, don’t know on Vista
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> ----- Original Message -----
> From: “Praveen Kumar Amritaluru”
> Newsgroups: ntdev
> To: “Windows System Software Devs Interest List”
> Sent: Thursday, August 24, 2006 11:05 PM
> Subject: [ntdev] What are reasonable stack limits for our drivers on WinXP
> and Vista
>
>
>> What are reasonable stack limits for our drivers on WinXP and Vista?
>>
>> Thanks,
>> -Praveen
>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>>
>> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
From the link below:
Each thread is allocated a kernel-mode stack, so increasing the size of
the stack by even a small amount would drastically increase the memory
footprint of the system. Therefore, the size of the kernel-mode stack on
a given platform is set by the operating system and cannot be modified.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Asa Yeamans
Sent: Thursday, August 24, 2006 10:09 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] What are reasonable stack limits for our drivers on
WinXP and Vista
What is the basis/origin for such small stack sizes?
is it a CPU based hardware limitation or is it an arbitrary decision?
-----Original Message-----
From: sh_alex [mailto:xxxxx@comcast.net]
Sent: Thursday, August 24, 2006 10:10 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] What are reasonable stack limits for our drivers on
WinXP and Vista
- Have a few local scalar local variables. If you need arrays,
structures,
etc., don’t put them on the stack. Allocate them from pool.- Use C, not C++
This is the case when elementary C++ (better C, “C with dtors”) might
help a bit.
I wrote a trivial template, allocate in ctor, deallocate in dtor kind of
thing,
that allowed me to replace all my char logBuf[512] - after a BSOD caused
by a stack exhaustion, of course.
This way I don’t eat the stack and, at the same time, deallocations
are automatic as if it were stack-based logBuf’s.
[And no, it is NOT a new discussion of C vs C++.]
On stack limits, from
http://www.microsoft.com/whdc/driver/tips/KMstack.mspx:
“On x86-based platforms, the kernel-mode stack is 12K.
On x64-based platforms, the kernel-mode stack is 24K. (x64-based
platforms
include systems with processors using the AMD64 architecture and
processors
using the Intel EM64T architecture).
On Itanium-based platforms, the kernel-mode stack is 32K with a 32K
backing
store.”
----- Original Message -----
From: “Dan Kyler”
To: “Windows System Software Devs Interest List”
Sent: Thursday, August 24, 2006 9:46 PM
Subject: RE: [ntdev] What are reasonable stack limits for our drivers on
WinXP and Vista
> Peter is correct to correct Maxim. Please do not use 12K of stack in
your
> driver. However, I will disagree with this statement Peter made:
>
>>In general driver stack usage should be small.
>
> It should read “In general driver stack usage should be VERY small.”
>
> You haven’t told us what kind of driver you have. That is an
important
> piece of information to determine how hard you have to work to be
stack
> frugal. If it is in the storage stack, please revise the the above
> statement to read EXTREMELY small.
>
> The Windows Filesystem team has worked hard to reduce the stack usage
of
> the
> filesystems in Vista. Those improvements are not in XP. It is also
my
> understanding that there has been no effort to reduce the stack usage
of
> I/O
> Manager or Win32 in Vista, and they can be almost as piggy as the
> filesystems. I’ve seen one dump where the thread in question was
doing a
> Terminal Server login. Win32 used 8k of the stack before making a
> CreateFile call…not bloody likely…
>
> The kernel stack is a limited resource, and while it is possible to
> determine how much has been used above you, there is no way to
determine
> how
> much is going to be used below you. In my experience, the best you
can do
> is use as little as possible.
>
> What happens is, a customer has 10 filter drivers, and they’re
constantly
> on
> the hairy edge of stack overflow. They add your driver and the system
> crashes. Guess who gets blamed? In that situation, it is helpful to
do a
> kf in windbg (which shows stack usage by call frame) and demonstrate
to
> the
> customer that Microsoft drivers are using 8k, random antivirus product
is
> using 3.9K, and your driver is using 12 bytes. Of course if your
driver
> is
> using 1K, they’re right to blame you.
>
> In general use the following rules:
> 1) Use C, not C++, because I’m a well known C bigot, and I don’t know
what
> C++ does on the stack behind my back. Also, some people think
anti-C++
> statements make this list “unbearable”, and I enjoy jabbing at the
> thin-skinned.
> 2) Have a few local scalar local variables. If you need arrays,
> structures,
> etc., don’t put them on the stack. Allocate them from pool. If you
need
> 300 local scalar variables, rethink the meaning of life.
> 3) Make your call structure broad, rather than deep.
> 4) If you are not the lowest level driver (few are), make your call to
the
> next driver as high in your call hierarchy as possible. Don’t call
> IoCallDriver 37 levels deep in your driver.
> 5) Don’t use recursion.
> 6) You can always go off the deep end and have a single local variable
for
> each routine, which is a pointer to your local variable structure. I
only
> recommend you go this far if you ignore #5.
>
> If you haven’t guessed yet, this is a pet peave of mine. The reason
is
> that
> it could be my driver, using 12 bytes of stack, that pushes the system
> over
> the limit, where your driver has been using 3k all along. Your fault,
I
> get
> blamed. So the short answer to your question is, “As close to zero as
> practical.”
>
> - Dan.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
> Sent: Thursday, August 24, 2006 1:40 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] What are reasonable stack limits for our drivers
on
> WinXP and Vista
>
>
> That’s the maximum stack limit. The stack will be eaten up with I/O
> manager
> code and any other drivers on the stack as well.
>
> In general driver stack usage should be small. If you need large
amounts
> of
> memory you should allocate them from pool, either once at init (and
then
> have a mechanism for safely sharing the buffer) or for each request.
>
> Avoid recursion and other stack-hogging models if you can help it.
>
> -p
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
Shatskih
> Sent: Thursday, August 24, 2006 12:19 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] What are reasonable stack limits for our drivers
on
> WinXP and Vista
>
>
> 12KB on 2003 and below, don’t know on Vista
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> ----- Original Message -----
> From: “Praveen Kumar Amritaluru”
> Newsgroups: ntdev
> To: “Windows System Software Devs Interest List”
> Sent: Thursday, August 24, 2006 11:05 PM
> Subject: [ntdev] What are reasonable stack limits for our drivers on
WinXP
> and Vista
>
>
>> What are reasonable stack limits for our drivers on WinXP and Vista?
>>
>> Thanks,
>> -Praveen
>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>>
>> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
It’s mostly about (the lack of) resources.
Remember three things about kernel stacks:
1 - Every thread in the system needs a kernel stack.
2 - Every thread’s kernel stack must be resident (locked in physical
memory) unless the thread is waiting on something or suspended
3 - Every thread’s stack is carved out of the shared kernel virtual
address space, which is limited to 2 GB (sometimes 1GB) on x86 machines.
If every thread has a 1MB stack (like in user-mode) in the shared KVA
you can see how you could quickly run out of room. KVA is crowded
enough with 12KB stacks. And for every running thread you’d need to
have the memory allocated as well, so that’s a lot of physical memory
dedicated to very limited use.
There’s some philosophy in there too, but like most kernel limitations I
think it’s mostly about managing the scarcity of resources.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Asa Yeamans
Sent: Thursday, August 24, 2006 10:09 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] What are reasonable stack limits for our drivers on
WinXP and Vista
What is the basis/origin for such small stack sizes?
is it a CPU based hardware limitation or is it an arbitrary decision?
-----Original Message-----
From: sh_alex [mailto:xxxxx@comcast.net]
Sent: Thursday, August 24, 2006 10:10 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] What are reasonable stack limits for our drivers on
WinXP and Vista
- Have a few local scalar local variables. If you need arrays,
structures, etc., don’t put them on the stack. Allocate them from
pool.- Use C, not C++
This is the case when elementary C++ (better C, “C with dtors”) might
help a bit.
I wrote a trivial template, allocate in ctor, deallocate in dtor kind of
thing, that allowed me to replace all my char logBuf[512] - after a BSOD
caused by a stack exhaustion, of course.
This way I don’t eat the stack and, at the same time, deallocations are
automatic as if it were stack-based logBuf’s.
[And no, it is NOT a new discussion of C vs C++.]
On stack limits, from
http://www.microsoft.com/whdc/driver/tips/KMstack.mspx:
“On x86-based platforms, the kernel-mode stack is 12K.
On x64-based platforms, the kernel-mode stack is 24K. (x64-based
platforms include systems with processors using the AMD64 architecture
and processors using the Intel EM64T architecture).
On Itanium-based platforms, the kernel-mode stack is 32K with a 32K
backing store.”
----- Original Message -----
From: “Dan Kyler”
To: “Windows System Software Devs Interest List”
Sent: Thursday, August 24, 2006 9:46 PM
Subject: RE: [ntdev] What are reasonable stack limits for our drivers on
WinXP and Vista
> Peter is correct to correct Maxim. Please do not use 12K of stack in
> your driver. However, I will disagree with this statement Peter made:
>
>>In general driver stack usage should be small.
>
> It should read “In general driver stack usage should be VERY small.”
>
> You haven’t told us what kind of driver you have. That is an
> important piece of information to determine how hard you have to work
> to be stack frugal. If it is in the storage stack, please revise the
> the above statement to read EXTREMELY small.
>
> The Windows Filesystem team has worked hard to reduce the stack usage
> of the filesystems in Vista. Those improvements are not in XP. It is
> also my understanding that there has been no effort to reduce the
> stack usage of I/O Manager or Win32 in Vista, and they can be almost
> as piggy as the filesystems. I’ve seen one dump where the thread in
> question was doing a Terminal Server login. Win32 used 8k of the
> stack before making a CreateFile call…not bloody likely…
>
> The kernel stack is a limited resource, and while it is possible to
> determine how much has been used above you, there is no way to
> determine how much is going to be used below you. In my experience,
> the best you can do is use as little as possible.
>
> What happens is, a customer has 10 filter drivers, and they’re
> constantly on the hairy edge of stack overflow. They add your driver
> and the system crashes. Guess who gets blamed? In that situation, it
> is helpful to do a kf in windbg (which shows stack usage by call
> frame) and demonstrate to the customer that Microsoft drivers are
> using 8k, random antivirus product is using 3.9K, and your driver is
> using 12 bytes. Of course if your driver is using 1K, they’re right
> to blame you.
>
> In general use the following rules:
> 1) Use C, not C++, because I’m a well known C bigot, and I don’t know
> what
> C++ does on the stack behind my back. Also, some people think
> C++ anti-C++
> statements make this list “unbearable”, and I enjoy jabbing at the
> thin-skinned.
> 2) Have a few local scalar local variables. If you need arrays,
> structures, etc., don’t put them on the stack. Allocate them from
> pool. If you need 300 local scalar variables, rethink the meaning of
> life.
> 3) Make your call structure broad, rather than deep.
> 4) If you are not the lowest level driver (few are), make your call to
> the next driver as high in your call hierarchy as possible. Don’t
> call IoCallDriver 37 levels deep in your driver.
> 5) Don’t use recursion.
> 6) You can always go off the deep end and have a single local variable
> for each routine, which is a pointer to your local variable structure.
> I only recommend you go this far if you ignore #5.
>
> If you haven’t guessed yet, this is a pet peave of mine. The reason
> is that it could be my driver, using 12 bytes of stack, that pushes
> the system over the limit, where your driver has been using 3k all
> along. Your fault, I get blamed. So the short answer to your
> question is, “As close to zero as practical.”
>
> - Dan.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
> Sent: Thursday, August 24, 2006 1:40 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] What are reasonable stack limits for our drivers
> on WinXP and Vista
>
>
> That’s the maximum stack limit. The stack will be eaten up with I/O
> manager code and any other drivers on the stack as well.
>
> In general driver stack usage should be small. If you need large
> amounts of memory you should allocate them from pool, either once at
> init (and then have a mechanism for safely sharing the buffer) or for
> each request.
>
> Avoid recursion and other stack-hogging models if you can help it.
>
> -p
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
> Shatskih
> Sent: Thursday, August 24, 2006 12:19 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] What are reasonable stack limits for our drivers
> on WinXP and Vista
>
>
> 12KB on 2003 and below, don’t know on Vista
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> ----- Original Message -----
> From: “Praveen Kumar Amritaluru”
> Newsgroups: ntdev
> To: “Windows System Software Devs Interest List”
> Sent: Thursday, August 24, 2006 11:05 PM
> Subject: [ntdev] What are reasonable stack limits for our drivers on
> WinXP and Vista
>
>
>> What are reasonable stack limits for our drivers on WinXP and Vista?
>>
>> Thanks,
>> -Praveen
>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>>
>> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
First of all,
I agree with Dan Kyler recommendations (Thu, 24 Aug 2006 19:46:29)
besides C++ using.
Dan,
It is not the problem to understand how bytes are allocated by every C++
call. I’m not C++ fan, but I not see any reason to be “C bigot”… 
Second.
As Maxim noted, the stack size is 12KB. Ok,
But I guess, the discursion is not correct without understanding how
this stack is used (by kernel and other drivers) in the different
situation BEFOR your driver is called.
Only few of situations:
- 3 different levels: passive, DPC and IRQ. Are the stack (size) same
for them? - NDIS driver(s). How NDIS uses stack before calling the driver? Pay
attention, NDIS has the different driver types and call types for them
too. - Filter drivers. Are they working on the same stack? (NDIS
intermediate is also specific filter, but in the other environment…) - Antivirus…
- File system drivers (I don’t know specific for them)…
As for me, I did not meet stack overflow in my drivers such as even did
sure before this discursion, the stack grows auto…
Stack usage usage in a DPC or ISR should be as minimal as possible
because you are running in a randrom thread context whose stack usage
you cannot control. There could be very little stack left or there
could be nearly the entire 12K. Either way, use as little as possible.
FS or FS filters are usually near the top of the call stack and start
out with a lot of stack space, but remember that the FS can be recursive
on the stack *AND* the rest of the storage stack shares that 12K.
Again, be as minimal as possible in your stack usage.
The basic rule is to always use as little stack as possible. It doesn’t
matter what the driver model is or where you are in the stack.
d
– I can spell, I just can’t type.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Grabelkovsky,
Michael
Sent: Sunday, August 27, 2006 12:51 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] What are reasonable stack limits for our drivers on
WinXP and Vista
First of all,
I agree with Dan Kyler recommendations (Thu, 24 Aug 2006 19:46:29)
besides C++ using.
Dan,
It is not the problem to understand how bytes are allocated by every C++
call. I’m not C++ fan, but I not see any reason to be “C bigot”…
Second.
As Maxim noted, the stack size is 12KB. Ok, But I guess, the discursion
is not correct without understanding how this stack is used (by kernel
and other drivers) in the different situation BEFOR your driver is
called.
Only few of situations:
- 3 different levels: passive, DPC and IRQ. Are the stack (size) same
for them? - NDIS driver(s). How NDIS uses stack before calling the driver? Pay
attention, NDIS has the different driver types and call types for them
too. - Filter drivers. Are they working on the same stack? (NDIS
intermediate is also specific filter, but in the other environment…) - Antivirus…
- File system drivers (I don’t know specific for them)…
As for me, I did not meet stack overflow in my drivers such as even did
sure before this discursion, the stack grows auto…
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Hi,
I think its graphics driver, though not sure.
I got this question from a colleague in my company…
He is running some static analysis tools which seems to be adding/putting
lots
of varaibles on stack. I dont have much details on his tests.
I have passed on the information to him.
Thanks,
“Dan Kyler” wrote in message news:xxxxx@ntdev…
> Peter is correct to correct Maxim. Please do not use 12K of stack in your
> driver. However, I will disagree with this statement Peter made:
>
>>In general driver stack usage should be small.
>
> It should read “In general driver stack usage should be VERY small.”
>
> You haven’t told us what kind of driver you have. That is an important
> piece of information to determine how hard you have to work to be stack
> frugal. If it is in the storage stack, please revise the the above
> statement to read EXTREMELY small.
>
> The Windows Filesystem team has worked hard to reduce the stack usage of
> the
> filesystems in Vista. Those improvements are not in XP. It is also my
> understanding that there has been no effort to reduce the stack usage of
> I/O
> Manager or Win32 in Vista, and they can be almost as piggy as the
> filesystems. I’ve seen one dump where the thread in question was doing a
> Terminal Server login. Win32 used 8k of the stack before making a
> CreateFile call…not bloody likely…
>
> The kernel stack is a limited resource, and while it is possible to
> determine how much has been used above you, there is no way to determine
> how
> much is going to be used below you. In my experience, the best you can do
> is use as little as possible.
>
> What happens is, a customer has 10 filter drivers, and they’re constantly
> on
> the hairy edge of stack overflow. They add your driver and the system
> crashes. Guess who gets blamed? In that situation, it is helpful to do a
> kf in windbg (which shows stack usage by call frame) and demonstrate to
> the
> customer that Microsoft drivers are using 8k, random antivirus product is
> using 3.9K, and your driver is using 12 bytes. Of course if your driver
> is
> using 1K, they’re right to blame you.
>
> In general use the following rules:
> 1) Use C, not C++, because I’m a well known C bigot, and I don’t know what
> C++ does on the stack behind my back. Also, some people think anti-C++
> statements make this list “unbearable”, and I enjoy jabbing at the
> thin-skinned.
> 2) Have a few local scalar local variables. If you need arrays,
> structures,
> etc., don’t put them on the stack. Allocate them from pool. If you need
> 300 local scalar variables, rethink the meaning of life.
> 3) Make your call structure broad, rather than deep.
> 4) If you are not the lowest level driver (few are), make your call to the
> next driver as high in your call hierarchy as possible. Don’t call
> IoCallDriver 37 levels deep in your driver.
> 5) Don’t use recursion.
> 6) You can always go off the deep end and have a single local variable for
> each routine, which is a pointer to your local variable structure. I only
> recommend you go this far if you ignore #5.
>
> If you haven’t guessed yet, this is a pet peave of mine. The reason is
> that
> it could be my driver, using 12 bytes of stack, that pushes the system
> over
> the limit, where your driver has been using 3k all along. Your fault, I
> get
> blamed. So the short answer to your question is, “As close to zero as
> practical.”
>
> - Dan.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
> Sent: Thursday, August 24, 2006 1:40 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] What are reasonable stack limits for our drivers on
> WinXP and Vista
>
>
> That’s the maximum stack limit. The stack will be eaten up with I/O
> manager
> code and any other drivers on the stack as well.
>
> In general driver stack usage should be small. If you need large amounts
> of
> memory you should allocate them from pool, either once at init (and then
> have a mechanism for safely sharing the buffer) or for each request.
>
> Avoid recursion and other stack-hogging models if you can help it.
>
> -p
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
> Sent: Thursday, August 24, 2006 12:19 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] What are reasonable stack limits for our drivers on
> WinXP and Vista
>
>
> 12KB on 2003 and below, don’t know on Vista
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> ----- Original Message -----
> From: “Praveen Kumar Amritaluru”
> Newsgroups: ntdev
> To: “Windows System Software Devs Interest List”
> Sent: Thursday, August 24, 2006 11:05 PM
> Subject: [ntdev] What are reasonable stack limits for our drivers on WinXP
> and Vista
>
>
>> What are reasonable stack limits for our drivers on WinXP and Vista?
>>
>> Thanks,
>> -Praveen
>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>>
>> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
Could someone clarify, KM has a 12k stack size, but the system graphic
drivers sit at 20k right?
m.
Praveen Kumar Amritaluru wrote:
Hi,
I think its graphics driver, though not sure.
I got this question from a colleague in my company…
He is running some static analysis tools which seems to be adding/putting
lots
of varaibles on stack. I dont have much details on his tests.I have passed on the information to him.
Thanks,
“Dan Kyler” wrote in message news:xxxxx@ntdev…
>
>
>>Peter is correct to correct Maxim. Please do not use 12K of stack in your
>>driver. However, I will disagree with this statement Peter made:
>>
>>
>>
>>>In general driver stack usage should be small.
>>>
>>>
>>It should read “In general driver stack usage should be VERY small.”
>>
>>You haven’t told us what kind of driver you have. That is an important
>>piece of information to determine how hard you have to work to be stack
>>frugal. If it is in the storage stack, please revise the the above
>>statement to read EXTREMELY small.
>>
>>The Windows Filesystem team has worked hard to reduce the stack usage of
>>the
>>filesystems in Vista. Those improvements are not in XP. It is also my
>>understanding that there has been no effort to reduce the stack usage of
>>I/O
>>Manager or Win32 in Vista, and they can be almost as piggy as the
>>filesystems. I’ve seen one dump where the thread in question was doing a
>>Terminal Server login. Win32 used 8k of the stack before making a
>>CreateFile call…not bloody likely…
>>
>>The kernel stack is a limited resource, and while it is possible to
>>determine how much has been used above you, there is no way to determine
>>how
>>much is going to be used below you. In my experience, the best you can do
>>is use as little as possible.
>>
>>What happens is, a customer has 10 filter drivers, and they’re constantly
>>on
>>the hairy edge of stack overflow. They add your driver and the system
>>crashes. Guess who gets blamed? In that situation, it is helpful to do a
>>kf in windbg (which shows stack usage by call frame) and demonstrate to
>>the
>>customer that Microsoft drivers are using 8k, random antivirus product is
>>using 3.9K, and your driver is using 12 bytes. Of course if your driver
>>is
>>using 1K, they’re right to blame you.
>>
>>In general use the following rules:
>>1) Use C, not C++, because I’m a well known C bigot, and I don’t know what
>>C++ does on the stack behind my back. Also, some people think anti-C++
>>statements make this list “unbearable”, and I enjoy jabbing at the
>>thin-skinned.
>>2) Have a few local scalar local variables. If you need arrays,
>>structures,
>>etc., don’t put them on the stack. Allocate them from pool. If you need
>>300 local scalar variables, rethink the meaning of life.
>>3) Make your call structure broad, rather than deep.
>>4) If you are not the lowest level driver (few are), make your call to the
>>next driver as high in your call hierarchy as possible. Don’t call
>>IoCallDriver 37 levels deep in your driver.
>>5) Don’t use recursion.
>>6) You can always go off the deep end and have a single local variable for
>>each routine, which is a pointer to your local variable structure. I only
>>recommend you go this far if you ignore #5.
>>
>>If you haven’t guessed yet, this is a pet peave of mine. The reason is
>>that
>>it could be my driver, using 12 bytes of stack, that pushes the system
>>over
>>the limit, where your driver has been using 3k all along. Your fault, I
>>get
>>blamed. So the short answer to your question is, “As close to zero as
>>practical.”
>>
>>- Dan.
>>
>>-----Original Message-----
>>From: xxxxx@lists.osr.com
>>[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
>>Sent: Thursday, August 24, 2006 1:40 PM
>>To: Windows System Software Devs Interest List
>>Subject: RE: [ntdev] What are reasonable stack limits for our drivers on
>>WinXP and Vista
>>
>>
>>That’s the maximum stack limit. The stack will be eaten up with I/O
>>manager
>>code and any other drivers on the stack as well.
>>
>>In general driver stack usage should be small. If you need large amounts
>>of
>>memory you should allocate them from pool, either once at init (and then
>>have a mechanism for safely sharing the buffer) or for each request.
>>
>>Avoid recursion and other stack-hogging models if you can help it.
>>
>>-p
>>
>>-----Original Message-----
>>From: xxxxx@lists.osr.com
>>[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
>>Sent: Thursday, August 24, 2006 12:19 PM
>>To: Windows System Software Devs Interest List
>>Subject: Re: [ntdev] What are reasonable stack limits for our drivers on
>>WinXP and Vista
>>
>>
>> 12KB on 2003 and below, don’t know on Vista
>>
>>Maxim Shatskih, Windows DDK MVP
>>StorageCraft Corporation
>>xxxxx@storagecraft.com
>>http://www.storagecraft.com
>>
>>----- Original Message -----
>>From: “Praveen Kumar Amritaluru”
>>Newsgroups: ntdev
>>To: “Windows System Software Devs Interest List”
>>Sent: Thursday, August 24, 2006 11:05 PM
>>Subject: [ntdev] What are reasonable stack limits for our drivers on WinXP
>>and Vista
>>
>>
>>
>>
>>>What are reasonable stack limits for our drivers on WinXP and Vista?
>>>
>>>Thanks,
>>>-Praveen
>>>
>>>
>>>
>>>—
>>>Questions? First check the Kernel Driver FAQ at
>>>
>>>
>>http://www.osronline.com/article.cfm?id=256
>>
>>
>>>To unsubscribe, visit the List Server section of OSR Online at
>>>
>>>
>>http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>>—
>>Questions? First check the Kernel Driver FAQ at
>>http://www.osronline.com/article.cfm?id=256
>>
>>To unsubscribe, visit the List Server section of OSR Online at
>>http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>>—
>>Questions? First check the Kernel Driver FAQ at
>>http://www.osronline.com/article.cfm?id=256
>>
>>To unsubscribe, visit the List Server section of OSR Online at
>>http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>>
>>
>
>
>
>—
>Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
>To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
>
>
I heartily agree with Doron’s point that stack usage should be kept to a minimum.
But in the interest of detailed technical correctness, note that for the last few OS releases DPCs have actually run on their OWN stack – a dedicated DPC stack. I believe this was introduced in S03, but it might have started in XP.
Peter
OSR
It’s older than that on the RISC platforms. Most of them had their own DPC
stacks from the beginning.
- Jake
wrote in message news:xxxxx@ntdev…
>
>
> I heartily agree with Doron’s point that stack usage should be kept to a
> minimum.
>
> But in the interest of detailed technical correctness, note that for the
> last few OS releases DPCs have actually run on their OWN stack – a
> dedicated DPC stack. I believe this was introduced in S03, but it might
> have started in XP.
>
> Peter
> OSR
>
>
“sh_alex” wrote in message news:xxxxx@ntdev…
> On stack limits, from http://www.microsoft.com/whdc/driver/tips/KMstack.mspx:
> “On x86-based platforms, the kernel-mode stack is 12K.
> On x64-based platforms, the kernel-mode stack is 24K. (x64-based platforms include systems with processors using the AMD64
> architecture and processors using the Intel EM64T architecture).
> On Itanium-based platforms, the kernel-mode stack is 32K with a 32K backing store.”
Given the previously discussed reasons why kernel stacks are small,
these 64-bit systems should be real RAM hogs - they must have
lot of committed physical RAM for all these stacks, not just virtual space ?
–PA
> But in the interest of detailed technical correctness, note that for the last
few OS
releases DPCs have actually run on their OWN stack – a dedicated DPC stack.
I believe this was introduced in S03, but it might have started in XP.
I think it is since some SPs for w2k, if not w2k itself.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Pavel A. wrote:
“sh_alex” wrote in message news:xxxxx@ntdev…
>
>
>>On stack limits, from http://www.microsoft.com/whdc/driver/tips/KMstack.mspx:
>>“On x86-based platforms, the kernel-mode stack is 12K.
>>On x64-based platforms, the kernel-mode stack is 24K. (x64-based platforms include systems with processors using the AMD64
>>architecture and processors using the Intel EM64T architecture).
>>On Itanium-based platforms, the kernel-mode stack is 32K with a 32K backing store.”
>>
>>
>
>Given the previously discussed reasons why kernel stacks are small,
>these 64-bit systems should be real RAM hogs - they must have
>lot of committed physical RAM for all these stacks, not just virtual space ?
>
>
Apparently, about twice as much. But, remember that you’re talking
about K bytes here. It is an insignificant amount of memory. My
machine has about 500 active threads. So, we’re talking about the
difference between 6MB and 12MB.
Now, your statement that “these 64-bit systems should be real RAM hogs”
is quite correct, but kernel stacks aren’t the reason…
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
“Tim Roberts” wrote in message news:xxxxx@ntdev…
>>Given the previously discussed reasons why kernel stacks are small,
>>these 64-bit systems should be real RAM hogs - they must have
>>lot of committed physical RAM for all these stacks, not just virtual space ?
>>
>
> Apparently, about twice as much. But, remember that you’re talking
> about K bytes here. It is an insignificant amount of memory. My
> machine has about 500 active threads. So, we’re talking about the
> difference between 6MB and 12MB.
>
> Now, your statement that “these 64-bit systems should be real RAM hogs”
> is quite correct, but kernel stacks aren’t the reason…
Then, if we’re takling about only 6 MB - ok let it be 20 MB - of a 1 GB kernel
space - why not to double kernel stacks on x86?
–PA
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
Pavel A. wrote:
“Tim Roberts” wrote in message news:xxxxx@ntdev…
>
>
>>>Given the previously discussed reasons why kernel stacks are small,
>>>these 64-bit systems should be real RAM hogs - they must have
>>>lot of committed physical RAM for all these stacks, not just virtual space ?
>>>
>>>
>>Apparently, about twice as much. But, remember that you’re talking
>>about K bytes here. It is an insignificant amount of memory. My
>>machine has about 500 active threads. So, we’re talking about the
>>difference between 6MB and 12MB.
>>
>>Now, your statement that “these 64-bit systems should be real RAM hogs”
>>is quite correct, but kernel stacks aren’t the reason…
>>
>>
>
>Then, if we’re takling about only 6 MB - ok let it be 20 MB - of a 1 GB kernel
>space - why not to double kernel stacks on x86?
>
>
Inertia, probably. Kernel stacks NEED to double on 64-bit architectures
because each stack push is twice as wide. 10 pointers in x64 take twice
the space of 10 pointers in x86.
But overall, there just doesn’t seem to be an overwhelming demand.
There has to be SOME limit, and those of us who write drivers have
learned to fit within the existing (small) limit.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.