Unhandled Exception etc...: Access Violation Reading Location 0x00000000

Unhandled Exception etc...: Access Violation Reading Location 0x00000000

resolar

Member #10,910

April 2009

I kept getiing the error message below when I run the standalone release version.
"Unhandled exception at 0x7c911689 in PTDA3.exe: 0xC0000005: Access violation reading location 0x00000000."

When I run the release version inside the IDE, everything works fine. I'm stumped and would appreciate any guidance.

Renante

torhu

Member #2,727

September 2002

Looks like you're dereferincing a null pointer there. Sure you're not using debug mode or doing something else different when running it in the IDE?

Anyway, you could maybe find out in which function 0x7c911689 is. But try to recreate it with debug symbols enabled first.

---
Smokin' Guns - spaghetti western FPS action

Matthew Leverton

Supreme Loser

January 1999

Compile in release mode and make sure every library you are using has been compiled with the same settings. And of course, the system you are running it on needs the proper VC run time.

--
RTFM | Follow Me on Google+ | I know 10 people

Tobias Dammers

Member #2,604

August 2002

resolar said:

When I run the release version inside the IDE, everything works fine. I'm stumped and would appreciate any guidance.

You are dereferencing a null pointer, but it is possible that this only happens in debug mode. Possible causes:
- you use assert() on a statement that dereferences a pointer (e.g. assert(bmp->w > 0)); the statement is not evaluated in release mode
- you dereference a pointer, but the statement is optimized away in release mode
- your compiler uses a different memory allocation algorithm in release mode, which leads to memory being accessible when it shouldn't be

In either case, you have questionable code somewhere, so I'd recommend using a debugger or some strategically placed TRACE() statements to find the exact line it crashes on; once you have that, finding out why it does so is often trivial.

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

Oscar Giner

Member #2,207

April 2002

Is your program loading files and not testing if they're loaded correctly? I'm guessing you use relative paths in your file I/O routines and while in the IDE the current folder is set up as you espect, it isn't when you run it from outside.

For example, if you're working with VC, release exe is put in projectdir/release. When run from the IDE, VC sets the current folder to projectdir, but if you run the exe from windows explorer, the current folder will be projectdir/release (the folder where the exe resides).

--
[Website | e-mail]
[Tetris Unlimited] [AllegAVI | AlText]

Andrei Ellman

Member #3,434

April 2003

Quote:

0x7c911689

This looks like the NULL-pointer dereference was generated somewhere by a Windows DLL. Most of the core DLLs in Windows are based in the 60000000-7FF00000 range. Source: http://www.virtualdub.org/blog/pivot/entry.php?id=114

--
Don't let the illegitimates turn you into carbon.

resolar

Member #10,910

April 2009

The exception only happens when I run the release version from outside the VS2005 IDE. The release and debug version works fine when run inside the IDE. Is there a difference between running the release version within the IDE and as a standalone application? The error message indicate as most of you have pointed out that there is a NULL pointer that is being dereferenced. I have stepped through the offending function looking for a deferenced NULL pointer and there is none.

count

Member #5,401

January 2005

resolar said:

Is there a difference between running the release version within the IDE and as a standalone application?

The folder you program is looking for resources is different.
Do you load any external files (bitmaps, textfiles)?

This is the same as Oscar already pointed out.

Don Freeman

Member #5,110

October 2004

You can also get that error when the program tries to do stuff that Windows will not let you do without a device driver, such as direct parallel port programming. I found that out a while back when I was experimenting with some of my hardware testing... ::)

--
"Everyone tells me I should forget about you, you don’t deserve me. They’re right, you don’t deserve me, but I deserve you."
"It’s so simple to be wise. Just think of something stupid to say and then don’t say it."

count

Member #5,401

January 2005

And why would that work when he runs the program from the ide?

Timorg

Member #2,028

March 2002

Random suggestion, that I wasn't sure if I should put out there. Does the program run outside the IDE when the IDE is running? If something is loaded when IDE is running, but not when it closed, this might work.

____________________________________________________________________________________________
"c is much better than c++ if you don't need OOP simply because it's smaller and requires less load time." - alethiophile
OMG my sides are hurting from laughing so hard ... :D

resolar

Member #10,910

April 2009

It does not work even with Visual Studio 2005 not running. I'm not doing anything fancy but just trying to read data from a binary file and printing it out to a text file.

Below is the code snippet:
void CTsr::read_STDF_rec(char *szBuffer, CTsr *pTsr, unsigned short length)
{
unsigned int i;
unsigned short idx;
float result = 0;
unsigned char *ptr2result = (unsigned char *) & result;

pTsr->HEAD_NUM = (*(szBuffer) & 0xff);
pTsr->SITE_NUM = *(szBuffer+1);
pTsr->TEST_TYP = *(szBuffer+2);
pTsr->TEST_NUM = read_U4(szBuffer, 3);
pTsr->EXEC_CNT = read_U4(szBuffer, 7);
pTsr->FAIL_CNT = read_U4(szBuffer, 11);
pTsr->ALRM_CNT = read_U4(szBuffer, 15);

idx = 19;
pTsr->TEST_NAM = read_char_string(szBuffer, length, idx); // It crash here

for(i = 0; i < sizeof(float); i++)
ptr2result[i] = *(szBuffer+idx-i);
pTsr->TEST_TIM = result;
}

read_char_string(....) is a function that is inherited from the base class. It is also called by other classes and they work fine in those classes.

Don Freeman

Member #5,110

October 2004

You are not checking to see if szBuffer or pTsr are valid. They may not be pointing to what you think. Also, does read_U4 actually increment where you are reading from?

[Example]
You have:
pTsr->TEST_TYP = *(szBuffer+2);
pTsr->TEST_NUM = read_U4(szBuffer, 3);

is that correct, or should it be:
pTsr->TEST_TYP = *(szBuffer+2);
pTsr->TEST_NUM = read_U4(szBuffer+2, 3);