Rss Feed
Tweeter button
Facebook button
Technorati button
Reddit button
Myspace button
Linkedin button
Webonews button
Delicious button
Digg button
Flickr button
Stumbleupon button
Newsvine button

Posts tagged: exception

Exception Tracer

By , August 24, 2019 8:43 am

We’ve just released another of our in-house tools – Exception Tracer.

Exception Tracer started off life as an experiment and then through a series of needing to capture debugging data for various problems with customers, morphed into the exception tracing tool that it is today. Exception Tracer logs debugging events that are sent to debuggers. Most debuggers respond to these events in an interactive manner, breaking the code on exceptions (such as access violations and breakpoints), stepping into and out of functions, inspecting variables. Exception Tracer doesn’t do any of those things. Exception Tracer simply logs every event and stores callstacks associated with each event. You can save the entire trace and inspect it later (or on a different machine if you wish).

Exception Tracer is great for understanding what exceptions are thrown by applications that throw a lot of exceptions, whether that is by design, or because something is going wrong and the exception handling mechanism is being triggered a lot.

We’ve provided filtering so that you only collect the events you’re interested in – perhaps all you’re interested in is what DLLs load and unload and the order they load in, or maybe you only care about a custom exception that your program throws.

We’ve also provided the ability to create minidumps when exceptions are thrown – minidump for any exception, or just the exceptions you care about.

Lastly, we’ve also provided automatic single stepping support (if you want it, turned off by default) with some intelligent options to reduce the amount of redundant single stepping events that are collected. Because you can turn single stepping on and off during a trace you can run at full speed to where the problem area is, turn on single stepping and collect just the area you need in detail.

We used single stepping to great effect to understand the cause of a stack overflow when one of our tools was shutting down on a customer machine. Turns out the culprit was an anti-virus product on the customer machine that was triggering an unexpected sequence of events that would never happen outside of the shutdown phase. We couldn’t get near this bug with a traditional debugger like Visual Studio, but Exception Tracer got us there (that’s where the intelligent filtering came in – the traces contained so many events we had to reduce the data size just to make it manageable when you were inspecting the results).


Select an item in the top window to view the event data and callstack in the lower windows.

Threads names are taken from GetThreadDescription() API (Windows 10), thread naming exceptions, and manual naming of threads (context menu).

Specific threads can be highlighted so that you can pick out related events on the same thread.

We’d love to hear about problems you’ve solved using Exception Tracer. Please let us know.

Unhandled non-continuable exception. What?

By , February 17, 2012 1:13 pm

The Problem

A few days ago I was testing the latest version of C++ Memory Validator x64.

The testing was going fine until I tried testing a particular test tool of ours. C++ Memory Validator x64 would inject into the test tool, start injecting then just die at some point.

No problem, just set the injection flags to inject a breakpoint and that’ll trigger the debugger as soon as we inject. This works with most software and with all our test tools. No joy. Hmmm, puzzling.

OK, try again, but when we get to CreateProcess() I’ll attach the debugger to the paused process myself. That’ll work. Right? Wrong. The debugger does attach and thats great. I resume the process and the the debugger spits out a really impenetrable error message.

“Debugger:: An unhandled non-continuable exception was thrown during process load”.

That is a really useful and useless message all in one.

Useful Unhandled. No one handled it, so in that case it will be a problem.
Useful Non-continuable. Even if someone could handle it, you can’t recover from it. Major problem.
Useless No description of what the exception was, no exception code, nothing. Why?

Next steps

One possible next step would be to repeat this sequence but before resuming the application, go to the debugger and open the Exceptions dialog from the Debug menu.

When the Exceptions dialog is displayed go to the Win32 exceptions part of the settings and expand it so that you can see the various exceptions that will be reacted to. We need to tell the debugger to react to some of these exceptions. I’ve included screenshots with the exceptions highlighted. Feel free to enable other exceptions that you think may be troublesome.

Having enabled the appropriate exceptions you can resume the process and see if the debugger reacts to any of these more obscure exceptions.

Solution

It turned out the problem was a DLL dependency was failing and thus resulting in a module not found exception.

In my case what had tripped me up was that we’ve been doing static analysis of our software recently using PC-Lint from Gimpel Software combined with Visual Lint from Riverblade. PC-Lint does the hard word of analysing your source code and Visual Lint organises the mountain of results into useful and usable information. If you’ve ever seen the log file from PC-Lint you’ll understand the benefits of a tool like PC-Lint to organise the results.

The result of the static analysis is that we’ve changed many APIs. Many objects that were passed in as objects (and implicitly incurred object copying penalties) are now passed as const references. Many char * strings and wchar_t * strings are now passed as const and so on. We’ve done this all over – changing our DLL APIs, everything.

It’s great, we’ve found bugs because of this. Really useful. But I digress. One side effect of this is that the anything dynamically or statically linked against our libraries now fails to work. We had rebuilt all the dynamically linked tests but forgotten the statically linked one. The test I was performing was statically linked.

Rebuilding and relinking the statically linked test meant that the DLL imports/exports now resolved and the DLL would load. Problem solved.

The change to our APIs is a one time change and will be painful for the folks that use our linkable APIs, but the benefits are increased software robustness for everyone, ourselves and customers alike.

Panorama Theme by Themocracy