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.
Related
Expression: header->_block_use == block_use || header->_block_use ==
_CRT_BLOCK && block_use == _NORMAL_BLOCK
What does this mean? It has something to do with a header?
I found in my code where after I step over it returns the debug assertion failure, just this one line of code works in other projects.
Is there a linker setting or c/c++ setting that I have to remove?
The assertion that you are hitting is part of the Microsoft Visual C/C++ runtime libraries, specifically related to the debug heap. Calling malloc/free and using the new/delete operators leads to calls to the CRT heap functions, which perform internal consistency checks using these assertions.
It's very likely that the assertion is hit as a result of a memory safety bug, for example trying to delete a garbage pointer, double-free, etc. If you are unable to find it, the ASAN tool can help by keeping closer track of memory operations and raising errors when your code does invalid things. Without these close checks, mistakes in your code can corrupt a data structure, and the crash could occur much, much later in unrelated code.
For Visual Studio, it involves a few steps: the "C++ AddressSanitizer" feature must be installed using the Visual Studio installer, and the address sanitizer must be enabled in the project properties under C/C++ -> General.
Languages such as C and C++ offer an assert(...expression...) facility that is typically used during debugging ... and omitted from the final delivered product. The ..expression... being "something that should always be False."
If the expression turns out not to be False, then it throws a runtime exception containing the exact text of expression. Which is exactly what a developer would like to see, because: "the whole idea is that this should never, ever, ever happen!"
Ordinarily, published versions of applications are compiled in such a way that all of the assert() statements are ignored: they are "no-ops."
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.
We have an application that is a C/C++/MFC desktop application, with some C++/CLI assemblies that allow us to access some managed code functionality. The app is crashing at startup in release mode only with the message
An unhandled exception of type 'System.TypeInitializationException' occurred in Unknown Module.
Additional information: The type initializer for '' threw an exception.
How can I go about debugging this scenario and what are the issues in mixing managed/unmanaged code? What special steps do I have to take to make them play nicely?
Things to suspect are:
Missing unmanaged DLLs. You can use Depends (from Sysinternals) and start profiling, but I've struggled to get good results in mixed-mode.
Make a native minimal test harness which has the same dependencies, and run that through Depends - you will get definitive information about missing DLLs.
Are you using obfuscation in your release build product?
The obfuscation software we use adds a field to types in evaluation mode. We have fixed offset structs, yet the new field doesn't get an explicit offset. This is an error which would be flagged up at compile time if it was in our own code. Since the obfuscator is dynamically patching the assembly, the CLR has no option but to fail to load the invalid type at runtime.
In my opinion (based on some trouble I have had) Matt Smith's comment is the most useful answer; actually, check 'Thrown' for all types of exception. Quite often the problem is a crash in the constructor of a global object. See also answer 5 at
http://www.codeproject.com/Questions/67419/The-type-initializer-for-threw-an-exception
which says (among other things):
Click Debug--> Exceptions and check ON all the Thrown checkboxes. This
will cause the debugger to stop on all first chance exceptions and
will help you find the error under the Type Initializer error that
you're seeing. If it is related to another assembly, as mine was, you
can use Microsoft's Assembly Binding Log Viewer tool to help determine
the problem.
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.
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).