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.
Related
I tried enabling asan in project->properties->c/C++->Enable Address Sanitizer (Experimental) : Yes (/fsanitize=address).
I can then build my project, but when running it breaks at
extern "C" void __cdecl _initterm(blah blah) in initterm.cpp with Exception thrown at 0x00007FFFCD3B2EB8 (ntdll.dll) in gnomes.exe: 0xC0000005: Access violation writing location 0x0000053747340000.
I've been told by others that this is a thing that happens, and I should continue through it. It then moves to ~50 or so other exceptions somewhere within ntdll.dll or other window api files, before eventually getting to my program, where it errors at the first line of main: GTApplication *app = new GTApplication(); (the first line of my main) with Access violation writing location blah.
So I'm unsure how to interpret this information. Is there something wrong with my foundational windows API layers on my computer? or is that just unavoidable (if weird) behavior.
And does that mean I should interpret the first line of my program as also just a quirk of using asan? or is there something wrong with the allocation of my application object?
Am I using asan incorrectly?
I am facing the same exact issue, while building 64-bit applications (looking at the size of pointers listed in messages, it's the same case for You), using VS 16.8.3. Even for an application, that does literally nothing (returns 0).
If possible, consider building 32-bit version of the application and checking, if the problem persists. ASan doesn't report such issues for me for 32-bit binaries.
Address Sanitizer in VS is still experimental, and support for x86-64 is even less mature, than for 32-bit x86.
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.
currently I used SetUnhandledExceptionFilter() to provide callback to get information when an unhandled exception was occurred, that callback will provides me with EXCEPTION_RECORD which provides ExceptionAddress.
[1]what is actually ExceptionAddress is? does it the address of function / code that gives exception, or the memory address that some function tried to access?
[2]is there any better mechanism that could give me better information when unhandled exception occured? (I can't use debug mode or add any code that affect runtime performance, since crash is rare and only on release build when code run as fast as possible)
[3]is there any way for me to get several callstack address when unhandled exception occured.
[4]suppose ExceptionAddress has address A, and I have DLL X loaded and executed at base address A-x, and some other DLL Y at A+y, is it good to assume that crash was PROBABLY caused by code on DLL X?
(1) The ExceptionAddress is the address of the code that caused the exception. In case of an access violation error (0xC0000005) one of the additional arguments of the exception record holds the address from which a read or a write was attempted and another argument tells if it was a read or a write. This is documented in the link you provide in the question.
(2) no. additionally, adding debug information to a release build doesn't affect performance. You can verify this and see for yourself.
(3) dbghelp.dll provides a complete library to investigate crashes. among athers there is StackWalk64 which allows you to get the complete stack of the crash.
(4) calling GetModuleHandleEx with the ExceptionAddress as an argument will get you the handle of the dll where the offending code resides. As to the question of which DLL CAUSED the crash, this depends on your definition of "CAUSED". A crash which occur in one dll can be the result of a bug in a completely different and unrelated dll.
Not direct answer to your question, but possibly this is what you need:
http://www.codeproject.com/KB/debug/postmortemdebug_standalone1.aspx
Post-mortem debugging is the way to find exception place when the program runs in Release build on a client computer.
Also, not a direct answer to your question, but I think it could help you:
http://www.codeproject.com/KB/applications/blackbox.aspx
It will produce a readable output to screen or file, which will give you a stack output to find the place where the exception occured along with other useful information.
It worked good for me.
There is also an improved version named "Blackbox revised". Can't find the website right now, though.