Prev: vb6 form in an Excel application
Next: Problem with a Registry program from Karen Kenworthy
From: wxforecaster on 8 Apr 2010 19:39
I have a very large application that is frequently crashing XP
machines, but not so much Vista/Win7 (including my development
machine). Apparently, memory management improvements in Vista/7 have
masked the underlying problem and attempt to prevent the crashing --
not necessarily a good thing.

Since the previous versions of the software have been stable, I'm
convined it's the result of a 3rd party ActiveX control that was
introduced. However, I want to check and make sure that my own code is
kosher. I have already confirmed that there are no USER or GDI
resource leaks, and the STATUS_ACCESS_VIOLATION and
STATUS_HEAP_CORRUPTION would suggest this is more of a memory
allocation issue.

With that said, I was using Page Faults as a means of tracking this
issue. I've had a hard time coming up with any sound reasoning, but I
was always under the impression that Page Faults are bad and should
not occur under any circumstance. However, I am able to generate them
simply by ReDimming an array to a "fairly large" value.

In the code below, we are allocating the memory necessary to store
data from GIS ESRI Shapefiles. The code/white sheet are pretty
intuitive and the code works great, but this is just one example of
where page faults are being generated on what I would say
"legitimately good code".

'POINTAPI defined as UDT of X, Y coordinates

Dim arrXYPoints() As POINTAPI
Dim arrPtsPerPart() As Long
Dim arrParts() As Long '4 byte long for each shape part
Dim arrPoints() As Double To hold each double X/Y point

ReDim arrXYPoints(shpinfo.lMaxPoints)
ReDim arrPtsPerPart(shpinfo.lMaxParts)
ReDim arrParts(shpinfo.lMaxParts * 4)
ReDim arrPoints(shpinfo.lMaxPoints * 16)

If shpinfo.lMaxPoints and shpinfo.lMaxParts are small -- say a few
hundred -- no page faults are generated. However, some shapefile
records have NUMEROUS points, in some cases nearly 200,000. In this
case arrPoints because 3,200,000 bytes. In this instance, the ReDim
statements generate some 6000 page faults!

There are 4GB of RAM on this machine, of which 2.5GB are free.

Can someone shed some light on:
1.) Is there a such thing as a "valid" page fault?
2.) A better way to make absolutely sure it's the 3rd party control
that's the problem and not my code -- and no, removing it and running
the code for several hours without crashing is not the approach I'd
like to take.

Thanks!
Evan



From: Helmut Meukel on 8 Apr 2010 20:18
"wxforecaster" <ebookbinder(a)kc.rr.com> schrieb im Newsbeitrag
news:cc2321e1-6603-4b6c-bf23-5e4c0101f906(a)x12g2000yqx.googlegroups.com...
> Can someone shed some light on:
> 1.) Is there a such thing as a "valid" page fault?
> 2.) A better way to make absolutely sure it's the 3rd party control
> that's the problem and not my code -- and no, removing it and running
> the code for several hours without crashing is not the approach I'd
> like to take.
>
> Thanks!
> Evan
>


Evan,

from Wikipedia:
In computer storage technology, a page is a fixed-length block of memory that is
used as a unit of transfer between physical memory and external storage like a
disk, and a page fault is an interrupt (or exception) to the software raised by
the hardware, when a program accesses a page that is mapped in address space,
but not loaded in physical memory.

The hardware that detects this situation is the memory management unit in a
processor. The exception handling software that handles the page fault is
generally part of an operating system. The operating system tries to handle the
page fault by making the required page accessible at a location in physical
memory or kills the program in case it is an illegal access.

Contrary to what their name might suggest, page faults are not errors and are
common and necessary to increase the amount of memory available to programs in
any operating system that utilizes virtual memory, including Microsoft Windows,
Mac OS X, Linux and Unix. Note that Microsoft uses the term hard fault in its
Resource Monitor to mean 'page fault' (cf. Resource View Help in Microsoft
operating systems).

