I've got a strange behaviour on my workstation...
I'm experiencing a crash when launching debugger on a very simple program (basically the template windows application one...) and i got a exception
Exception thrown at 0x000000007719759E (ntdll.dll) in test2.exe:
0xC0000005: Access violation writing location 0x0000000000000000.
when I look in the stack trace in disassembly I am in RtlActivateActivationContextUnsafeFast (from ntdll.dll I guess)
0000000077197591 je RtlActivateActivationContextUnsafeFast+4Eh (07719755Eh)
0000000077197593 jmp string "Enabling heap debug options\n"+10B68h (0771E7B58h)
0000000077197598 cmp qword ptr [r8+8],rdx
000000007719759C je RtlActivateActivationContextUnsafeFast+6Ah (07719757Ah)
000000007719759E mov qword ptr [r9],rax
the exception occurs at the 000000007719759E
any idea on how to fix this? reinstalling VS2017 didn't help, and memory is fine (checked by memtest86)
thanks a lot
Full Stack trace of the buggy thread :
> ntdll.dll!RtlActivateActivationContextUnsafeFast() Unknown
ntdll.dll!LdrpProcessStaticImports() Unknown
ntdll.dll!LdrpLoadDll() Unknown
ntdll.dll!LdrLoadDll() Unknown
0000000000060124() Unknown
I had this similar issue with VS 2017 v15.9.11 for 64-bit exe.
If this is happening only with 64-bit version, this fix worked for me.
Go to Tools >> Options >> Debugging >>
Check this option - "Automatically close the console when debugging stops"
Related
I'm currently using Qt Creator 4.4.1 with Qt 5.9.2 and the MSVC 2015 32/64 Bit compilers to create a DLL on Windows 7.
In Qt Creator under
Projects -> Build & Run -> Desktop Qt 5.9.2 MSVC2015 xxbit -> Run -> Executable
I've specified the host application, that loads my DLL, so when I hit F5 this app gets executed and loads my DLL without a flaw.
However, on loading, the main app raises an exception which I have no hands-on, making Qt Creator showing up a message box with the following content:
The inferior stopped because it triggered an exception.
Stopped in thread 0 by: Exception at 0x60251637, code 0xc0000005: write access violation at: 0x1, flags=0x0 (first chance).
I now have to close the message box and hit F5 again to proceed.
Because I have to do this for every test run, again and again, it becomes really annoying. So, is there a simplest way to tell CDB from Qt Creator to ignore only that specific type of exception?
Look at the call stack, find the relevant code and see what it does. You should find a try ... catch ... around that line. See whether you can avoid the exception in some way, typically by introducing an if ... else ....
If you cannot avoid it, and you made sure it's really safe to ignore it, start CDB with command line argument -c "sxn c0000005" or the equivalent -c "sxn av", where AV is short for "access violation". You can use sx to see all exception settings.
I encountered the same problem, the problem may be caused by the variable is not initialized, for example:
QLable *lable;
If you forget to allocate memory for this variable, it will cause this error.
lable = new QLable(this);
I think you should check your variables.
This is about a week I am trying to solve my problem and I really need help. I hope someone will find what is wrong with my setup.
(I am french so I apologize for any English mistakes)
CONTEXT
I have a Visual Studio Project which has been developed from OpenFace, a free open-source library, downloaded at that address:https://github.com/TadasBaltrusaitis/OpenFace . "Developed from" because the project just uses the code of OpenFace. I precise that the project was not made by me, I checked out from a private repository.
PROBLEM
My project build an executable but not run, stopped by an illegal instruction at the file exe_common.inl (don't know what this file is) at the line 223, before getting into in the entry point of my programm (cout << " " << endl at the very beggining of the main() function is not executed).
Here is the guilty line:
__scrt_current_native_startup_state = __scrt_native_startup_state::initialized;
Here the stack trace at that breakpoint:
CamFeaturesExtractor_Affich.exe!dlib::get_global_clock(void)
CamFeaturesExtractor_Affich.exe!00007ff63493114e()
ucrtbase.dll!_initterm()
CamFeaturesExtractor_Affich.exe!__scrt_common_main_seh() line 223
kernel32.dll!BaseThreadInitThunk()
ntdll.dll!RtlUserThreadStart()
Here the exact message exception:
Unhandled exception at 0x00007FF63499C5B7 in CamFeaturesExtractor_Affich.exe: 0xC000001D: Illegal Instruction.
WHAT I TRIED
Change VS 2017 to 2015
Build in Debug/Release in x64/x86
Change Enhanced Instruction Set in Configuration Properties > C/C++ > Code Generation to AVX, AVX2, SSE, SSE2, IA32, No Set...
Disable any optimization
That problem doesn't appear on some more recent computer (check below for my spec) so my first guess is to say that is a hardware problem. The exception is not triggered on Intel Cord Duo I5 (with same model of computer than mine). Here is my specs:
Edition : Windows 10 Professionel
Version : 1511
OS Version : 10586.679
Processor : Intel(R) Celeron(R) CPU 2950M # 2.00 GHz 2.00 GHz
RAM : 4G
System type : OS 64 bits, processeur x64
If the problem comes from my poor processor doesn't have the instruction, is there a workaround or I need to change my computer ?
Let me know if you need some informations I forgot to provide and thanks in advance if you try to help me...
EDIT
The part of disassembly where the code stop as requested:
00007FF6D635B5BD mov eax,0FFh
00007FF6D635B5C2 jmp __scrt_common_main_seh+167h (07FF6D635B6B3h)
_initterm(__xc_a, __xc_z);
00007FF6D635B5C7 lea rdx,[__xc_z (07FF6D639ED98h)]
00007FF6D635B5CE lea rcx,[__xc_a (07FF6D639EC10h)]
00007FF6D635B5D5 call _initterm (07FF6D635C4B0h)
__scrt_current_native_startup_state = __scrt_native_startup_state::initialized;
00007FF6D635B5DA mov dword ptr [__scrt_current_native_startup_state (07FF6D64162E0h)],2
}
else
00007FF6D635B5E4 jmp __scrt_common_main_seh+0A2h (07FF6D635B5EEh)
{
has_cctor = true;
00007FF6D635B5E6 mov sil,1
00007FF6D635B5E9 mov byte ptr [has_cctor],sil
}
__scrt_release_startup_lock(is_nested);
00007FF6D635B5EE mov cl,bl
00007FF6D635B5F0 call __scrt_release_startup_lock (07FF6D635B368h)
Note that exe_common.inl, as said in comment, is a Read-Only Visual Studio file located in C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\crt\src\vcruntime\exe_common.inl. I made a gist if you want to see it: https://gist.github.com/AlEmerich/281994ebbcde7d3bac88f21a85de96e2
LAST EDIT:
I don't know if it is the right way to do but I let know the audience that I give up on that problem by trying to change my computer. I have now a more recent hardware and it throws any errors. Thanks anyway for your help !
For me, remove _CRT_SECURE_NO_WARNINGS from Release Mode and try to build in Release Mode.
It should contain some errors, fix them and than it should be fine.
I'm trying to build a game in sfml under windows 10.It shows successful at the time of building.whenever i debug the solution it shows the error message like:
Unhandled exception at 0x00007FFA622C21F9 (sfml-system-2.dll) in picpuz2.exe: 0xC0000005: Access violation reading location 0x0000000000000019.
Under call stack the program stopped at the code:
window.create(sf::VideoMode(300, 300, 32), "PICPUZ");
This is my code:
Please follow the tutorials closely. If you are doing a debug build, you should link with the dlls that end in -d for debug.
For example sfml-system-d-2.dll
Linking release and/or debug to the wrong configuration (release to debug or debug to release) will result in unpredictable crashes.
I have a C++ windows application that was done by another programmer, that I had to remove one line of code. After rebuilding the application with visual studio 2013 it crashes with this in the event log:
Faulting application name: WaveStream.exe, version: 0.0.0.0, time stamp: 0x536122da
Faulting module name: WaveStream.exe, version: 0.0.0.0, time stamp: 0x536122da
Exception code: 0xc0000409
Fault offset: 0x0000bd7f
Faulting process id: 0x8b8
Faulting application start time: 0x01cf6490aee4f557
Faulting application path: C:\Program Files (x86)\PS Audio\WaveStream.exe
Faulting module path: C:\Program Files (x86)\PS Audio\WaveStream.exe
Report Id: efe00d42-d083-11e3-a513-bc305baf9e1e
The application uses QT 4.7.4, and compiles with no errors. I am an embedded systems programmer and have very little windows programing experience. What can I do to figure out why it is crashing?
Dennis
The clue to the problem is in the exception code: 0xc0000409
0xc0000409 means STATUS_STACK_BUFFER_OVERRUN.
In other words, something in your program is writing past the current stack frame, corrupting data on the stack. The program has detected this and rather than let it continue, has thrown an exception.
How do you debug this? There are a few options:
1) Rerun this in the debugger and watch it crash, workout what failed.
2) If you've got a crash dump of this, load that in the debugger, hit F5 and workout what failed.
3) If you don't have a crash dump you can still attempt to find out the cause of the crash if you know the absolute address of the crash (and know the module always loads at a fixed address), or if you know the offset of the crash location from the start of the faulting module.
The crash information above tells you the offset into the faulting module of the crash. That's reported in the Fault Offset field. In your example, that is an offset of 0x0000bd7f.
If you've got the original dll/exe and it's matching PDB, just load it into DbgHelpBrowser, go to the Query menu, choose "Find Symbol with DLL Relative Address..." then enter the offset in the field and click "Find Symbol...". The display will move to show you the nearest matching symbol, highlighting the symbol and display any info about parameters, line numbers and source code.
It's a free tool. You can get it here:
https://www.softwareverify.com/cpp-dbghelp-browser.php
Disclaimer. I wrote this tool to do just this job for our in house use. We recently made it available for everyone else. I found this question while trying to understand what the exception code 0xc0000409 meant.
Try to create a crash dump for the application. See this StackOverflow question and the MSDN documentation on how to do that. Once you have the crash dump file, open it in the Visual Studio debugger and you will be able to see the exception and call stack for the exception, which should help.
!analyize -v in windbg
It will do a lot of work for you.
I've got a kind of curious problem here, and to be quite honest I have no idea what's causing it. For whatever reason, when I debug my application from Qt Creator my application runs just fine without any exceptions, but when I only run the application, I get a write access violation exception (as follows)
(1f68.1ea8): Access violation - code c0000005 (first chance)
Exception at 0x77da2073, code: 0xc0000005: write access violation at: 0x1, flags=0x0 in ntdll!RtlpLowFragHeapFree
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00720065 ebx=82130074 ecx=006f007f edx=0000006f esi=01fa5fb6 edi=82130000 eip=77da2073 esp=0012cc70 ebp=0012cca4 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010202
ntdll!RtlpLowFragHeapFree+0xc5:
77da2073 8930 mov dword ptr [eax],esi ds:0023:00720065=????????
Exception at 0x77da2073, code: 0xc0000005: write access violation at:
0x1, flags=0x0
NOTE: INFERIOR SPONTANEOUS STOP
State changed from InferiorRunOk(11) to InferiorStopOk(14).
When I comment out the line it breaks at (after running, then manually attaching the debugger) it just seems to bring me to a different line for the same issue. The tool chain I'm using is MSVCC, with the additional flags:
QMAKE_CFLAGS_RELEASE += -Zi
QMAKE_CXXFLAGS_RELEASE += -Zi -g
QMAKE_LFLAGS_RELEASE += /DEBUG /OPT:REF
To recount, here's what I've tried:
Debugging with debug configuration - ok
Running with debug configuration - ok
Debugging with release configuration - ok
Running with release configuration - exception
Are you double freeing something? A quick search brings up this article about double freeing.
I'm not sure what the MSVCC equivalent might be (the article mentions a tool called gflags.exe), but under Linux with GCC you can use a program called Valgrind with the memcheck tool to find this sort of problem.