There are good answers to your question here. However, I wanted to give you my opinion. Root cause analysis, over all, is best done half-manually. One of the reasons is that techniques like Dynamic Taint Analysis, using SMT solvers, etc... are good tools for small or specific problems but almost unusable for whole projects + real targets, for the average researcher, because of the time and power required. Also, it's worth considering the time you will need to develop a tool using such techniques that might work well with a real target, like Acrobat Reader.
The very first thing I can recommend you, in order to make your task less annoying, is to write minimization tools. Depending on how you created your mutated samples, you could even use some of the tools I wrote myself for Nightmare like this kind of generic crash minimization tool that works for some binary files and for text only files (it might work for you with Acrobat Reader with some modifications). Once you minimized your PDF, you might want to do also the following:
- Use MyNav, BinNavi or a similar tool able to do differential debugging.
- Record a first execution with a blank PDF. Be sure to record as most GUI events as possible.
- If you created your mutated file from a template PDF file, then record also an execution of that original PDF file. It will remove all the functions and basic blocks that were used for that specific template.
- After the previous steps were you record a trace of a blank PDF file, GUI events, etc... record the execution of your crashing PDF sample. As you're using differential debugging, only the last basic blocks and/or functions will appear in the last trace.
Hopefully, you will have only a few basic blocks or functions to analyse and you might be able to see which conditional jumps where taken or not taken and determine why it crashed.
BTW, if you're on Unix, you can also diff logs of valgrind executions with the original template and with your crashing sample.
My 2 cents...