unhandled exception in someprog.exe (NTDLL.DLL): 0xC0000005: Access Violation

[Steve]

Why do I get the following error message when I press the exit button
on my application(release version).

unhandled exception in someprog.exe (NTDLL.DLL): 0xC0000005: Access
Violation

I do not get any error messages when exiting from the debug version of
the program. Initially I had some memory leakage in the debug output
window but I have already corrected it by deleting away the objects.

Looking up MSDN, access violation means accesing memory that is
illegal....
Why does the message appear only in the release version and not the
debug version? How to correct this bug since it does not appear in the
debug version?
Just in time debugging is enabled but if you view the stack it will
only show the assembly code for the NTDLL.DLL(windows nt dll). No
error messages in the debug ouput of the window.Thread exited with
code 0 no memory leakage warning.

Can anyone help?

Regards

[X]

This error will usually occur if you're incorrectly trying
access heap allocated memory (it doesn't occur in debug mode
because memory allocation in debug mode is different from that
of release mode). Just put in your debug symbols and compile the
release build.

X

"Steve" <ngs...@my-deja.com> wrote in message
news:976e0586.01060...@posting.google.com...

[Karl]

You can debug at release mode.

Go to "C++" tab in "Project setting" menu.
Set 'Debug info' to 'Program Database for Edit and Continue'
And then, Go to "Link" tab in "Project setting" menu.
Put check mark on 'Generate Debug info' checkbox.

Forgive my poor english.

Regards

"Steve" <ngs...@my-deja.com> wrote in message
news:976e0586.01060...@posting.google.com...

[Bruce Dawson]

You also should add /opt:ref to the link options. For full details
read:

http://www.cygnus-software.com/papers/release_debugging.html

Karl wrote:

--
.Bruce Dawson, Humongous Entertainment (we're hiring).
http://www.humongous.com/
Send job applications by e-mail, post technical questions
to the newsgroups please. Thanks.

[Steve]

I still cannot find out what is wrong with it, I have done the
following according to Karl,

Go to "C++" tab in "Project setting" menu.
Set 'Debug info' to 'Program Database for Edit and Continue'
And then, Go to "Link" tab in "Project setting" menu.
Put check mark on 'Generate Debug info' checkbox.

X, what do you mean by

"Just put in your debug symbols and compile the release build."

What debug symbols to add?

It gets an unhandled exception inside ntdll.dll(windows dll).You can't
possibly debug ntdll.dll since you don't have the source code??Or Can
you?? What can you do other then look through the entire program to
see where memory is not allocated properly?

Regards

[Sam Hobbs]

There are many causes for this and adding Debug info will probably not help
to find the most common ones. One possibility is that the program is
function improperly due to an uninitialized variable. A debug build
initailizes some storage automaticly that a release build does not. Another
common mistake is message map entries that are incorrect. If you have used
ClassWizard to add all message map entries then that is not likely to be a
problem.

See Joseph Newcomer's article at:
http://www.pgh.net/~newcomer/debug_release.htm

"Steve" <ngs...@my-deja.com> wrote in message
news:976e0586.01060...@posting.google.com...

[X]

I just meant what Karl said, Project setting, Program Database
... etc.

Yea, basically when you get the error and the option of OK |
Cancel, choose cancel. VC++ should open up in Debug mode. Open
up the Variables window if it's not open (ALT+4). Click Context
list, and look for the method/function where it failed.

X

"Steve" <ngs...@my-deja.com> wrote in message
news:976e0586.01060...@posting.google.com...

[Bruce Dawson]

ntdll.dll is being called from your program. If you find out where
then you can have some clue of why you are crashing. After
enabling the debug symbols with the instructions below, and
rebuilding, make the crash happen - preferably while running
under the debugger.

Then, open up the call stack window and see what function
is calling ntdll.dll. Then think very hard.

It's not easy. Debugging release builds can be very hard.

If you can detect the problem in release builds - perhaps
by using pageheap or BoundsChecker or more agressive
bounds checking of all of your memory accesses or
*something* then maybe you can track it down there.

However, unless you also look at the call stack in the
release build to *see* where it is crashing (and where
doesn't just mean what function, it means the complete
calls tack) then you won't know for sure when you've
fixed it.

If you still can't track it down, maybe you need a
consultant to fix it. I happen to be expert in this area...

Steve wrote:

--

[Steve]

Bruce Dawson <bru...@humongous.com> wrote in message news:<3B205C6F...@humongous.com>...

> ntdll.dll is being called from your program. If you find out where
> then you can have some clue of why you are crashing. After
> enabling the debug symbols with the instructions below, and
> rebuilding, make the crash happen - preferably while running
> under the debugger.

The crash always happen when the exit button of the release version is
pressed.

>
> Then, open up the call stack window and see what function
> is calling ntdll.dll. Then think very hard.
>
> It's not easy. Debugging release builds can be very hard.

If I can see which function or file is calling the ntdll.dll in the
call stack then I would not have a problem narrowing the bug at all.
The problem is the stack only displays two entries and both are from
ntdll.dll.It is a MFC program and it is after the last statement in
the initInstance() function in the winapp in my program that this
errors occurs.I have encountered this error before and is usually due
to some careless mistakes such as those listed in your article.Your
article was quite interesting.(I wasn,t the one writing the program
but I end up debugging it.There has to be a systematic way of
debugging such errors.

>
> If you can detect the problem in release builds - perhaps
> by using pageheap or BoundsChecker or more agressive
> bounds checking of all of your memory accesses or
> *something* then maybe you can track it down there.

Any freeware or shareware available and how are they used?? What is
microsoft spy that comes with Visual studio? Is it useful for this
sort of problem?

>
> However, unless you also look at the call stack in the
> release build to *see* where it is crashing (and where
> doesn't just mean what function, it means the complete
> calls tack) then you won't know for sure when you've
> fixed it.
>
> If you still can't track it down, maybe you need a
> consultant to fix it. I happen to be expert in this area...
>

I can't afford one.:->

[yugami]

just add debugging support to a build configuration thats copied from your
release build. then start the debugger, your probably deleteing a pointer
that changed somewhere down the line.

"Steve" <ngs...@my-deja.com> wrote in message

news:976e0586.0106...@posting.google.com...

[Bruce Dawson]

If you're running on Windows 2000 you can try PageHeap. It's
free and will track down some problems.

http://support.microsoft.com/support/kb/articles/Q264/4/71.asp?SD=MSDN

Also, if the crash always happens when the exit button is pressed,
put a breakpoint in the code that gets called then and step forward
watching for the crash.

Also, try to narrow down what it is that makes this happen on the
release build but not the debug build. If you disable optimizations
and the problem still happens then you know that optimizations are
not related to the problem, and you can debug far more easily
(debugging optimized code is a royal pain).

You can also try simplifying your program until the problem goes
away. Binary search. If your program just starts and then immediately
exits does the crash happen? What happens if you do this after
carefully removing half of your application specific code. Repeat as
needed.

Steve wrote:

--