|
code
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Any thoughts? Application error .data not place into memory because of an I/O errorThe 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/ Tony Toews presented the following explanation :
Show quoteHide quote > Folks Hmmm... I'd suspect bad ram. I'd run memtest or similar.> > 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 -- Tom Shelton On Tue, 03 Aug 2010 21:05:36 -0600, Tony Toews
<tto***@telusplanet.net> wrote: Show quoteHide quote >Folks As you have already found out if you did any Googling - this is not a> >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. > 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 On Tue, 03 Aug 2010 21:05:36 -0600, Tony Toews
<tto***@telusplanet.net> wrote: >The instruction at 0x7344de72 referenced memory at 004bac40. The They think it's a permissions or quota problem. I would've thought>required data was not placed into memory because of an I/O error >status of 0000000c4 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/ 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 Me too, BUT one always needs more information ...><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. > 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>] 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, Yes, definitely my VB6 exe, they sent me a screen shot and you can see>a VB report) or something from the O/S? my VB6 exe name in the title of the Application Error msg box. >Ie, what does your App do? All you can do is click OK to terminate the program so it crashes.>Hiccup or come crashing down? 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 Absolutely.>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 Hmm, I'll have to check this out.>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 Not going to catch a plane unless they pay me in advance. <smile>>knowledgeable people on site, or you probably have to catch a plane. ><sad $$$>. 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/ |
|||||||||||||||||||||||