This is kinda a very low-level type question, but maybe someone here has some insight...
I'm having an issue where unhandled SEH exceptions (such as Access Violations) are seemingly being caught at the Win32 message dispatch level, rather than terminating the program. I found the following reference blog, which explains the problem, but in the context of WM_TIMER messages only: http://bugswar.blogspot.com/2010/07/why-its-not-crashing.html
I'm experiencing the issue with Win 2008R2, and on "normal" messages (eg: WM_COMMAND, etc.). I suspect it might be Windows trying to "help" by masking exceptions, but I want it to error out; the "continue and ignore" behavior is causing problems with the application in general. I realize I could try to wrap every function in a try/catch, and use the compiler option /EHa to convert SEH exceptions into C++ exceptions (which is itself very discouraged and dangerous), but this is obviously sub-optimal.
According to the referenced blog, there's a flag in the AppCompatFlags2 in the TIB structure (http://en.wikipedia.org/wiki/Win32_Thread_Information_Block) which can cause the Win32 handler to not catch/discard the SEH exception, but I have no idea how to set/enable it. Anyone have any insight on this? Is there an AppCompat setting I can enable to have Windows not catch and ignore exceptions?
I think it's by design, but obviously it was not considered carefully enough. Perhaps ill-advised attempt to make some legacy application "behave".
You can override this behaviour in Windows 7 SP1; I wrote more on this in this stackoverflow answer.
I don't know how the compatibility settings affect this particular aspect, but you can choose among several compatibility modes from the Properties page of an EXE in Explorer (on W7 and Vista, at least). I seem to recall that you can also request a specific one from the manifest.
Related
I seem to remember at a previous job, when tracking down a certain bug I added a call to a function that made sure that floating point errors got reported in some way. I don't remember exactly how - probably a callback, or maybe it caused a break in Visual Studio immediately when it happened.
Tried searching for this but got nothing. Does this ring a bell for anyone? This is for a Windows game, if that matters.
(I'm not talking about enabling first-chance exceptions in Visual Studio, I want to catch it "live" as well).
It's called the floating-point environment. References:
http://en.cppreference.com/w/cpp/numeric/fenv (C++11)
http://pubs.opengroup.org/onlinepubs/009604599/basedefs/fenv.h.html (Unix)
To get exceptions to immediately halt your program, use platform-specific functions:
http://www.gnu.org/s/hello/manual/libc/Control-Functions.html (glibc)
http://msdn.microsoft.com/en-us/library/e9b52ceh.aspx (Windows)
also: http://msdn.microsoft.com/en-us/library/5z4bw5h5.aspx to get C++ exceptions; I think this is what you were after.
If I'm creating a new project in unmanaged C++, Visual Studio 2008 or greater, which exception handling model do I want to go with?
I understand that /EHa option results in less efficient code, and also catches SEH exceptions, right?
So I have been steering clear of that option and typically going with /EHsc, so that I'm only catching C++ exceptions that are actually thrown and not catching access violations and other structured execptions, in catch(...) handlers. If there is an access violation in my code, I don't want it being masked by a catch(...) {}.
I code with others who want catch(...) {} to do nothing and they even want it to do it if there is an access violation, which seems like a really bad idea to me. If there is a bug due to bad coding, you don't want to stick your fingers in your ears and loudly say "La la la la la!" so that you don't have to have the program crash? In fact, if the code is now in a bad state because of a coding error, do you really want the code to continue?
So my general thought is that /EHa creates larger/slower code and it allows programmers to get away with writing code that if a fatal bug is present, it will continue to run in an undefined state.
BTW, I'm talking about applications and service code which is what we are writing for the most part. Not low level device drivers or anything like that.
Please weigh in with your thoughts.
/EHa does two things. First and foremost, it suppresses an optimization that omits exception filters that automatically call the destructors of local class variables if the code analyzer cannot see any code that might throw a C++ exception. This makes stack unwinding safe for any kind of exception, not just a C++ exception. Overhead for these exception filters is time on x86 and space on both x86 and x64.
And yes, it alters the behavior of catch(...), it now also filters any SEH exception, not just C++. This is indeed a gamble because you catch all the really nasty stuff, the asynchronous hardware exceptions. Although I personally don't think that catching all C++ exceptions is very defensible either, you still have but a vague idea to what degree the program state got mutated and why it failed.
Realistically, you'll need to switch to using __try/__except so that you can write your own exception filter and avoid catching the bad ones. The exception code for C++ exceptions is 0xe04d5343 ("MSC"). Using _set_se_translator() would be another approach.
I use /EHa because it's safe with .NET interop , whereas /EHsc may not be; see Destructors not called when native (C++) exception propagates to CLR component for example.
However, if for a specific bit of code the extra performance really matters and you don't need .NET (or whatever else) compatibility, then sure, /EHsc sounds fine.
Neither /EHsc nor /EHa catch most memory errors, so using these to catch access violations is a hopeless case.
This question is about a C++ library for Windows and we use Visual C++ as our compiler.
We enable exception handling compiler option in our library. We also use throw/catch in a few places.
One of our customers says that they disable exception handling option in their application. Now the question is, whether they would experience any problems if they use our library with their application.
If any exceptions can get emitted out of your library than yes indeed they could have problems. Consider if your library threw an exception that wasn't caught and then propagated back to the application. Since the app isn't built with support for exceptions it won't know how to handle it and most likely will behave incorrectly. If you're lucky it'll crash rather than silently failing in some obscure way.
If you catch all exceptions internally within the library and use only return codes to signal problems to the outside world then things may work out ok (note that this means constructors of public API classes can't throw, and throwing is the only way they can report problems).
I've recently implemented some vectored exception handling to catch errors in our software. This is especially useful as we've just converted from vc6 to vs2005. We're encountering a few problems with the use of the STL library (generally people doing things they shouldn't). I'm trying to catch these errors with my vectored exception handler.
However this doesn't seem to get called, instead these errors are internally processed by the Microsoft Visual Studio C Runtime library.
My question is;
Is there a way to turn off the runtime error checking and get the exceptions passed to the VE handler?
Thanks
Rich
http://msdn.microsoft.com/en-us/library/aa985973%28VS.80%29.aspx
#define _SECURE_SCL 1
#define _SECURE_SCL_THROWS 1
The above allows me to throw exceptions.
You can turn off the additional run-time checks. However, not all errors this catches will result in a crash which you can intercept.
On a sidenote: These checks often consume significant performance and are, by default, not turned off in release builds.
#define _SECURE_SCL 0
It's best to do this via project settings, as you could get nasty linker problems if the setting differs within or between files.
I ran into this problem a while ago and it took me some time to wrap my head around what they are doing in their runtime. I would recommend reading "Migrating from Previous Versions of Visual C++" on MSDN at least twice. Then read "Extensions to the C Library, Part I: Bounds-checking interfaces (ISO/IEC TR 24731-1)". The latter is the standard that most of the parameter checking stuff is based on.
Once you understand what they are up to, just define _CRT_SECURE_NO_DEPRECATE, _SECURE_SCL, and _SECURE_SCL_THROWS in your project settings. Then make sure that you have "Enable C++ Exceptions" set to "Yes with SEH Exceptions (/EHa)" and "Basic Runtime Checks" set to "Default" in your project. At least, that is what is working for us right now. It did take some time to remove the incorrect code that we had created under VC6 though.
The most important thing that you can do is set aside a few weeks and really dig into what the various options and macros do. Then figure out what works with your code. We didn't do this early enough and it hurt a lot once we had some "bad builds" make it out of engineering.
Is there a way catch an exception like access violation and get information about on which line an exception occurred? This would be very good for debugging purposes, especially for testers..
My environment is Windows with VC++ on VS2008
An access violation is not an exception in C++ terms, so the answer is in general "no". Concieveably, your specific implementation might have a feature that turns access violations into C++ exceptions - you need to specify what compiler & platform you are using.
In case you really want to log info about C++ exceptions (AV is not one) thrown from your code, you can use macros __FILE__ and __LINE__ within constructors of your exception types.
If you catch the SEH exception using a __catch handler you can then access the thread context at the time of the exception and then use StackWalk64 to dump the call stack at the point where the exception was generated. Note that as I mentioned here: Printing the stack trace in C++ (MSVC)? StackWalker by Jochen Kalmbach [MVP VC++] and available on codeproject is probably the easiest way to do this. It wraps up all of the details of dealing with the underlying StackWalk64 API.
Alternatively you could the same solution that I proposed here: How to catch divide-by-zero error in Visual Studio 2008 C++? to convert the Windows Structured Exceptions into C++ exceptions and capture the stack trace as shown above at the point where you translate the exception. This would give you a C++ exception with a stack trace like you get in C# or Java.
I'm not sure why testers would need to know which line an exception occurred.
The developers might want to know, though. But a better approach is the following:
Include the information about class and method with each PROGRAM exception. These are exceptions that should NOT have happened.
This should be output by whatever logs your exceptions. Your program does catch and log every exception, doesn't it? If not, it should.
Make sure your methods are small enough that the above is enough information to easy track down a bug. If you need line information as well, then your methods are too large and your exceptions are not specific enough.
In MSVC you can set the debugger to break when any exception or things like an access violation happen buy going to debug->Exceptions and checking the appropriate box.
Note that access violations are not C++ exceptions and will be handled differently on different systems. In Windows you can trap them with a structured exception handler. In unixy systems it will usually core dump. You can usually get a stacktrace from that.
For msdev / Windows, during development, always have your linker generate a MAP file.
When Windows throws up an access violation, and it's your code (not library), you can use the address to match up function / data in the MAP file and get within a few lines of the offender. At a minimum, you'll know the function/method.
That's really a compiler question.
If you want to know if it is possible for a compiler to provide, the answer is yes. I know multiple Ada compilers that provide tracebacks for unhandled exceptions, so it is clearly possible. This includes the gcc-based Gnat, so if the C++ compiler uses any of the same facilities for its exceptions, the support for doing that should already be there.
On unix type systems a Access violation generates a SEGV or BUS signal. This normally causes the application to core dump. You could always write your own signal handler. From there you could probably generate a stack-dump using the glibc before core dumping.
A core dump generally give you all this for wasy analysis in gdb.
My answer refers to Windows only. You have quite a few options:
Without changing your code -
Avoid catching exceptions (at least ones you do not expect), and let your app just crash. Configure good ol' dr. watson (drwtsn32.exe) to create a crash dump, and open that dump in your debugger. You'll get the exact line of code there.
Use adPlus (from the windbg installation) to monitor your app's run, and create a dump when an exception is thrown.
From within your code, you can -
Easily walk the stack when a structured exception is thrown. See Jochen Kalmbach's stack walker for example.
Use this weird hack to walk the stack when a C++ exception is thrown.
Finally, quite a lot of questions have been asked here on this issue. Look around, and you'll get additional answers.
On one project I worked on, the root class of the exception hierarchy used captured a callstack in the constructor in case that information was needed later for debugging after the exception was caught. It was a decent idea, although if you're catching and 'handling' the exception, exactly when it was thrown shouldn't really matter all that much.
To put it another way, if you care about this info (context of "who" threw it), you probably shouldn't be using an exception to report this condition, or potentially you shouldn't be catching the exception in the first place. Uncaught exceptions cause crashes, giving you a crash dump at the point the exception was thrown.
On windows, the C runtime system function _set_se_translator() takes a simple static function with signature
void f(int, EXCEPTION_POINTERS*)
neither of which argument you totally need. In the body of f, throw your favorite exception. Call the function near the beginning of your program. The documentation is reasonable for microsoft.
You can do all manner of additional stuff with this function.
The google breakpad project has many good things. Among them are means to convert a crash address to file, line, and function name using build symbols and the debuginfo dll.