Getting information from minidumps that have WerReportFault() on the stack

I have crash dumps that have WerpReportFault() in their stack and they really don't look the way I expect them to.

My expectation

If have seen WerpReportFault()along with 0x80000003 breakpoints and I was able to use WinDbg to re-dump with different exception pointers, taken from the second argument passed to WerpReportFault().

I'm very sure that has worked before, since I even recommended that in my answer over there. There are also other sites suggesting this technique, e.g. James Ross

My current observations

The dumps I'm analyzing have an "ordinary exception" inside, e.g. an access violation:

0:000> .exr -1
ExceptionAddress: 53ec8b55
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000000
   Parameter[1]: 53ec8b55
Attempt to read from address 53ec8b55

But they still have WerpReportFault() as the stack:

0:000> k
ChildEBP RetAddr  
0018f25c 74c4171a ntdll!NtWaitForMultipleObjects+0x15
0018f2f8 75181a08 KERNELBASE!WaitForMultipleObjectsEx+0x100
0018f340 75184200 kernel32!WaitForMultipleObjectsExImplementation+0xe0
0018f35c 751a80ec kernel32!WaitForMultipleObjects+0x18
0018f3c8 751a7fab kernel32!WerpReportFaultInternal+0x186
0018f3dc 751a78a0 kernel32!WerpReportFault+0x70
0018f3ec 751a781f kernel32!BasepReportFault+0x20
0018f478 7295fa2e kernel32!UnhandledExceptionFilter+0x1af

Argument 2 does not seem to be a good exception pointer to be used in the .dump command.

0:000> kb
ChildEBP RetAddr  Args to Child              
[...]
0018f3dc 751a78a0 0018f4a0 00000001 0018f478 kernel32!WerpReportFault+0x70
[...]

Question

What causes the problems I have and how do I get around it? I know it must be possible, because !analyze -v can tell me the real call stack.

Is it due to Visual Basic 6 and the unhandled exception filter?

0018f478 7295fa2e 00000000 72a2bd04 0018f4a8 kernel32!UnhandledExceptionFilter+0x1af
0018ff80 00440fe2 00443860 7518338a 7efde000 msvbvm60!Zombie_Release+0x10fd5

I really want to have a nice call stack, since all my manual debugging and all my scripts are broken which rely on k and !clrstack and similar. They can't deal with WerpReportFault() on the stack.

All the dumps are 32 bit, as you can imagine from the VB6 dependency.

Such a problem is caused by a wrong context. It seems to be set to the normal context record. To set it to the exception context, use .ecxr. To switch back to the normal context (which you see), use .cxr