From: Gregg N 

Rich wrote:
>    USER32.DLL is not screwing up.  If there is a memory leak than you
> are likely running out of virtual memory.  A handle leak can also cause
> problems.  You can't create new processes because there is insufficient
> resources to do so.  You get an error mentioning USER32.DLL because
> there is either insufficient resources to load it or for it to initialize.
>
>    The fix is to increase your page file size, add a new page file, or
> add more RAM.  Well that and to fix the memory and/or handle leak.
>
> Rich
>

Speaking of page files, we have a dedicated (semi-embedded) computer
running Windows XP on which we have disabled paging in order to reduce disk
I/O (which has caused interrupt latency issues with our application). Since
it is a dedicated application/computer with bounded memory usage, we either
have enough RAM or we don't. There is no real need for a page file in this
case.

However, even though the page file size is zero, we have recently noticed
that the application is constantly producing page faults (and a rather
large number of them) at a rate similar to the processing rate of our
application, even though the total committed memory is less than half the
available physical memory. What would cause this, and do you know of a way
to diagnose it?

I understand that the operating system can page in from the image file
itself even if there is no page file, but why would it be constant after
the initial set of faults if there is adequate memory?

Thanks.

Gregg

--- BBBS/NT v4.01 Flag-5