John Eldridge : Windows CE Debugging

KITL First. Ask Questions Later.

Virtual Memory and Thread Stacks

I know. It's been nearly a year since I posted anything. Ouch. Bad John.

What inspires a new post? Virtual memory. One of my favorite subjects, but unfortunately, also a common stumbling block on Windows CE, especially on feature-rich Pocket PCs. I've been debugging several stress cases recently that were impacted by virtual memory pressures and I thought I should remind folks about one common source of unnecessary pain.

When you build applications within Platform Builder or the Windows Mobile Adaptation Kit, the default thread stack is 64kB of reserved virtual memory (the physical RAM is committed one page at a time). This is a pretty reasonable limit for most things on an embedded device. However, when you build your applications in Visual Studio, the default thread stack is 1MB of reserved virtual memory. This is often much more than needed and consumes precious virtual memory real estate. Windows CE processes are limited to 32 MB of virtual address space, unless you employ specific techniques to allocate larger blocks outside the process space. If your application only has one or two threads this may not be a big deal, but if your app is heavily multi-threaded, you can very quickly run out of virtual address space on a CE-based device.

The better option is to set the default stack within the VS options back to 64k (see photo) and then allocate larger stacks only if necessary. The way to create a thread with a larger than default stack on Windows CE is to call CreateThread with the STACK_SIZE_PARAM_IS_A_RESERVATION set in dwCreationFlags and dwStackSize set to how large you would like your stack to be. That value will be rounded up to the next 64kB boundary. The physical RAM will still be committed just a page at a time as needed.

I'd personally like to change the VS default to a much smaller value, but that could introduce unexpected backwards-compatibility issues for folks that couldn't be caught at build time. I'm curious to hear feedback though of whether anyone targeting CE-based devices in Visual Studio is relying on the 1MB default? Or if you are changing the stack sizes already? Or just don't care since your apps only have a couple threads anyway?

Published Tuesday, January 31, 2006 2:44 PM by kitlfirst

Comments

 

Doug B said:

This is stunning! I've been hearing of products having trouble with app installs and driver loads on Windows Mobile 5. It was looking like a Merlin redux.

I can't imagine anyone actually depending on the 1 Meg stack this soon after the release VS 05. I'd change the default back to 64 K in a service pack asap. The only worry would be MFC and ATL apps. Perhaps the new port needs the larger stack. That'd take a bit of testing to see if they deal with in a 64 K stack.

Thanks for this info.

Doug
January 31, 2006 7:25 AM
 

B. Lee said:

Welcome back, John.
To answer your question, I work on applications that use lots of threads but the default 64K is good enough.

After reading your post, I've checked the 'Stack Reserved Size' on my projets.
It was just a quick test, so I'm now sure how correct(?) this may be
but here are my observations.

1. Created a Smart Device project with hello window code for WM5.0 in VS2005 --> Size was 0
So where does the default 1MB come from?

2. New Project in eVC 4.0 with hello window code ---> Size was 0x10000 == 65536
If I hit help on the settings menu a little popup shows that default stack size is 1MB. But it has the value 0x10000 entered by default. So how does it relate?



February 8, 2006 12:04 AM
 

B. Lee said:

Here is a typo fix.
I'm 'now' sure how correct(?) this may be --> 'now' should be a 'not'
February 8, 2006 1:43 AM
 

John Eldridge said:

Thanks for the feedback, B.  Yes, eVC4 did set the size to 64k explicitly. For VS2005, a value of zero means that the linker's default (1MB) will be used. I notified the VS team and they are looking into it.
February 19, 2006 12:39 AM
 

RoboForm said:

Good!
February 19, 2006 4:22 AM
 

Richard Plante said:

I'm having a program that reads a XML file using CubeWerx open source (www.cubewerx.com). Reading a small XML file (let say ~100K) works perfectly and does not generate any problem. Reading a huge XML file (currently trying 2.5Mb) is causing a stack overflow.

Reading a XML file is done recursively in CubeWerx since you have to go deep enough to the rightmost leaf to read the full content of the file. The default stack size of my program is still 1Mb and everything in CubeWerx is done from the same thread.

My question is: how come that code works correctly on a Win32 program but not on a SmartDevice program? Under Win32, my stack size is also set to the default value 1Mb and reading a 2.5Mb XML file is not generating a stack overflow.
March 1, 2006 1:15 PM
 

Windows Mobile Team Blog said:

Visual Studio reserves 1 MB of virtual memory for each of your app's threads by default.  This is...
March 29, 2006 12:45 PM
 

Kevin Moran said:

Is there any way to set this property for a c# smart device project?

Kevin
March 29, 2006 5:26 PM
 

Mike C. said:

Where do you find/set this value in Visual Studio 2005?
March 29, 2006 7:51 PM
 

kitlfirst said:

Mike C.,

You can find it under Project | Properties. Then you should see the dialog box. The setting is under Configuration Properties | Linker | System.
March 29, 2006 8:21 PM
 

Mike C. said:

Kitlfirst,

When I go into Project | Properties in VS 2005, I get the properties tabbed window (alongside my source code tabbed windows).  There is no dialog box as such.

Unfortunately, the project properties tabbed window doesn't have as many options at the VS 2003 dialog box has, as seen below:

<img src="http://itracksolutions.com/imagedump/VS2005ProjProps.gif">
March 30, 2006 1:36 PM
 

process stack size and threads | keyongtech said:

January 22, 2009 4:36 AM
New Comments to this post are disabled

© 2009 Microsoft Corporation. All rights reserved. Terms of Use  |  Trademarks  |  Privacy Statement
Microsoft
Page view tracker