Unhandled Exception, 0xC0000005: Access Violation error

I have this app that I have tweaked, debugged, compilied in Win2000 but the release that I have built and used in a installshield script is for a WinXP machines.

When I test the app on the XP machine I receive this error:
Unhandled exception in <App.exe>: 0xC0000005: Access Violation.

I do not receive this message at all on my window 2000 machines...

any ideas?

thanks

Well, it is telling you that you have attempted to access memory that does not belong to you, so either you have a bounds overrun in your code that manages to stay within your program's image on Win2K or there is a bug in some API routine you call on XP (I rather doubt the latter, but you never know). Do you get the same results with a debug version? If not, then I suggest you have a memory overrun somewhere. If you get the same problem in debug mode, run it in a debugger and see where it barfs. If it is in your code trace all calls that lead to that point (which may not be obvious at all) and see if you can track down the overwrite. In the unlikely event that it is barfing in API code, try to write a very tiny, stripped down version of your program that replicates the problem (i.e., runs on Win2K, blows up on XP) and send it on to MS and ask them to fix the problem (of course, you will want to be sure all service packs have been installed as they may have already fixed the problem). However, since it is much more likely that the error is in your code (MS does do a lot of testing, after all, how much have you done?), here are a couple of things that can cause access violations: having a character array that you write past the end (or before the beginning, though that is less likely) and having a pointer that is pointing at garbage and then you try to dereference it (very VERY common, you should always initialize pointers to NULL);

Thank you so much for this explanation...great details...

One question:
I do not receive the same error with a debug version on XP...what you are saying is that its looking more and more like memory overrun?


thanks again...

Generally speaking, the API calls in debug mode are pretty much the same as in release mode (though there are exceptions). What happens when you compile in debug mode (indeed when you make any change in the code, no matter how trivial) you can trigger a very significant rearrangement of the actual layout of the binary. What that means then is that if you had an out of bounds access (note that typically this is a write error, but sometimes a read error) that just read a few bytes beyond its allowed boundaries, the rearrangement of the binary may result in a few bytes of padding in just that spot. Therefore your program would be accessing its own space (though not all parts of the program are created equal by the OS) and the OS wouldn't care if your program is making changes. Sometimes you can replicate the error in debug mode (that is, by far, the best of circumstances), but often the act of recompiling will shift things around. Also, in many debug versions the compiler puts in a lot of padding so it can access memory structures easier (which, btw, often make the program as much as an order of magnitude slower, one of the reasons why you should never put a debug version into production) so a bug that never shows up in testing can be a real nightmare in production. Having said all that, if you are linking to debug versions of the API libs, you could be seeing the exact same effect in MS's code, though, as I said, there is only a small chance of that (it is always best to assume it is your problem until you can prove otherwise).

thanks again...can something like this cause a problem:
[code]
while (m_pDBAccess->GetClosureMethod(m_stClosureMethodData))
{
do something
}
[code]


thanks

Anything is possible, but from the looks of the name I would suppose you are using some MS lib. What can happen is you can have an overwrite nearly anywhere in your code with a variable that happens to overlap some area where the compiler has put some code (or data) for your program's portion of a library object. Corrupting that area wouldn't cause any problem when it actually happened, but later when you need to use that area of code/data, the corrupted memory causes all sorts of problems. That is why it is so difficult to find and fix. The 'easiest' way is to find out which areas of memory are just 'up memory' (as overflows are much more common than underflows) from the actuall location where the crash occurs and then examine the variables that reside there in your code and see if any could be overflowed. It is an often painful and tedious task and more than once I have simply rewritten a program (no copy and paste!) because I got tired of trying to find my bug.

BTW: You need to do some research on code tags.

It appears that I'm bombing out at this location, but I have initialized the pointer to null in the constructor:


Here is wher I am initializing the pointers...is that correct?



If I am initializing the pointer..why is it bombing out?

thanks

i never do any windows programming, but if you have an unhandled exception, it means that somewhere an exception is being thrown, and nobody is catching it. if M$ has been sensible, there will be some documentation telling you what type of exception is being thrown (maybe even all exceptions derive from a base class...). i suggest you embed the block of code in a try-catch block, and print the error message from the exception you catch. this should

a) stop you application from just bombing out (if it does)
b) give you some more information about what is happening.

i hope this information is useful to you.

cheers,
conejito

Establishing the default value only helps you if you DON'T otherwise initialize the variable. In this case it appears to be failing on assignment, which means the failure is in AfxGetApp(), not in your code. If it fails AFTER you call AfxGetApp() then you have an invalid pointer from AfxGetApp(), check to see if it is a NULL. If it is NULL and then you try to use it, you will get an exception every time.