CLSID_SQLSERVERCE_2_0 memory requirements on Pocket PC



Can anyone help me or,at least, explain to me what is happening.

I have an application on Pocket PC 2003 and Windows Mobile 2005 that
uses that SqlCe database engine.

The following test application, which I have created to represent a
problem that I encounter on
my real application, fails in the same way on Pocket PC 2003 and
Windows Mobile 5.0.


int WINAPI WinMain( HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPTSTR lpCmdLine,
int nCmdShow)
{

INT n;
INT nMax;
PVOID pMem[32];

nMax=12;
//nMax=11;

for (n = 0; n < nMax; n++) {
pMem[n]=malloc(1048576);

if(pMem[n]==NULL)
{
// DebugMsg (_T("Malloc failed at %d bytes"), n*1048576);
break;
}
}

HRESULT hr;

hr = CoInitializeEx(NULL, COINIT_MULTITHREADED);

IDBInitialize *pIDBInitialize = NULL; // Provider Interface
Pointer

hr = CoCreateInstance( CLSID_SQLSERVERCE_2_0,
0,
CLSCTX_INPROC_SERVER,
IID_IDBInitialize,
(void**)&pIDBInitialize);


//pMem[n+1]=malloc(1048576);

return 0;
}

If I allocate 11 megabytes of memory (i.e. nMax is set to 11) then the
call to
CoCreateInstance will succeed. If I allocate 12 megabyes of memory
(i.e. set
nMax to 12), then the call to CoCreateInstance will fail with
E_OUTOFMEMORY.

If you attempt to run this code, be aware that the exact amount of
memory to be
allocated to create success and failure situations varies between
different brands
of device. You have to increase or decrease the amount of memory that
you
allocate to see this problem.

However, the process has not reached its heap memory limit. Since, if
I were to
call malloc again (i.e. uncomment the malloc that follows the call to
CoCreateInstance) the call to malloc would succeed. In fact, I can use
malloc
to allocate about 26 megabytes of memory before malloc starts to fail.

As I have said, the above test application fails in the same way on
Pocket PC 2003
and Windows Mobile 5.0. The only difference is that you may have to
malloc more
memory on the Pocket PC 2003 device (about 16 megabytes) before the
CoCreateInstance
fails. Also the amount of memory that can be allocated varies between
different
manufacturers's device. This may be due to the differences in the
number and type of other
applications running on the device rather the operating system itself.


The fact that I can use malloc to allocate upto 26 megabyes of heap
memory
suggests to me that there are about 26 megabytes of heap memory
available
to this process. The fact that the CoCreateInstance of
CLSID_SQLSERVERCE_2_0
fails if I have already allocated more than 12 megabytes suggests to me
that
this function thinks that it requires about 14 megabytes of heap
memory.

However, when the call to CoCreateInstance succeeds, I don't see the
"Settings"=>"Memory"=>"
Program Memory In Use" shooting up by 14 megabytes. All that I see is
a small
increase of a few hundred kilobytes. Using DumpMem I see that the
ssce20.dll
has been loaded but this only uses 1.4 mb.


TestSqlCeMem.exe base address: 2E000000
=========================
ssce20.dll 00C30000 15B000 A
ole32.dll 02E20000 2C000 RO, H, S, XIP
oleaut32.dll 02FE0000 2F000 RO, H, S, XIP
coredll.dll 03F60000 95000 RO, H, S, XIP
coredll.dll.0409.mui 7FFE0000 15000 RO, S, XIP

The Virtual Memory Dump follows at the bottom of this message.

So please can someone tell me why CLSID_SQLSERVERCE_2_0 needs all this
free
heap space even though it appears not to use it.

Is there a way around this? In my real application I call
CoCreateInstance for
CLSID_SQLSERVERCE_2_0 at the start of the program. When the amount of
memory
malloc'ed rises above 12 megabytes, calls made to COM objects that are
derived
from CLSID_SQLSERVERCE_2_0 fail with E_OUTOFMEMORY.

By the way, I have read the paper Windows CE.NET Advanced Memory
Management by
Douglas Boling (ms836325). This was written in 2002. Is what was
written here still
valid.

Thanks in advance for your responses.

Grunter.




Process Memory Dump
TestSqlCeMem.exe

Virtual Memory Dump
======================
Legend
C - Committed
R - Reserved
F - Free

RO - Read Only
RW - Read Write
WC - Write Copy
X - Execute
XR - Execute Read
XRW - Execute Read Write
XWC - Execute Write Copy
G - Guard
NA - No Access
NC - No Cache

