Sign in to follow this  

Access violation .... the memory could not be read

This topic is 3677 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello, A C++ application of mine occasionally procudes a sporadic access violation after running fine for hours. Since this error is so rare, it is very hard to catch it while running the program in the debugger. :( My only clue is an error message such as "Access violation! The instruction at 0xblahblahblah referenced memory at 0x00000blahblah. The memory could not be read." Now much to my shame I must confess that while I'm a relatively solid C/C++ coder, my assembler knowledge is very limited. Is there any way I can use the instruction/memory addresses provided by the error message to track down the bug? Can anyone give me a few pointers in the right direction? Do I need to put my executable through a disassembler or something like that?

Share this post


Link to post
Share on other sites
Running your code through the debugger should give you a call stack you can use.

What's the actual address? If it's 0x00000000, or very close to zero), then that's almost certainly a null pointer somewhere.

Dissasembling your app probably won't give you any useful information.

Share this post


Link to post
Share on other sites
Quote:
Original post by Red Ant
Hello,

A C++ application of mine occasionally procudes a sporadic access violation after running fine for hours. Since this error is so rare, it is very hard to catch it while running the program in the debugger. :( My only clue is an error message such as "Access violation! The instruction at 0xblahblahblah referenced memory at 0x00000blahblah. The memory could not be read." Now much to my shame I must confess that while I'm a relatively solid C/C++ coder, my assembler knowledge is very limited. Is there any way I can use the instruction/memory addresses provided by the error message to track down the bug? Can anyone give me a few pointers in the right direction? Do I need to put my executable through a disassembler or something like that?


Well, for starters you could have shown the address instead of "0000blahblah". The first half of it looks like it's probably a null pointer you're trying to dereference.

As for how you can diagnose it yourself? Use the debugger. At the point where it crashes, you'll know the address it tried to access, and then you just have to look through your local variables to find out which one of them contained that address. Then you know that variable contained an invalid pointer, and you can backtrack from there to figure out how that happened.

Share this post


Link to post
Share on other sites
Oh how I wish I could run it in the debugger! Alas .. no such luck, mainly because of the error being so damn sporadic that it never happens when I got the app running in the debugger.

EDIT: There are plenty other reasons why I can't run it in the debugger and hope to catch the error that way. The application in question is a CORBA server that interfaces with PROFIBUS plug-in cards, etc ... on my development machine, the PROFIBUS cards aren't present and the whole PROFIBUS interface isn't even loaded. The machines where the application is actually used productively don't (and can't) have Visual Studio installed. :(

Share this post


Link to post
Share on other sites
Quote:
Original post by Spoonbender
Well, for starters you could have shown the address instead of "0000blahblah". The first half of it looks like it's probably a null pointer you're trying to dereference.


the instruction was: 0x7c901010
the memory location: 0x00000014


Share this post


Link to post
Share on other sites
Quote:
Original post by Red Ant
Oh how I wish I could run it in the debugger! Alas .. no such luck, mainly because of the error being so damn sporadic that it never happens when I got the app running in the debugger.

EDIT: There are plenty other reasons why I can't run it in the debugger and hope to catch the error that way. The application in question is a CORBA server that interfaces with PROFIBUS plug-in cards, etc ... on my development machine, the PROFIBUS cards aren't present and the whole PROFIBUS interface isn't even loaded. The machines where the application is actually used productively don't (and can't) have Visual Studio installed. :(

So you settled on a platform without even considering the debugging implications. Oops.

Your best bet at this point is to get VS (probably in remote mode) working on that machine. Failing that, instrument your application to produce good debugging dumps, and examine those dumps. Your problem is almost certainly the execution of a member function on a null pointer, but without a stack trace this is likely to be a completely useless diagnosis.

Share this post


Link to post
Share on other sites
Your debugging suggestions have given me another idea. I think I'll try to get remote debugging to work. Perhaps that will help.

Quote:
Sneftel said
So you settled on a platform without even considering the debugging implications. Oops.


Silly, I know. Not my decision, though. I inherited this project from a coworker half a year ago. I had to do some serious refactoring to even enable the application to run from anywhere other than C:\testconfiguration. I also had to switch from static DLL linking to runtime linking to get the program to run on ANY development machine at all. It is all such a horrible mess. :(

Share this post


Link to post
Share on other sites
Quote:
Original post by Red Ant
Quote:
Original post by Spoonbender
Well, for starters you could have shown the address instead of "0000blahblah". The first half of it looks like it's probably a null pointer you're trying to dereference.


the instruction was: 0x7c901010
the memory location: 0x00000014
That looks like you're accessing a member variable in a class which is a null pointer. You can find out what function it was in from the instruction address, that's in a windows DLL (Kernel32 maybe?)

Perhaps someone else here knows how to get the function from the address (I don't)

Share this post


Link to post
Share on other sites
According to Process Explorer, 0x7c901010 is in ntdll.dll, which loads at 0x7c900000. And according to Depends, RtlEnterCriticalSection's entry point is 0x00001005, which looks like it would be correct.

Can you get a call stack from when the access violation occurs? RtlEnterCriticalSection is called from various other Win32 functions.

Share this post


Link to post
Share on other sites
Have you tried watching the memory usage of the program over time? It might be crashing accessing data from a NULL pointer to struct because it couldn't allocate the memory for that struct.

Share this post


Link to post
Share on other sites
Quote:
Original post by Evil Steve
According to Process Explorer, 0x7c901010 is in ntdll.dll, which loads at 0x7c900000. And according to Depends, RtlEnterCriticalSection's entry point is 0x00001005, which looks like it would be correct.

Can you get a call stack from when the access violation occurs? RtlEnterCriticalSection is called from various other Win32 functions.


Well, that looks interesting! So you took the instruction address I gave you, subtracted the load address of the DLL and that gave you the entry point of the function in which the instruction is located? Interesting, learn something new every day (I really need to read up on this kind of stuff). :)

Unfortunately until I've set up remote debugging I see no way of getting that call stack ... unless I had a way of converting an access violation to a regular C++ exception. Each thread of the program catches any and all exceptions that propagate out far enough and reports them in a log file.
Hmm, that's not actually such a dumb idea, is it? I think I read about something like that a while back ...

Share this post


Link to post
Share on other sites
Quote:
Original post by iMalc
Have you tried watching the memory usage of the program over time? It might be crashing accessing data from a NULL pointer to struct because it couldn't allocate the memory for that struct.


Memory usage seems normal. At any rate, failure to allocate memory (using new at least) should have caused an std::bad_alloc to be raised, shouldn't it?

Share this post


Link to post
Share on other sites
Quote:
Original post by Evil Steve
According to Process Explorer, 0x7c901010 is in ntdll.dll, which loads at 0x7c900000. And according to Depends, RtlEnterCriticalSection's entry point is 0x00001005, which looks like it would be correct.

Can you get a call stack from when the access violation occurs? RtlEnterCriticalSection is called from various other Win32 functions.

In a little more detail, the instruction at 0x7C901010 attempts to dereference the SpinCount parameter of the CRITICAL_SECTION passed to EnterCriticalSection:

typedef struct _RTL_CRITICAL_SECTION {
PRTL_CRITICAL_SECTION_DEBUG DebugInfo;

//
// The following three fields control entering and exiting the critical
// section for the resource
//

LONG LockCount;
LONG RecursionCount;
HANDLE OwningThread; // from the thread's ClientId->UniqueThread
HANDLE LockSemaphore;
ULONG_PTR SpinCount; // force size on 64-bit systems when packed
} RTL_CRITICAL_SECTION, *PRTL_CRITICAL_SECTION;


Then again, this isn't entirely useful, as I doubt the OP is calling this function manually.

Red Ant, are you using any Internet Explorer or Java modules in your program? If so, this particular error is associated with a known malware threat. See this thread for removal details. From what I gather, the malware is attempting to execute some shellcode via a vulnerability in RtlEnterCriticalSection, but is causing an exception to be thrown by SP2's data-execution-prevention feature.

Share this post


Link to post
Share on other sites
You might find a minidump useful.

However I just did a quick test and a call to EnterCriticalSection(NULL) will cause an identical crash. Of course without the call stack you can't locate it, it may not even be from your code, but wrapping all your calls to EnterCriticalSection() with a null check is probably a good start! Don't just leave it at that though, you'll need to find out why it's end up as null and fix it.

Share this post


Link to post
Share on other sites
Quote:
Original post by TheAdmiral
Red Ant, are you using any Internet Explorer or Java modules in your program?


Nope. Anyway, thanks for that highly informative post. :)

Share this post


Link to post
Share on other sites
Quote:
Original post by Adam_42
You might find a minidump useful.

However I just did a quick test and a call to EnterCriticalSection(NULL) will cause an identical crash. Of course without the call stack you can't locate it, it may not even be from your code, but wrapping all your calls to EnterCriticalSection() with a null check is probably a good start! Don't just leave it at that though, you'll need to find out why it's end up as null and fix it.


Critical sections are certainly used in my program, but never directly. We do all thread sychronization using higher-level threading primitives supplied by the ACE library, which I suspect calls EnterCriticalSection internally.

Share this post


Link to post
Share on other sites
Quote:
Original post by Evil Steve
According to Process Explorer, 0x7c901010 is in ntdll.dll, which loads at 0x7c900000. And according to Depends, RtlEnterCriticalSection's entry point is 0x00001005, which looks like it would be correct.


And putting the two numbers into google yields plenty of results, indicating it's an OS related problem.

Share this post


Link to post
Share on other sites
Okay. Could you give us some more information about which standard and third-party controls and libraries you are using? It seems there are a few reports of incorrect use of EnterCriticalSection. You wouldn't be using VS 2005 Pro's Datasource control, perchance?

A lot of noise about this particular error seems to have been appeased by reinstalling 'everything'. This probably isn't what you want to hear, but if things get desperate enough, it may be necessary so as to ensure that you don't have any OS DLL incompatibilities.

Before that, though, try updating all your drivers. I encountered a couple of instances of DirectX causing this error with outdated graphics drivers.

Edit:

Quote:
Original post by Antheus
And putting the two numbers into google yields plenty of results, indicating it's an OS related problem.

Not necessarily. Many of these results pertain to particular programs, libraries and controls (Windows Move Maker seems popular). There doesn't seem to be any single, dominant theme though.

Share this post


Link to post
Share on other sites
Quote:
Original post by Red Ant
Quote:
Original post by iMalc
Have you tried watching the memory usage of the program over time? It might be crashing accessing data from a NULL pointer to struct because it couldn't allocate the memory for that struct.


Memory usage seems normal. At any rate, failure to allocate memory (using new at least) should have caused an std::bad_alloc to be raised, shouldn't it?


No. std::bad_alloc is a means of signalling that the attempt to allocate memory failed. The C++ language provides no standard, portable way to determine, given only a memory location, if the memory there is allocated, belongs to your process, or even exists.

Share this post


Link to post
Share on other sites
Quote:
Original post by Red Ant
Quote:
Original post by iMalc
Have you tried watching the memory usage of the program over time? It might be crashing accessing data from a NULL pointer to struct because it couldn't allocate the memory for that struct.


Memory usage seems normal. At any rate, failure to allocate memory (using new at least) should have caused an std::bad_alloc to be raised, shouldn't it?
Assuming you have a compliant compiler, and haven't changed any compile switches to alter that behaviour, then sure. There are plenty of things that might have been allocating memory without using new. Also I have no idea what excpetion handling your program does either, so you could have been catching and ignoring such exceptions.
Anyway, as you say, memory usage doesn't look to be a problem. That doesn't rule out resource exhaustion of course, but that's easy to look into as well.
There's a dozen or so different things that could be the cause at this stage.

Share this post


Link to post
Share on other sites

This topic is 3677 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this