How to debug a crash in a process containing anti-debugger measures

Question

I've got a crash in our app which I can't debug as one of our partners has seen fit to use truly horrible 'CodeMeter' to encrypt their DLL. CodeMeter licensing prevents all attempts to debug an app containing a CodeMeter encrypted DLL and even seems to cause MiniDumpWriteDump called from an unhandled exception filter to fail (this technique works without this DLL loaded). The crash only happens when the encrypted DLL is loaded into the process.

I'm going mad trying to debug this and establish whether it's the encrypted DLL that's crashing, and if so how I can provide adequate diagnostic information to our partner to solve this.

Any suggestions - perhaps some manual stack and module walking code I could call from my unhandled exception filter?

Does CodeMeter have build settings that will allow our partner to produce a build that is still encrypted and licensed but doesn't sabotage debugging so aggressively?

Just to be clear in case there's any doubt, I'm not trying to hack the licensing, just diagnose this crash.

Answer 1

I've used some stack walking code that works well that can be called from an SEH or unhandled exception filter by passing in the CONTEXT record passed to the exception filter.

The addresses in the stack and the potential addresses in the first few exception parameters can be interpreted using SymFromAddr in DbgHelp including the module handle. Add to that a log of the module file names and module handles for interpreting which DLLs the stack addresses relate to.

This particular crash was a Visual C++ exception. The type of the exception is revealed by looking up the address of one of the exception parameters using SymFromAddr.

Raymond Chen's blog has some code for finding the type of a Visual C++ exception from the exception parameters but I couldn't get this to work for me for some reason (probably my own error).