简体   繁体   中英

Exception thrown at 0x00007FF93E507A7A (ntdll.dll) .Access violation reading location 0xFFFFFFFFFFFFFFFF

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.

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).

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.

This could occur, when you do have multiplatform projects (ie 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 (ie 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.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM