If you've got a crashed process that WER has handled but you either know the JIT debugger is set wrong or you haven't got one set up at all (so no "Debug" button on the crash dialog), you can leave the dialog open and attach any debugger of your choice to the suspended, crashed process.
However, there's a problem. By attaching the debugger to the suspended process, the process' last-exception information has been lost; this is because the way the debugger sucessfully attaches to a suspended (or hung) process is to inject a new, running thread and have that thread crash. So your debugger, and any minidumps it generates with .dump, will not be able to find the original program's exception information. Oops!
The solution is very similar to Raymond Chen's post on Sucking the exception pointers out of a stack trace. The difference is how we find the pointers and what we do with them.
Starting with the stack trace from kb:
RetAddr : Args to Child : Call Site
000007f9`d88212d2 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!NtWaitForMultipleObjects+0xa
000007f9`dae8d20e : 00000000`02300000 000007f6`96e75000 00000000`00000000 00000000`000001dc : KERNELBASE!WaitForMultipleObjectsEx+0xe5
000007f9`dae8cfd2 : fffff8a0`00000080 00000000`80004005 00000000`000001ec 00000000`00000000 : KERNEL32!WerpReportFaultInternal+0x1fa
000007f9`d889fc87 : 00000000`00000000 00000000`00195c30 00000000`00000030 00000000`00195c30 : KERNEL32!WerpReportFault+0x42
000007f9`db56a43d : 00000001`00000000 00000000`00196990 00000000`0019f620 00000000`003441d0 : KERNELBASE!UnhandledExceptionFilter+0x1d7
000007f9`db4b4ad4 : 000007f9`d8eeabdd 00000000`00196990 00000000`00000000 00000000`00000000 : ntdll!LdrpLogFatalUserCallbackException+0x4d
000007f9`db4d464d : 00000000`00000000 00000000`00195de8 00000000`00195da0 000007f9`d8f7f000 : ntdll!KiUserCallbackDispatcherHandler+0x20
000007f9`db4d567c : 000007f9`d8ee0000 00000000`0019f5c0 000007f9`0000e4f0 00000000`00000000 : ntdll!RtlpExecuteHandlerForException+0xd
000007f9`db4b4bba : 00000000`00000000 00000000`00000000 000007f6`96e7e300 00000000`00000000 : ntdll!RtlDispatchException+0x392
000007f9`db4b2acd : 000007f9`d8bbc36c 00000000`00360f00 00000000`00360f00 00000000`00360f00 : ntdll!KiUserExceptionDispatch+0x2e
000007f9`d8bbc36c : 00000000`00360f00 00000000`00360f00 00000000`00360f00 00000000`00000000 : ntdll!memcpy+0x21a
The EXCEPTION_POINTERS structure address seems[1] to be passed as arguments 2 and 4 of the call to "KERNEL32!WerpReportFault". From this, the exception and context records can be displayed - but we only really need to include the EXCEPTION_POINTERS address in the minidump, since adding this one address will allow the !analyze command to work.
Create the minidump using the command ".dump /ma /xp 00195c30 dump.dmp" and you're done. (Apart from all of the actual debugging - have fun!)
[1] This is on Windows 8 64bit running the 64bit WinDbg debugging a 32bit executable. YMMV.