In C++ any try catch to catch unhandled exception at address in .exe: 0xc0000005: access violation

Question

0.00/5 (No votes)

See more:

Hi,

In c++ program after long run I am getting an error at memory i think. The error shows

Unhandled exception at [address] in [projectname].exe: 0xc0000005: Access violation.

Is there any way to handle this issue with try catch. This make my application to crash. Please help me on this thank you.

What I have tried:

Unhandled exception at [address] in [projectname].exe: 0xc0000005: Access violation.

Posted 14-Feb-18 20:05pm

ssyuvaraja

Updated 20-Feb-20 16:54pm

Add a Solution

4 solutions

Solution 1

This is a memory access violation. Your program is accessing invalid memory. Normally a misleading pointer: deleted memory or the pointer is set or used wrongly.

You must debug the code line in which it happens. I know an option in Visual Studio to hit a debug point when memory or a value is changed, but not remember where it is now... (sorry)

Read the Using Breakpoints: Additional Information to find a way to set a helpful breakpoint and debug.

Posted 14-Feb-18 21:00pm

KarstenK

Updated 15-Feb-18 21:43pm

v2

Comments

ssyuvaraja 15-Feb-18 3:07am

Hi, Thank you. yes its because of memory. Memory address for pointer working fine for more then a day. At long run on certain point the memory corrupted, that causing the issue. So I want to catch that issue. Is there any way to use try...catch for this to handle it.

Stefan_Lang 21-Feb-20 4:54am

You could add code to test pointer values not for null, but for numbers below 1024. This is not 100% reliable, but when you have issues with memory allocation, the invalid pointers will be in that range most of the time. In any case, no valid pointer should be in that range, so you won't catch false positives.

P.s.: I've read that in some thread on SO some time ago. Unfortunately I can't find the link anymore, so I can't say what the source is for 1024. However, in UNIX, and probably some (most? all?) Linux distributions, addresses below 0x8000 are treated as seg fault. I have not found any such limit for Windows 10, but Win32 (without the /3gb switch set) used to reserve the address space below 0x10000.

KarstenK 16-Feb-18 3:45am

Added a link. You must debug your app - there is no way around. Some memory leaks are minimal, stay undercover because of a bigger buffer or are only in some random code pathes and are so hard to detect.

Solution 3

You should also look into using the DbgHelp.DLL library (at least in debug versions). Given debug information and symbols, it can be used to create a stack trace starting at the point where the exception was raised.

Posted 18-Feb-18 9:25am

Daniel Pfeffer

Solution 4

unhandled exception 0xC0000005 at adress 0x01197ED8

Posted 20-Feb-20 16:55pm

Member 14750988

Comments

Richard Deeming 21-Feb-20 7:58am

Your error message is not a "solution" to someone else's question.

Read the existing solutions.

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Jochen Arndt · Accepted Answer · 2018-02-14T22:32:00

You can catch such exceptions when enabling SEH (structured exception handling, see -EH (Exception Handling Model)[^]).

Because such exceptions occur asynchronous, they are fatal errors and the application should terminate. So catching such exceptions has no benfits for release builds besides generating your own error message or logging them.

But you can use them temporarily to get closer to the source of the problem by inserting try catch blocks at prominent code locations. Once you have a smaller portion of code that throws the exception, inspect it to find probable sources.

If not done so far, ensure that all pointer variables are initialised and perform assert() checks for debug builds.

To nail it down:
You have a bug in your code that must be fixed. It can be generally handled by catching the exception due to the asynchronism.