Home All Groups Group Topic Archive Search About

Any thoughts? Application error .data not place into memory because of an I/O error

Author
4 Aug 2010 3:05 AM
Tony Toews
Folks

The following problem has been reported twice on two separate systems
at one particular client

The instruction at 0x7344de72 referenced memory at 004bac40.  The
required data was not placed into memory because of an I/O error
status of 0000000c4

Given that the VB6 exe resides on the server I'm thinking this is a
network corrupt packet issue of some sort given the IO error.   Or
maybe bad RAM.

There are a total of three hits for "data not placed into memory
because of an I/O error".  So this is exceedingly rare.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
  updated see http://www.autofeupdater.com/

Author
4 Aug 2010 3:16 AM
Tom Shelton
Tony Toews presented the following explanation :
Show quoteHide quote
> Folks
>
> The following problem has been reported twice on two separate systems
> at one particular client
>
> The instruction at 0x7344de72 referenced memory at 004bac40.  The
> required data was not placed into memory because of an I/O error
> status of 0000000c4
>
> Given that the VB6 exe resides on the server I'm thinking this is a
> network corrupt packet issue of some sort given the IO error.   Or
> maybe bad RAM.
>
> There are a total of three hits for "data not placed into memory
> because of an I/O error".  So this is exceedingly rare.
>
> Tony

Hmmm... I'd suspect bad ram.  I'd run memtest or similar.

--
Tom Shelton
Author
4 Aug 2010 4:05 AM
ralph
On Tue, 03 Aug 2010 21:05:36 -0600, Tony Toews
<tto***@telusplanet.net> wrote:

Show quoteHide quote
>Folks
>
>The following problem has been reported twice on two separate systems
>at one particular client
>
>The instruction at 0x7344de72 referenced memory at 004bac40.  The
>required data was not placed into memory because of an I/O error
>status of 0000000c4
>
>Given that the VB6 exe resides on the server I'm thinking this is a
>network corrupt packet issue of some sort given the IO error.   Or
>maybe bad RAM.
>
>There are a total of three hits for "data not placed into memory
>because of an I/O error".  So this is exceedingly rare.
>

As you have already found out if you did any Googling - this is not a
good thing. Since you are getting a "~0C4" then RAM must be suspect,
but it could also be any other 'device'.

A card is bad - ie, over-heating, bad fan, dirt, poor seating,
over-clocked, blah, blah, ... . Therefore some general knowledge of
the client's environ might help - ie, is it an especially dirty place,
do they have old boxes, tight-wads (buy cheap...), etc.

I really doubt "corrupt packets" (other than from a problem with a
specific device), or any kind of software error as normally you would
get some other kinds of errors as well. Need to really peruse the
logs.

Exhasutive memory tests and HD tests are warranted. However, you are
reporting two separate 'systems' for one client, yet you said the exe
resides on "THE server" (emphasis mine).  Look for a physical device
in common between the systems.

-ralph
Author
5 Aug 2010 9:26 PM
Tony Toews
On Tue, 03 Aug 2010 21:05:36 -0600, Tony Toews
<tto***@telusplanet.net> wrote:

>The instruction at 0x7344de72 referenced memory at 004bac40.  The
>required data was not placed into memory because of an I/O error
>status of 0000000c4

They think it's a permissions or quota problem.  I would've thought
the OS would give a much clearer error message in such a situation.
Note, among other things, that my utility copies files from the server
to the workstation or sometimes from the server to a user specific
folder on a server.   So a permissions or quota problem is certainly
possible but I wouldn't have thought this kind of failure.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
  updated see http://www.autofeupdater.com/
Author
5 Aug 2010 10:17 PM
ralph
On Thu, 05 Aug 2010 15:26:01 -0600, Tony Toews
<tto***@telusplanet.net> wrote:

Show quoteHide quote
>On Tue, 03 Aug 2010 21:05:36 -0600, Tony Toews
><tto***@telusplanet.net> wrote:

>>The instruction at 0x7344de72 referenced memory at 004bac40.  The
>>required data was not placed into memory because of an I/O error
>>status of 0000000c4
>
>They think it's a permissions or quota problem.  I would've thought
>the OS would give a much clearer error message in such a situation.
>Note, among other things, that my utility copies files from the server
>to the workstation or sometimes from the server to a user specific
>folder on a server.   So a permissions or quota problem is certainly
>possible but I wouldn't have thought this kind of failure.
>

Me too, BUT one always needs more information ...

Where or who is generating this error? Is is definitely your App (ie,
a VB report) or something from the O/S? Ie, what does your App do?
Hiccup or come crashing down? What happens afterwards? What do the
logs show?

Also perhaps you are getting 'scapegoated' - is your App the only
thing demonstrating odd behavior? If so then it could very well be
that your App is responsible, otherwise it may only be your App
violently exercises some otherwise obscure device.

I hate guessing before all the facts are in, but who does? Very much
like 'pre-optimizing' as you never actually know where the bottlenecks
are until you run the numbers. Your primary fact-finder is WinDbg and
the logs.

WinDbg installs on a production box with minimum impact*. Not like the
problems associated with installing say VB or VS, or even installing
and running a verbose debug version of your app. Run as a JIT debugger
and you should get some good clues.

I'm assuming the client is remote. Hopefully you have some
knowledgeable people on site, or you probably have to catch a plane.
<sad $$$>.

-ralph
[* however, it sometimes takes someone who golfs with the CEO to get
permission to install anything on a production box, no matter how
benign. <g>]
Author
5 Aug 2010 11:21 PM
Tony Toews
On Thu, 05 Aug 2010 17:17:44 -0500, ralph <nt_consultin***@yahoo.net>
wrote:

>Where or who is generating this error? Is is definitely your App (ie,
>a VB report) or something from the O/S?

Yes, definitely my VB6 exe, they sent me a screen shot and you can see
my VB6 exe name in the title of the Application Error msg box.

>Ie, what does your App do?
>Hiccup or come crashing down?

All you can do is click OK to terminate the program so it crashes.
Mind you it does do a few things before crashing.    But it could be
crashing at the point where it copies down files.

>What happens afterwards?

The program crashes so nothing more can happen.

>What do the logs show?

I've asked.

>Also perhaps you are getting 'scapegoated' - is your App the only
>thing demonstrating odd behavior? If so then it could very well be
>that your App is responsible, otherwise it may only be your App
>violently exercises some otherwise obscure device.

Absolutely.

>I hate guessing before all the facts are in, but who does? Very much
>like 'pre-optimizing' as you never actually know where the bottlenecks
>are until you run the numbers. Your primary fact-finder is WinDbg and
>the logs.
>
>WinDbg installs on a production box with minimum impact*. Not like the
>problems associated with installing say VB or VS, or even installing
>and running a verbose debug version of your app. Run as a JIT debugger
>and you should get some good clues.

Hmm, I'll have to check this out.

>I'm assuming the client is remote. Hopefully you have some
>knowledgeable people on site, or you probably have to catch a plane.
><sad $$$>.

Not going to catch a plane unless they pay me in advance.   <smile>
Which isn't going to happen of course.  This is sort of a shrink wrap
app.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
  updated see http://www.autofeupdater.com/