Why program will not crash and could still execute After Access Violation?

Question

I am coding a C++ win32 app and encounter a weird appearance which is that access violation instruction will not always cause app crashed, It depends where the instruction inserted! Here is the case I encountered : I have used a third party library, and If I put *(int *0)=0; in one special overload function of that library, The program will not crash and some instruction will be skipped which result that the program run in a abnormal status. code like the below:

void CMainWnd::InitWindow(){
    //other constructions 
    (*(int *)0) = 0;//access violation
   //other construction which is under *(int *0)=0; in InitWindow scope will not be executed.
   //.....
}

I guess the library have used some SEH Technology, so search through the library codebase and not found any relative API used.

SO, WHAT HAPPENED???

----- split line ----------

Thanks everyone's response, after Daniel Sęk`s prompt. I add more detail to here. Here is crash function call stack.

duidemo_d.exe!crash() Line 73   C++
duidemo_d.exe!CMainWnd::InitWindow() Line 89    C++
DuiLib_d.dll!DuiLib::WindowImplBase::OnCreate(unsigned int uMsg, unsigned int wParam, long lParam, int & bHandled) Line 313 C++
DuiLib_d.dll!DuiLib::WindowImplBase::HandleMessage(unsigned int uMsg, unsigned int wParam, long lParam) Line 359    C++
DuiLib_d.dll!DuiLib::CWindowWnd::__WndProc(HWND__ * hWnd, unsigned int uMsg, unsigned int wParam, long lParam) Line 436 C++

here is how DuiLib_d.dll!DuiLib::CWindowWnd::__WndProc is invoked.Registers a window class which has WNDCLASS::lpfnWndProc=CWindowWnd::__WndProc for subsequent use in calls to the CreateWindow or CreateWindowEx function.

------split line-----

The reason for why I do this test is that I want to catch every unexpected thing happens in my program and dump it ,debug it ,figure out how it happened and solve it, finally reduce one bug. It seems that my catch method does not work well if exception happened in wndproc whatsoever exceotion code is. Here is the method how I create dump file.SetUnhandledExceptionFilter is called after WinMain.

SetUnhandledExceptionFilter((LPTOP_LEVEL_EXCEPTION_FILTER)CallBackCrashHandler);
//dump
LONG CallBackCrashHandler(EXCEPTION_POINTERS* pException)
{
//write dump
HANDLE hFile = CreateFile(gBugReport->m_dumpFilePath.data(), GENERIC_READ | GENERIC_WRITE,
    0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);

MINIDUMP_EXCEPTION_INFORMATION l_eInfo;
l_eInfo.ThreadId = GetCurrentThreadId();
l_eInfo.ExceptionPointers = pException;
l_eInfo.ClientPointers = FALSE;

MiniDumpWriteDump(
    GetCurrentProcess(),
    GetCurrentProcessId(),
    hFile,
    MiniDumpNormal,
    pException ? &l_eInfo : NULL,
    NULL,
    NULL);

CloseHandle(hFile);
return EXCEPTION_EXECUTE_HANDLER;
}

It has a few difference. It always will not cause app crash when access violation instruction in CMainWnd::InitWindow other than other scope — No.6, Oct 12 '17 at 04:29
@NickyC How to remove The Title：This question may already have an answer here？ It has a few difference. I said that It has just happened in CMainWnd::InitWindow, So It is not a undefined behaviour. — No.6, Oct 12 '17 at 04:36
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html — Jeremy Friesner, Oct 12 '17 at 04:49
@No.6 It is undefined behavior. Do you know some place that defines this behavior and says that code must crash? Because I don't. — David Schwartz, Oct 12 '17 at 04:51
Try `RaiseException` instead, possibly with the `EXCEPTION_NONCONTINUABLE` flag. — Harry Johnston, Oct 12 '17 at 05:26
Someone closed question so I paste it here. 1. You have somewhere SEH handler which just ignores exception. 2. You have active translation of SEH to C++ exceptions and these exceptions are eaten by `catch (...)`. **3. You are developing 32 bit application on 64 bit Windows system and exception is thrown in some callback (for example `WindowProc`). 32 bit application can't safely unwind stack when called from 64 bit kernel and exceptions are unfortunately swallowed.** Investigate if your case is my case #3. — Daniel Sęk, Oct 12 '17 at 06:19
@DanielSęk, Thanks, After I test， My problem belongs to your case #3, — No.6, Oct 12 '17 at 07:36
@No.6 I would recommend [WindowProc calback function](https://msdn.microsoft.com/en-us/library/ms633573(VS.85).aspx) **Remarks section** and [Crashing correctly](https://www.reddit.com/r/programming/comments/w4z6y/crashing_correctly_is_surprisingly_difficult_on/) — Daniel Sęk, Oct 12 '17 at 07:51
@DanielSęk, I add more detail to there, the network is so poor, so my response is so slowly. — No.6, Oct 12 '17 at 08:37
To prevent swallowing, wrap code in `WindowProc` with SEH `__try {} __except () {}`. [Structured Exception Handling C/C++](https://msdn.microsoft.com/en-us/library/swezty51.aspx) — Daniel Sęk, Oct 12 '17 at 08:45
See also [Mixing SEH and C++ Exceptions](https://blogs.msdn.microsoft.com/jaredpar/2008/01/11/mixing-seh-and-c-exceptions/) and [Structured Exception Handling SEH and C++ exception handling](https://blogs.msdn.microsoft.com/zhanli/2010/06/25/structured-exception-handling-seh-and-c-exception-handling/) — Daniel Sęk, Oct 12 '17 at 08:55
The unhandled exception filter only runs, in case the exception is indeed, well, unhandled. As explained in a comment above, the system does handle exceptions under certain circumstances. Besides, your `MiniDumpWriteDump` implementation is a guaranteed dead lock. See [this Q&A](https://stackoverflow.com/a/41433641/1889329) for details. In short: `MiniDumpWriteDump` must be called from a different process, as [documented](https://msdn.microsoft.com/en-us/library/windows/desktop/ms680360.aspx). — IInspectable, Oct 12 '17 at 09:13
This might be a better duplicate than the selected one: https://stackoverflow.com/q/1487950/886887 see also https://stackoverflow.com/q/11376795/886887 — Harry Johnston, Oct 12 '17 at 14:05
I used method from your link@DanielSęk, It works good. But after do more test, I draw a conclusion whether SetUnhandledExceptionFilter will work well is also relevant to WM_MESSAGE type under `WindowProc`. Because I found that **CallBackCrashHandler** can not catch exception under **WM_CREATE** Message in `WindowProc` , can catch exception under **WM_LBUTTONUP**.Message in `WindowProc`. — No.6, Oct 13 '17 at 02:23
Thank @Harry Johnston, I get a lot useful info from your link. — No.6, Oct 13 '17 at 02:29

Why program will not crash and could still execute After Access Violation?

0 Answers0