I have a C# application that calls a mixed mode C++ dll. I enabled dump generation via HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps.
When the dll accesses invalid memory, the runtime converts the win32 exception to a managed System.AccessViolationException, and unwinds the stack before generating the dump, destroying the native stack information. I could catch the exception myself before .net gets at it and generate the dump manually, but running code on an already corrupt program could hang it, according to the msdn. So, how can I disable SEH translation?
You cannot disable that. The CLR will not unwind the stack unless you catch the exception. Make sure you don't. This needs to go through an AppDomain.UnhandledException event handler. The essential function you need is Marshal.GetExceptionPointers(), that's the one that will pinpoint the exception when you open the minidump.
You'll find resources in my answer in this MSDN forum thread and this pinvoke.net snippet, should be enough to cobble your own together.
Related
I use a crash reporting feature that allows the user to submit a crash report if the application crashed with an uncaught exception.
After adopting C++20 coroutines entered the application.
If there is an unexpected exception thrown in a coroutine the exception is caught before it is rethrown.
This causes crashreports to not show the stacktrace needed to figure out what happened, but only the stacktrace to the coroutine that rethrew the exception. This basically makes any crash reporting useless.
As far as I could find there is no way to prevent the catching of any exceptions by the coroutine because it is a required part of the design.
Is there a way to improve this I cant see?
I am curious because I found nobody else complaining yet. :->
Edit: To clarify the app is running on Windows, I mean the stacktrace of a minidump that is created at the point of the unhandled exception using: SetUnhandledExceptionFilter + MiniDumpWriteDump
C++ does not have standard stack tracing yet, so there is no nice builtin way to do this.
However, there are ways, which rely on keeping information in the promise objects.
Clang has documentation for some common debugging methods for coroutines.
The best solution we have found is as follows (Windows specific!):
Until now we used SetUnhandledExceptionFilter at the start of the app to set an exceptionfilter function that writes a minidump.
Instead we now use _set_se_translator.
If we want the program to just crash (f.e. if windows is set to write dumps) we set a function which calls std::abort.
If we want to handle it interactively we set a function which asks the user whether to send a minidump, the dump is written as before at this point.
Both cases provide the full callstack in the dump.
The only downside remaining is we cant let the program crash for "normal" exceptions to dump, this was possible before. But the "most important" exceptions (f.e. access violations) work.
we are using Sikuli with Java (Sikuli 1.1.1), but we are running into java.lang.ThreadDeath exception for a new client. In Java Configuration, we have selected mix code of Enable - hide warning and run with protections. Has anyone run into this issue before and what is the reason and possible fix?
Somewhere in the code Thread.stop() is being called.
According to the documentation don't do this! It releases all locks held by that thread may cause locked objects to be accessed in inconsistent state.
I would like to have my code create a dump for unhandled exceptions.
I'd thought of using the SetUnhandledExceptionFilter. But what are the cases when SetUnhandledExceptionFilter may not work as expected. For example what about stack corruption issues when, for instance, a buffer overrun occurs on stack?
what will happen in this case? are there any additional solutions which will always work?
I've been using SetUnhandledExceptionFilter for quite a while and have not noticed any crashes/problems that are not trapped correctly. And, if an exception is not handled somewhere in the code, it should get handled by the filter. From MSDN regarding the filter...
After calling this function, if an exception occurs in a process that
is not being debugged, and the exception makes it to the unhandled
exception filter, that filter will call the exception filter function
specified by the lpTopLevelExceptionFilter parameter.
There is no mention that the above applies to only certain types of exceptions.
I don't use the filter to create a dump file because the application uses the Microsoft WER system to report crashes. Rather, the filter is used to provide an opportunity to collect two additional files to attach to the crash report (and dump file) that Microsoft will collect.
Here's an example of Microsoft's crash report dashboard for the application with module names redacted.
You'll see that there's a wide range of crash types collected, including, stack buffer overrun.
Also make sure no other code calls the SetUnhandledExceptionFilter() after you set it to your handler.
I had a similar issue and in my case it was caused by another linked library (ImageMagick) which called SetUnhandledExceptionFilter() from its Magick::InitializeMagick() which was called just in some situations in our application. Then it replaced our handler with ImageMagick's handler.
I found it by setting a breakpoint on SetUnhandledExceptionFilter() in gdb and checked the backtrace.
I have an exception that is being thrown in Grails. Looking at the stack trace is helpful because I can see where the code bombed, but it turns out it is only bombing for one record out of hundreds, so it would be helpful to know what the values of the variables in memory are at the time of the exception. For example, in Visual Studio, when an Exception occurs, everything is paused on the line that throws the exception and all variables in memory are available to look at.
Is there anything like this for Grails (or Spring Source Tool Suite/Eclipse)? Is there a way to dump all variables to standard out? Thanks.
It sounds like you want to set an exception breakpoint, one that is triggered only when a particular type of exception is thrown.
Also, if you are using STS you can set conditional breakpoints in groovy code (and of course you can set conditional breakpoints in Java in either STS or Eclipse, but only STS allows this for Groovy).
"Hundreds" is not a number that is unmanageable. Can you connect to your application with a remote debugger and attach a breakpoint? In Intelli-J, you can start a server in debug mode; unsure how you do it in eclipse STS/vanilla grails, aside from deploying a war into a tomcat container with remote debug connections enabled.
I am using Enterprise Library's DAAB to access a database, both with ExecuteReader and ExecuteNonQuery. The problem is that these methods do not have exceptions thrown documented... How can I, then, know which exceptions should I catch?
I agree with WebTurner, I'm guessing a good place to start would be which database your connecting to, so if an ms sql database I'm guessing a couple of (perhaps many) exceptions would be:
SqlException
InvalidOperationException
http://msdn.microsoft.com/en-us/library/9kcbe65k.aspx
EDIT:
I just came across this: How can I determine which exceptions can be thrown by a given method?
Which looks liek it uses reflection to help uncover a list of exceptions that are thrown.
The problem is that there are many exceptions that will be thrown at a lower level than the enterprise library, and it would be impossible for EL to document all of these.
I suggest you use the exception handling and logging blocks to catch and log all exceptions. You can then see which ones occur and adapt the configuration of the exception handler or add new code to handle the specific execptions.