2E000000 10000 F NA
2E010000 1000 R NA Image
2E011000 1000 C RW Image
2E012000 1000 R NA Image
2E013000 1000 C RO Image
2E014000 1000 C RW Image
2E015000 1000 R NA Image
2E016000 1000 C RO Image
2E017000 9000 F NA
2E020000 F000 R NA Private
2E02F000 1000 C RW Private
2E030000 1000 C RW Private
2E031000 2E000 R NA Private
2E05F000 1000 F NA
2E060000 101000 C RW Private
2E161000 F000 R NA Private
2E170000 101000 C RW Private
2E271000 F000 R NA Private
2E280000 101000 C RW Private
2E381000 F000 R NA Private
2E390000 101000 C RW Private
2E491000 F000 R NA Private
2E4A0000 101000 C RW Private
2E5A1000 F000 R NA Private
2E5B0000 101000 C RW Private
2E6B1000 F000 R NA Private
2E6C0000 101000 C RW Private
2E7C1000 F000 R NA Private
2E7D0000 101000 C RW Private
2E8D1000 F000 R NA Private
2E8E0000 101000 C RW Private
2E9E1000 F000 R NA Private
2E9F0000 101000 C RW Private
2EAF1000 F000 R NA Private
2EB00000 101000 C RW Private
2EC01000 F000 R NA Private
2EC10000 101000 C RW Private
2ED11000 F000 R NA Private
2ED20000 1130000 F NA
2FE50000 7E000 R NA Image
2FECE000 2000 C RW Image
2FED0000 D0000 R NA Private
2FFA0000 40000 F NA
2FFE0000 1F000 R NA Image
2FFFF000 1000 C RW Image


Process Heaps Dump

Default Heap
==================
2E030060 FA0 Free
2EC10020 100FE8 UNKNOWN
2EB00020 100FE8 UNKNOWN
2E9F0020 100FE8 UNKNOWN
2E8E0020 100FE8 UNKNOWN
2E7D0020 100FE8 UNKNOWN
2E6C0020 100FE8 UNKNOWN
2E5B0020 100FE8 UNKNOWN
2E4A0020 100FE8 UNKNOWN
2E390020 100FE8 UNKNOWN
2E280020 100FE8 UNKNOWN
2E170020 100FE8 UNKNOWN
2E060020 100FE8 UNKNOWN

Visual Studio 2005 compiler command line:

/Od /Os /D "DEBUG" /D "ARM" /D "_ARM_" /D "ARMV4"
/D "UNDER_CE=0x501" /D "_WIN32_WCE=0x501" /D "WIN32_PLATFORM_PSPC"
/D "UNICODE" /D "_VC80_UPGRADE=0x0600" /D "_UNICODE" /FD /EHsc
/MTd /fp:fast /GR /Yu"stdafx.h"
/Fp"Windows Mobile 5.0 Pocket PC SDK
(ARMV4I)\WM5Debug/TestSqlCeMem.pch"
/Fo"Windows Mobile 5.0 Pocket PC SDK (ARMV4I)\WM5Debug/"
/Fd"Windows Mobile 5.0 Pocket PC SDK (ARMV4I)\WM5Debug/"
/W3 /nologo /c /Zi /TP

Visual Studio 2005 linker command line:

/OUT:"Windows Mobile 5.0 Pocket PC SDK
(ARMV4I)\WM5Debug/TestSqlCeMem.exe"
/INCREMENTAL /NOLOGO /MANIFEST:NO /NODEFAULTLIB:"kernel32.lib"
/NODEFAULTLIB:"oldnames.lib" /DEBUG
/PDB:"Windows Mobile 5.0 Pocket PC SDK
(ARMV4I)\WM5Debug/TestSqlCeMem.pdb"
/STACK:65536,4096 /ENTRY:"WinMainCRTStartup" /BASE:"0x00010000"
/ERRORREPORT:PROMPT commctrl.lib coredll.lib aygshell.lib Oleaut32.lib
Uuid.lib Ole32.lib. coredll.lib corelibc.lib ole32.lib oleaut32.lib
uuid.lib commctrl.lib

.



Relevant Pages

  • Re: StackOverflowException.
    ... The Status object monitors the ... so I'm really at a total loss as to where I'm leaking stack memory. ... private static extern bool EscapeCommFunction(IntPtr hFile, ... Good to know about arrays. ...
    (microsoft.public.dotnet.framework)
  • Re: How: multiple program instances sharing same data
    ... so this memory isn't shared. ... private copy of JITted code. ... Ok, because the .exe isn't native to my machine, it gets just-in-time ... I am talking about a Windows NET App, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: How can I tell the application total memory usage? (LONG!)
    ... No you can't simply add these two to calculate the amount of memory your ... of memory taken by a process using the performance counters but you can get ... The "Private bytes" represents the total of the pages, ... So while might be important to keep an eye at your memory consumption, ...
    (microsoft.public.dotnet.languages.csharp)
  • Windows Service Memory Usage
    ... starts to the first time it hits the database its memory consumption is ... database for the first time its memory jumps to 15MB and stays there. ... private SqlConnection sqlConnection = null; ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Memory leak with Datagrid and array
    ... > Matrix_A still has a reference to your instance of form2, ... > For detailed information on windows memory management ... > 64-bit, working set, private bytes, etc. ... >> However, the memory problem persists. ...
    (microsoft.public.dotnet.languages.vb)