I have a process that handles exceptions great. It calls:
_set_se_translator(exception_trans_func);
SetUnhandledExceptionFilter(UnhandledExceptionFilterHandler);
_set_purecall_handler(purecallHandler);
set_terminate(terminateHandler);
set_unexpected(unexpectedHandler);
_set_invalid_parameter_handler(InvalidParameterHandler);
atexit(exitHandler); //ignored during an expected exit
_onexit(onexitHandler); //ignored during an expected exit
Anytime an exception happens, one of the handlers is called which creates a crash dump for me. Life is good.
Except at one customer site. When they shutdown the process, there is an exception that isn't routed through these calls for some reason and they get the error:
The instruction at "0x101ba9df" referenced memory at "0x00000004". The memory could not be "read". Click OK to terminate...."
The memory reference of x000000004 looks like it's probably a null pointer. And looking at that address appears to be a global STL object's destructor (probably in the CRT's initterm call where globals are cleaned up).
Right now I'm kind of stuck though since I can't get a diagnostic dump and call stack and see exactly what is going on. So....
Why isn't the exception being routed through the above handlers, and instead being shown to the user?
Is there any way to hide that dialog (since no harm is being done at that point)?
And is there a way to track down the root error?
Thanks for any ideas.
What operating system are they running?
I assume you're setting the error mode using something like
::SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX | SEM_NOOPENFILEERRORBOX);
to make sure that windows isn't jumping in with its own error handling?
This sounds like the CRT has put an SEH try/catch block (can't write it properly, Markdown kicks in) around some piece of code, and is catching the exception to display the message, so you never end up calling the unhandled exception code path. You might have to do some CRT hacking to figure out what's happening.
It could be that STL code is being executed during the destruction of global variables at program shutdown time and perhaps (depending on the version of STL that you're using) some global variables that it requires have already been destroyed.
I've seen this with VS2008's STL. There are some STL lock objects that are created via a file level static during start up.
Are you using STL in your error handler functions? It could be that one of these is going off late in program shutdown and causing the problem.
Related
I update my computer to Windows10.
It cause an exception in OutputDebugString callstack i guess.
When i called OutputDebugString, the callstack was shown like this.
ntdll.dll!_WerpWaitForCrashReporting#16()
ntdll.dll!_RtlReportExceptionHelper#16()
ntdll.dll!_RtlReportException#12()
ntdll.dll!_RtlpReportInvalidExceptionChain#8()
ntdll.dll!RtlDispatchException()
ntdll.dll!_KiUserExceptionDispatcher#8()
KernelBase.dll!_RaiseException#16()
KernelBase.dll!OutputDebugStringW()
It looks like windows error report process.
Why dose this happen?
Is OutputDebugString deprecated in Windows10?
Thanks.
Why does this happen?
There is an error in your code somewhere. Perhaps a heap corruption, or an invalid argument passed to the function. For. Instance it may be that the string is not null terminated, or that the memory you passed has already been freed.
If I had to bet, I would expect that this final explanation is the most likely.
Is OutputDebugString deprecated in Windows10?
No. Much as you might be inclined to think the problem is related to the OS upgrade, it is an issue with your code. The upgrade has just happened to highlight the problem with your code, a problem that has always existed but only now happens to manifest.
OutputDebugString works by generating an exception. The debugger catches it as a debug event ("1st chance"), then extracts the string argument and displays it.
The important part in the stack you show is _RtlpReportInvalidExceptionChain. What this means is that somehow your try/catch chain was corrupted. Perhaps a mismatch in exception handling model (/EHsc) or otherwise.
Currently, I see a recurring error:
2013-04-18 02:35:51.583 aaah[1713:1110f] *** Terminating app due to uncaught exception 'NSGenericException', reason: '*** Collection <__NSArrayM: 0x1fc00dc0> was mutated while being enumerated.'
In the failing background queue (I see my queues state upon the moment of a crash by pressing Command + 5) I see:
0 _pthread_kill
1 pthread_kill
And I see assembly output which I completely don't understand.
I know how to resolve this kind of array enumeration errors - I just can't understand where/how I should seek for the piece of code causing my app to crash.
I have much multi-threaded code using AFNetworking and Core Data, so I can't just remember where the crucial section might be.
Also, this error occurs not always, but from time to time, so it is difficult just to use "isolation approach", isolating smaller and smaller pieces of code, to finally identify the buggy piece of code.
So the question is:
How can I extract some more useful information from this output, or Xcode can provide me with some more verbosity level, so I could know how to resolve this annoying piece of code.
Have you tried setting an exception breakpoint? Sometimes the debugger struggles with exception handling inside blocks but it might help.
In the breakpoints navigator (one of the tabs on the left side of the window) click the plus button at the bottom of the window and select add an exception breakpoint. Then hit done.
Now when you crash, the debugger should hopefully put you right before the instant the exception was raised.
See http://developer.apple.com/library/mac/#recipes/xcode_help-breakpoint_navigator/articles/adding_an_exception_breakpoint.html for more info.
Edit:
Based on the feedback provided in the comments, here's some more analysis:
The exception your application is raising means that you attempted to change a collection type (in this case, an NSMutableOrderedSet) inside of an enumeration block (in your case, most likely a for-loop). It looks like you're trying to remove objects in a set that you are looping over: [NSMutableOrderedSet removeObjectsInRange:inOrderedSet:]
To resolve this you should store the ranges you wish to remove and then do the actual removing once you're no longer iterating over the set. It's still going to be difficult since, as I understand it, you're not breaking inside of Objective-C code. You should look at the running threads in the panel on the left and look at what method they're currently in. That might give you a hint as to where your code is wrong.
I'm wanting to use MiniDumpWriteDump to generate crash logs for an application of mine. Microsoft recommends performing the dump from another process, which is what I'm trying to do. The issue I'm having is with passing the PEXCEPTION_INFORMATION structure from the parent to the child process. The issue is that the parent process owns the memory for this structure, and I need to give it to the child. I found this post
How do I get at the exception information when using MiniDumpWriteDump out-of-process?
And the accepted answer said "It doesn't matter that the pointer is not valid in the context of the watchdog process." which lead me to believe I could simply pass the PEXCEPTION_INFORMATION pointer that my unhandled exception filter receives to the child process, and windows would read it from the parent. This isn't happening and so I don't really know what to do, at the moment the child process crashes, presumably because windows tries to access this memory as-if it belonged to the child. I'm obviously missing something here, but I'm not sure what. I use pipes to send data to the child process, and the answer to the above question says using memory mapped files works, but I'm not really sure why, or if I'm understanding the answer correctly.
Debug the process you want to dump.
typedef struct _EXCEPTION_POINTERS {
PEXCEPTION_RECORD ExceptionRecord;
PCONTEXT ContextRecord;
} EXCEPTION_POINTERS, *PEXCEPTION_POINTERS;
ExceptionRecord can be got from EXCEPTION_DEBUG_EVENT by WaitforDebugEventEx.
ContextRecord can be got by OpenThread and GetThreadContext with threadid from DebugEvent
I am trying to understand if we can add our page fault handlers / exception handlers in kernel / user mode and handle the fault we induced before giving the control back to the kernel.
The task here will be not modifying the existing kernel code (do_page_fault fn) but add a user defined handler which will be looked up when a page fault or and exception is triggered
One could find tools like "kprobe" which provide hooks at instruction, but looks like this will not serve my purpose.
Will be great if somebody can help me understand this or point to good references.
From user space, you can define a signal handler for SIGSEGV, so your own function will be invoked whenever an invalid memory access is made. When combined with mprotect(), this lets a program manage its own virtual memory, all from user-space.
However, I get the impression that you're looking for a way to intercept all page faults (major, minor, and invalid) and invoke an arbitrary kernel function in response. I don't know a clean way to do this. When I needed this functionality in my own research projects, I ended up adding code to do_page_fault(). It works fine for me, but it's a hack. I would be very interested if someone knew of a clean way to do this (i.e., that could be used by a module on a vanilla kernel).
If you don't won't to change the way kernel handles these fault and just add yours before, then kprobes will server your purpose. They are a little difficult to handle, because you get arguments of probed functions in structure containing registers and on stack and you have to know, where exactly did compiler put each of them. BUT, if you need it for specific functions (known during creation of probes), then you can use jprobes (here is a nice example on how to use both), which require functions for probing with exactly same arguments as probed one (so no mangling in registers/stack).
You can dynamically load a kernel module and install jprobes on chosen functions without having to modify your kernel.
You want can install a user-level pager with gnu libsegsev. I haven't used it, but it seems to be just what you are looking for.
I do not think it would be possible - first of all, the page fault handler is a complex function which need direct access to virtual memory subsystem structures.
Secondly, imagine it would not be an issue, yet in order to write a page fault handler in user space you should be able to capture a fault which is by default a force transfer to kernel space, so at least you should prevent this to happen.
To this end you would need a supervisor to keep track of all memory access, but you cannot guarantee that supervisor code was already mapped and present in memory.
I want to access the call stack at runtime in a Native C++ application. I am not using the IDE. How do I display the call stack?
Update: I have a function which is called from many points all over the application. It crashes on rare occasions. I was looking for a way to get name of the caller and log it.
Have a look at StackWalk64.
If you're used to doing this on .NET, then you're in for a nasty surprise.
I believe that this page has the answer you are looking for. You said Visual C so I assume you mean windows.
You should consider setting your unhandled exception filter and writing a minidump file from within it. It is not all that complicated and is well documented.
Just stick to the minimum of things you do once in your unhandled exception filter (read what can all go wrong if you get creative).
But to be on the safe side (your unhandled exception filter might get inadvertently overwritten), you could put your code inside __try/__except block and write the minidump from within the filter function (note, you cannot have objects that require automatic unwinding in a function with __try/__except block, if you do have them, consider putting them into a separate function):
long __stdcall myfilter(EXCEPTION_POINTERS *pexcept_info)
{
mycreateminidump(pexcept_info);
return EXCEPTION_EXECUTE_HANDLER;
}
void myfunc()
{
__try{
//your logic here
} __except(myfilter(GetExceptionInformation())) {
// exception handled
}
}
You can then inspect the dump file with a debugger of your choice. Both Visual Studio and debuggers from Windows Debugging Tools package can handle minidumps.
If you want to get a callstack of the crash, what you really want to do is post mortem debugging. If you want to check a callstack of application while it is running, this is one of many functions SysInternals Process Explorer can offer.
If you're not actively debugging, you can "crash" the app to produce a minidump (this can be done non-invasively and lets the app continue running). IIRC DrWatson will let you do this, if not userdump from MS support will.
You can then load the dump into windbg and see the callstack + variables etc there. You will need your app's symbols to make sense of the trace.
If you're looking for a simpler run-time code style traces, I recommend a simple class that you instantiate on every method, the constructor writes the method name using OutputDebugString. Use WinDebug to view the trace as the program runs. (put some form of control in your class, even if its just a global variable or registry value, or global Atom so you can turn the tracing on or off at will).
It crashes on rare occasions. I was looking for a way to get name of the caller and log it.
What do you mean by it crashes? Access Violation? Divide by zero? what exactly? Does it interact with kernel mode components?
Turn on appverifier. that should eliminate a lot of things.
create this:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\FileName.exe
under that key, create a new string
name : debugger
value: c:\pathtowindbg\windbg.exe -gG -xe av
If you're running 32bit code with WOW, you need to do this under the wow3264node.