Any thoughts? Application error .data not place into memory because of an I/O error
in [Visual Basic]
|
Prev: Unicode API
Next: Thread hijacking (Was: Unicode API)
From: Tony Toews on 3 Aug 2010 23:05 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/
From: Tom Shelton on 3 Aug 2010 23:16 Tony Toews presented the following explanation : > 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
From: ralph on 4 Aug 2010 00:05 On Tue, 03 Aug 2010 21:05:36 -0600, Tony Toews <ttoews(a)telusplanet.net> wrote: >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
From: Tony Toews on 5 Aug 2010 17:26 On Tue, 03 Aug 2010 21:05:36 -0600, Tony Toews <ttoews(a)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/
From: ralph on 5 Aug 2010 18:17
On Thu, 05 Aug 2010 15:26:01 -0600, Tony Toews <ttoews(a)telusplanet.net> wrote: >On Tue, 03 Aug 2010 21:05:36 -0600, Tony Toews ><ttoews(a)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>] |