I recently used NDepend and it produced a good report on my .net assemblies and related pdbs.
The most interesting thing I found in the report was abstractness vs. insta
Both abstractness and instability can be used alone to evaluate your code. You know in advance how abstract or stable some module should be. For example, you want presentation layer to be moderately abstract and highly stable, because lower modules depend on it. On the other hand, you want infrastructure layer to be highly concrete (low abstractness) and highly instable, because it should implement what upper layers are demanding.
Once that is clear, you can combine abstractness and instability into one graph, and that is the instability-abstractness graph. You want your code to exhibit as much abstractness as it is stable, in order to balance the needs to support future changes in requirements.
But anyway, you should have strong understanding of instability and abstractness metrics alone before trying to understand them working together. You can find some examples on what instability means in this article: How to Use Module Coupling and Instability Metrics to Guide Refactoring
There is a related article deriving a CQLinq query that measures instability of all modules in the application: How to Measure Module Coupling and Instability Using NDepend