I am getting the error: Unhandled exception at 0x77d815de in client.exe: 0xC0000005: Access violation reading location 0x00000000.
I understand what the normal access violation error means, but this one keeps repeating itself at location 0x77d815de, as in, I'll delete lines of code in the program, and it breaks at location 0x77d815de, regardless of the line that is. The code I am running is the simple Windows API code, with some additions to the switch statements (which i have tried removing) and a class initialisation (Which again, i have also tried removing).
Could you please give me some suggestions on at least why there may be an overflow, or a way to fix this.
Thank you for your time.
--
Found it out, it was caused by two switch cases interlocking in a way unnoticable by the compiler, and me. Reverted it to an older form from my repository and it was fine. It caused corrupt data in the DirectX Device class, and screwed up some of the initialisations of it, causing the read exception.
I usually see those addresses in ntdll.dll. You are probably providing some bad data to the WinAPI and it's crashing because you are not using it correctly.
If you break into your debugger at this point, you should be shown the call stack. You can go back through it until you reach your own code where you made the call. From there, it should be much easier to find the problem.
Related
I'm using POCO lib to working network.
i use JSON data of POCO/JSON . my code:
User user(context.marshal_as<std::string>(tbUserName->Text),
context.marshal_as<std::string>(tbFullName->Text),
context.marshal_as<std::string>(tbDisplayName->Text),
context.marshal_as<std::string>(tbEmail->Text),
context.marshal_as<std::string>(tbPhoneNumber->Text),
context.marshal_as<std::string>(tbNamSinh->Text),
context.marshal_as<std::string>(tbPassword->Text),
context.marshal_as<std::string>(tbConfirm->Text)
);
string jsonString = user.serialize();
I have an error Exception thrown at 0x00007FF93E507A7A (ntdll.dll) in Client_Winform.exe:
0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.
If there is a handler for this exception, the program may be safely continued.
Use Visual Studio's Code Analysis to track the exact place in your code where the bug is.
https://msdn.microsoft.com/en-us/library/ms182028.aspx
The problem with these kinds of error messages is not to understand the reason (bad handle) but to find the place. Since your code passed compilation with no errors, and in many cases, will run smoothly on several machines and crash only on one of them, you need to focus on the place of the crash.
You are using a handle which got returned as INVALID_HANDLE from some function (INVALID_HANDLE is -1 or 0xFFFFFFFFFFFFFFFF). When you try to use it, it gets used as an address and you don't have permissions to access that address (error 5 is access violation).
This could occur, when you do have multiplatform projects (i.e. assemblies). Meaning, if you do have one project of x86 and another project in x64. Issue occurs when you build project under wrong platform. For example, referred x64 assembly build under x86 and in the consumer code are trying to call specific function. Because, of this mixed platformed assemblies, reference calculation is resulting in x00000005 or xFFFFFFFF kind of location, which is restricted area in side RAM (i.e. OS part). Hence, it's throwing exception having message like "Access Violation exception reading location...". The solution I found is to identify and apply exact platform to relevant project. I retrieved entirely fresh code from the repo again and build under specific platform and this issue disappeared.
I was building a 10-year-old project with debug set as x64. When I changed to x86 for debug and Win32 in the configuration manager the "ntdll.dll can't find" error went away. Remaining issue is that malloc/free throws a runtime error is some places but not in others. Change to new/delete formats solved this issue.
I get the occasional access violation when I start my wxwidget application:
Unhandled exception at 0x0267894A (atigktxx.dll) in MyApp.exe: 0xC0000005: Access violation reading location 0xFEEEFEEE.
This is strange since is happens when I start the Release build. Shouldn't 0XFEEEFEEE point to uninitialized memory in Debug mode?
I usually get rid of the error by rebuilding my project (only).
So there's not really a chance to reproduce the error.
Has anyone come across this? I use wxGLCanvas widgets in my programm.
The first thing to do is to find out where exactly this access violation happens and you should be able to do this by choosing to break at Win32 exceptions when you run the program under debugger.
If it happens deep inside ATI OpenGL driver, it would seem to indicate yet another weirdness in ATI code and it wouldn't be the first one, e.g. it's also known to call CRT functions with invalid parameters.
OTOH it's also possible that you really pass an invalid parameter to some OpenGL function and in this case the stack backtrace should give at least some information about which function and which parameter it is.
I have just started programming in allegro, but the first simple program i wrote to check it is in working order returns the error:
"Unhandled exception at 0x0F4C590B (allegro-5.0.7-monolith-md-debug.dll) in C++ Setup.exe: 0xC0000005: Access violation reading location 0x00000000."
I have looked for solutions but i cant find any, and yes, i have made sure it's 5.0.7 i have installed and linked to.
I have tried uninstalling and re-installing Allegro 5 and still do not know where the problem lies.
Access Violation errors are very rare and always related to the individual computer on which they occur. They are not errors in the ExpressMaintenance software but rather the result of something not functioning right on the system that causes the program to lose its place in memory. Usually an Access Violation results following some other error and it is the preceding error that is of significance.
Again, Access Violation errors are rare and always relate to the individual computer operating software or settings. The exact cause of the error can be difficult to find. Common causes typically are one one of the following:
Corrupt or insufficient version of Windows.
Insufficient RAM memory or system requirements.
Old or bad version of Microsoft Data Access Components (MDAC). See below.
Insufficient virtual memory allocated for large queries and data in memory.
Source
At runtime, when myApp.exe crashes i receive "Unhandled Win32 exception" but how would i know which exception was occurred? where did something went wrong?
For a Native C++ app see my earlier answer here: Detect/Redirect core dumps (when a software crashes) on Windows for catching the unhandled exception (that also gives code for creating a crash dump that you can use to analyse the crash later. If the crash is happening on a development system then in Visual Studio (I'm assuming you're using that, if not other IDEs will have something similar), in Debug/Exceptions tick the 'Thrown' box for 'Win32 Exceptions'.
Typically, Windows will give you several hexadecimal numbers as well. Chances are that the exception code will be 0xC0000005. This is the code of an Access Violation. When that happens, you also will have three additional bits of information: the violating address, the violated address, and the type of violation (read, write or execute).
Windows won't narrow it down any further than that, and often it couldn't anyway. For instance, if you walk past the end of an array in your program, Windows likely won't realize that you were even iterating over an array. It just sees "read:OK, read:OK, read:out of bounds => page fault => ACCESS VIOLATION". You will have to figure that out from the violating address (your array iteration code) and the violated address (the out-of-bounds address behind your array).
If it's a .Net app you could try to put in a handledr for the UnhandledException event. You can find more information about it and some sample code here.
In general it's a good sign that your exception handling is broken though, so might be worth going through your code and finding places that could throw but where you don't handle exceptions.
Use the debugger. You can run the program and see what exception is been thrown that kills your application. It might be able to pinpoint the location of the throw. I have not used the VS debugger for this, but in gdb you can use catch throw to force a breakpoint when an exception is thrown, there should be something similar.
My application crashes after running for around 18 hours. I am not able to debug the point in the code where it actually crashes. I checked the call stack- it does not provide any information as such. The last few calls in the call stack are greyed out-meaning I cannot see the code of that part-they all belong to MFC libraries.
However, I get this 'MicroSoft Visual Studio' pop-up when it crashes which says :
Unhandled exception at 0x7c809e8a in NIMCAsst.exe: 0xC0000005:
Access violation reading location 0x154c6000.
Could the above information be useful to understand where it is crashing.Is there any software that could tell me a particular memory address is held by which variable in the code.
If you can't catch the exception sometimes you just have to go through your code line by line, very unpleasant but I'd put money on it being your code not in MFC (always is with my bugs). Check how you're using memory and what you're passing into the MFC functions extra carefully.
Probably the crash is caused by a buffer overflow or other type of memory corruption. This has overwritten some part of the stack holding the return address which has made the debugger unable to reconstruct the stack trace correctly. Or, that the code that caused the crash, you do not have correct sybols for (if the stack trace shows a module name, this would be the case).
My first guess would be to examine the code calling the code that crashed for possible issues that might have caused it. Do you get any other exceptions or error conditions before the crash? Maybe you are ignoring an error return? Did you try using the Debug Heap? What about adplus? Application verifier to turn on heap checks?
Other possibilities include to run a tool like pclint over the code to check for obvious issues of memory use. Are you using threads? Maybe there is a race condition. The list could go on forever really.
The above information only tells you which memory was accessed illegally.
You can use exception handling to narrow down the place where the problem occurs, but then you need at least an idea in which corner to seek.
You say that you're seeing the call stack, that suggests you're using a debugger. The source code of MFC is available (but perhaps not with all vc++ editions), so in principle one can trace through it. Which VC++ version are you using?
The fact that the bug takes so long to occur suggests that it is memory corruption. Some other function writes to a location that it doesn't own. This works a long time, but finally the function alters a pointer that MCF needs, and after a while MFC accesses the pointer and you are notified.
Sometimes, the 'location' can be recognized as data, in which case you have a hint. F.e. if the error said:
Access violation reading location 0x31323334
you'd recognize this as a part of an ASCII string "1234", and this might lead you to the culprit.
As Patrick says, it's almost definitely your code giving MFC invalid values. One guess would be you're passing in an incorrect length so the library is reading too far. But there are really a multitude of possible causes.
Is the crash clearly reproducible?
If yes, Use Logfiles! You should use a logfile and add a number statements that just log the source file/line number passed. Start with a few statements at the entrypoint (main event handler) and the most common execution paths. After the crash inspect the last entry in the logfile. Then add new entries down the path/paths that must have been passed etc. Usually after a few iterations of this work you will find the point of failure. In case of your long wait time the log file might become huge and each iteration will take another 18 hours. You may need to add some technique of rotating log files etc. But with this technique i was able to find some comparable bugs.
Some more questions:
Is your app multithreaded?
Does it use any arrays not managed by stl or comparable containers (does it use C-Strings, C/C++-Arrays etc)?
Try attaching a debugger to the process and have the debugger break on access violations.
If this isnt possible then we use a tool called "User mode process dumper" to create a memory dump of the process at the point where the access violation happened. You can find this for download here:
http://www.microsoft.com/downloads/details.aspx?FamilyID=E089CA41-6A87-40C8-BF69-28AC08570B7E&displaylang=en
How it works: You configure rules on a per-process (or optionally system-wide) basis, and have the tool create either a minidump or a full dump at the point where it detects any one of a list of exceptions - one of them being an access violation. After the dump has been made the application continues as normal (and so if the access violation is unhandled, you will then see this dialog).
Note that ALL access violations in your process are captured - even those that are then later handled, also a full dump can create a while to create depending on the amount of memory the application is using (10-20 seconds for a process consuming 100-200 MB of private memory). For this reason it's probably not a good idea to enable it system-wide.
You should then be able to analyse the dump using tools like WinDbg (http://www.microsoft.com/whdc/devtools/debugging/default.mspx) to figure out what happened - in most cases you will find that you only need a minidump, not a full dump (however if your application doesnt use much memory then there arent really many drawbacks of having a full dump other than the size of the dump and the time it takes to create the dump).
Finally, be warned that debugging access violations using WinDbg can be a fairly involed and complex process - if you can get a stack trace another way then you might want to try that first.
This is the cause of possible memory leak, there are various blogs could teach on checking for memory leaks in application, you simply make observations on Physical Memory of the process from Windows Task Manager, you could find at some stage where memory keep increasing & run out of memory. You can also try running with windbg tool to identify memory leaks in your code. I havent used this tool just giving some heads up on this.
This question is pretty old, and I've had the same problem,
but I've quickly solved it - it's all about threads:
First, note that updating GUI can only be done at the Main Thread.
My problem was that I've tried to handle GUI from a Worker Thread (and not a Main Thread) and i've got the same error: 0xC0000005.
I've solved it by posting a message (which is executed at the Main Thread) - and the problem was solved:
typedef enum {
WM_UPDATE_GUI
}WM_MY_MSG
// register function callback to a message
BEGIN_MESSAGE_MAP(CMyDlg, CDlgBase)
ON_MESSAGE(WM_UPDATE_GUI, OnUpdateGui)
END_MESSAGE_MAP()
// For this example - function that is not invoked in the Main Thread:
void CMyDlg::OnTimer()
{
CString str_to_GUI("send me to gui"); // send string to gui
// Update_GUI(str_to_GUI); // crashed
::PostMessage(hWnd, MyMsg::WM_UPDATE_GUI, (WPARAM)&str_to_GUI, 0);
}
HRESULT CMyDlg::OnUpdateGui(WPARAM wParam, LPARAM lParam)
{
CString str = *(CString*)wParam; // get the string from the posted message
Update_GUI(str);
return S_OK;
}