Maximum stack memory

NTDEV
1

Hi,
I am developing an user mode applicaiton with the help of DDK checked build
in windows XP professional. In this program when I try to allocate memoty in
stack using

unsigned char buff[2048*64];

it is throwing a runtime exception “stack overflow”.

Is there any specific limitation on maximum memory that can be allocated in
stack? can find this limit?

Thanks,
Lloyd

Scanned and protected by Email scanner

2

This newsgroup is for developing drivers. The maximum that can allocated on
the stack is rather large, but your method for doing so should not work and
is not a good programming practice. Stacks are grown one page at a time.

“Lloyd” wrote in message news:xxxxx@ntdev…
> Hi,
> I am developing an user mode applicaiton with the help of DDK checked
> build in windows XP professional. In this program when I try to allocate
> memoty in stack using
>
> unsigned char buff[2048*64];
>
> it is throwing a runtime exception “stack overflow”.
>
> Is there any specific limitation on maximum memory that can be allocated
> in stack? can find this limit?
>
> Thanks,
> Lloyd
>
>
> ______________________________________
> Scanned and protected by Email scanner
>

3

The limit changes from release to release, but 32 pages on the stack is a bit excessive regardless of how much available stack there is.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Lloyd
Sent: Tuesday, December 08, 2009 10:23 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Maximum stack memory

Hi,
I am developing an user mode applicaiton with the help of DDK checked build
in windows XP professional. In this program when I try to allocate memoty in
stack using

unsigned char buff[2048*64];

it is throwing a runtime exception “stack overflow”.

Is there any specific limitation on maximum memory that can be allocated in
stack? can find this limit?

Thanks,
Lloyd

Scanned and protected by Email scanner

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

4

>

This newsgroup is for developing drivers. The maximum that can
allocated on
the stack is rather large, but your method for doing so should not
work and
is not a good programming practice. Stacks are grown one page at a
time.

There is no hard and fast rule though is there? I seem to remember
asking the question a while back… I’d just discovered that a hard hang
I was experiencing (even the debugger couldn’t break into it) was due to
declaring a large array on the stack in one of the scsiport routines,
and it would crash most of the time on resume from hibernation.

James

5

> unsigned char buff[2048*64];

Bad idea, use malloc or operator new or VirtualAlloc instead.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

6

>I was experiencing (even the debugger couldn’t break into it) was due to

declaring a large array on the stack in one of the scsiport routines,

In kernel mode the stack size is 12K on the x86 and 24K on the x64 (modolo
some special cases where “large stacks” are used). Overflowing a kernel
stack causes a double fault do to the guard page at the end, so you should
have received a crash.

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“James Harper” wrote in message
news:xxxxx@ntdev…
>
> This newsgroup is for developing drivers. The maximum that can
allocated on
> the stack is rather large, but your method for doing so should not
work and
> is not a good programming practice. Stacks are grown one page at a
time.
>

There is no hard and fast rule though is there? I seem to remember
asking the question a while back… I’d just discovered that a hard hang
I was experiencing (even the debugger couldn’t break into it) was due to
declaring a large array on the stack in one of the scsiport routines,
and it would crash most of the time on resume from hibernation.

James

7

Lloyd wrote:

Hi,
I am developing an user mode applicaiton with the help of DDK checked
build in windows XP professional. In this program when I try to
allocate memoty in stack using

unsigned char buff[2048*64];

it is throwing a runtime exception “stack overflow”.

Is there any specific limitation on maximum memory that can be
allocated in stack? can find this limit?

It might be useful to go over how stack allocation is done. The typical
application has a stack “allocation” of 4k bytes, and a stack “reserve”
of 1MB. (Those are parameters in the PE header that can be set in the
linker.) It doesn’t allocate a full megabyte right off the bat and tie
it up forever; since most programs don’t use that much, it would waste
working set pages. Instead, they just allocate one page, and put the
stack pointer at the end of it. The rest of the 1MB is left unassigned.