Helmut.



From: ralph on 8 Apr 2010 21:50
On Thu, 8 Apr 2010 16:39:12 -0700 (PDT), wxforecaster
<ebookbinder(a)kc.rr.com> wrote:

>I have a very large application that is frequently crashing XP
>machines, but not so much Vista/Win7 (including my development
>machine). Apparently, memory management improvements in Vista/7 have
>masked the underlying problem and attempt to prevent the crashing --
>not necessarily a good thing.
>
>Since the previous versions of the software have been stable, I'm
>convined it's the result of a 3rd party ActiveX control that was
>introduced. However, I want to check and make sure that my own code is
>kosher.
....
>2.) A better way to make absolutely sure it's the 3rd party control
>that's the problem and not my code -- and no, removing it and running
>the code for several hours without crashing is not the approach I'd
>like to take.
>

Meukal has explained the 'page faults'.

There are ways to instrument a program to profile total memory usage
but as you have discovered it tends to lead you down a interesting
path (to a geek) but doesn't really provide much information to
resolve your problem.

My suggestion is for you to forget any assumptions and fire up WinDbg.
(http://www.microsoft.com/whdc/devtools/debugging/default.mspx)

Get an XP box, Setup WinDbg as the JIT Debugger. Find the point of
failure and then back-track to the problem.

-ralph
From: Nigel Bufton on 9 Apr 2010 03:07

"wxforecaster" <ebookbinder(a)kc.rr.com> wrote in message
news:cc2321e1-6603-4b6c-bf23-5e4c0101f906(a)x12g2000yqx.googlegroups.com...
> I have a very large application that is frequently crashing XP
> machines, but not so much Vista/Win7 (including my development
> machine). Apparently, memory management improvements in Vista/7 have
> masked the underlying problem and attempt to prevent the crashing --
> not necessarily a good thing.
>
> <snip>
>
> There are 4GB of RAM on this machine, of which 2.5GB are free.
>
> Can someone shed some light on:
> 1.) Is there a such thing as a "valid" page fault?
> 2.) A better way to make absolutely sure it's the 3rd party control
> that's the problem and not my code -- and no, removing it and running
> the code for several hours without crashing is not the approach I'd
> like to take.
>
> Thanks!
> Evan
>

The fact that you see the crashes more frequently with XP may indicate that
memory fragmentation is contributing to the problem.

XP/Vista/7 implement "Low Heap Fragmentation". It is enabled by default in
Vista/7, but not in XP.

Nigel

From: Nobody on 9 Apr 2010 09:59
There is no relationship between page faults and crashes. Page faults tell
how much disk swapping is taking place. Each process has a set of pages in
physical memory that changes overtime. You can tell how many pages your
process is using by calling GetProcessWorkingSetSize(NT4+ only) or
GetProcessMemoryInfo(NT4+ only). You can change it by calling
SetProcessWorkingSetSize(NT4+ only). Try not to request too much because
this would affect other applications, but the OS is not guaranteed to give
you what you asked for. See the remarks section of SetProcessWorkingSetSize
for details. Requesting more reduces disk swapping.

Some links:

Process Working Set:
http://msdn.microsoft.com/en-us/library/ms684891(VS.85).aspx

Working Set:
http://msdn.microsoft.com/en-us/library/cc441804(v=VS.85).aspx

As for crashes, it probably caused by something that use CopyMemory
incorrectly. Like passing a wrong pointer or length, which erases part of
the heap. This could be caused by your code if you are using CopyMemory, or
by the 3rd party control you mentioned. However, if the 3rd party control
accepts arbitrary pointers to memory blocks and their size, it's possible
that you are giving it incorrect information. This obviously depends on how
the control works.



 |  Next  |  Last
Pages: 1 2
Prev: vb6 form in an Excel application
Next: Problem with a Registry program from Karen Kenworthy