When you touch memory below that 4k allocated space, it triggers a page
fault. Only then does the system allocate another real page of memory
and continue on.

This scheme works even if you jump pages. So, if you touch memory 12k
bytes below the current stack pointer, it should allocate the three
pages in between. Because of that, I’m a little surprised that you got
this error, unless you were already near your 1MB reservation.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

8

> >I was experiencing (even the debugger couldn’t break into it) was due
to

>declaring a large array on the stack in one of the scsiport routines,

In kernel mode the stack size is 12K on the x86 and 24K on the x64
(modolo
some special cases where “large stacks” are used). Overflowing a
kernel
stack causes a double fault do to the guard page at the end, so you
should
have received a crash.

That’s what had me stumped… I was looking for a place where my code
could cause a tight loop at DIRQL, but even that should be break-in-able
from the debugger. It wasn’t until I did some quick calculations and saw
that I was allocating something like 10K on the stack that I got to
thinking that I was approaching things the wrong way.

James

9

I have modified the code to very short one as shown below

int __cdecl main()
{
unsigned char buff[(1024*243)+880];
return 0;
}

No header files included. This is the maximum limit I am able to alocate in
stack. If I try to allocate one more byte it will crash!. I would like to
know the reason (I am convinced that this is not a good practive, just
wanted to know…)

Thanks,
Lloyd

This scheme works even if you jump pages. So, if you touch memory 12k
bytes below the current stack pointer, it should allocate the three
pages in between. Because of that, I’m a little surprised that you got
this error, unless you were already near your 1MB reservation.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Scanned and protected by Email scanner

10

Did you happen to look at the generated code either in a debugger or code
listing?

I ask only to understand if you (and we!) can trust that this 5 lines of
code is actually generating exactly the thing we infer from it.

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lloyd
Sent: Thursday, December 10, 2009 12:32 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Maximum stack memory

I have modified the code to very short one as shown below

int __cdecl main()
{
unsigned char buff[(1024*243)+880];
return 0;
}

No header files included. This is the maximum limit I am able to alocate in
stack. If I try to allocate one more byte it will crash!. I would like to
know the reason (I am convinced that this is not a good practive, just
wanted to know…)

Thanks,
Lloyd

This scheme works even if you jump pages. So, if you touch memory 12k
bytes below the current stack pointer, it should allocate the three
pages in between. Because of that, I’m a little surprised that you got
this error, unless you were already near your 1MB reservation.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Scanned and protected by Email scanner

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

11

Lloyd wrote:

I have modified the code to very short one as shown below

int __cdecl main()
{
unsigned char buff[(1024*243)+880];
return 0;
}

No header files included. This is the maximum limit I am able to
alocate in stack. If I try to allocate one more byte it will crash!. I
would like to know the reason (I am convinced that this is not a good
practive, just wanted to know…)

Do “dumpbin /headers xxx.exe” and see what the stack reserve and stack
commit values are.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

12

These are the values I get for “dumpbin /headers xxx.exe”

40000 size of stack reserve
2000 size of stack commit

Do “dumpbin /headers xxx.exe” and see what the stack reserve and stack
commit values are.

Scanned and protected by Email scanner

13

Lloyd wrote:

These are the values I get for “dumpbin /headers xxx.exe”

40000 size of stack reserve
2000 size of stack commit

Well, that answers your question very nicely, doesn’t it? 40000 hex is
262,144 bytes. That’s exactly the limit you saw.

That number is adjustable through a linker command line switch, if you
need more stack.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

14

Thank you very much for clarifying me …

Lloyd wrote:
> These are the values I get for “dumpbin /headers xxx.exe”
>
> 40000 size of stack reserve
> 2000 size of stack commit

Well, that answers your question very nicely, doesn’t it? 40000 hex is
262,144 bytes. That’s exactly the limit you saw.

That number is adjustable through a linker command line switch, if you
need more stack.

Scanned and protected by Email scanner