Mattias,
Hmm... I was afraid of that. Well, at least I know to bag looking for a
solution inside there. Is there something else I should be looking at? I've
looked briefly at the Debugging API, but it seems horribly complicated to
use for this purpose -- and I'm unclear as to how to make the connection
between the references I find via reflection to values I would obtain via
ICorDebug and friends -- or should I discover the stack/heap from the
debugging API, skipping Reflection altogether?
-LZ

Ben...  In a word, Yes. I'm trying to get a stack trace goodies.

Well, that's true, but there is a workaround. Exception handling involves a
two phase stack walk. The first walks up the stack to look for a qualifying
catcher of the exception thrown. Using exception filtering via the WHEN
clause in VB.NET, one can generate StackTrace info while the throwing code
is still alive. It has to be since the second unwind hasn't occurred yet,
which is where the finally blocks are executed. Only then would the locals
of each method be allowed to go out of scope. Here's some interesting code
to try out:

Sub Main()
   Try
       Helper()
   Catch ex As Exception When ExceptionFilter()
   End Try
End Sub

Sub Helper()
   MakeExceptionHappen()
End Sub

Sub MakeExceptionHappen()
   Throw New ApplicationException("Bummer")
End Sub

Function ExceptionFilter() as Boolean
   Dim st as New StackTrace()    'gets a stack trace at this point
   Console.WriteLine(st.ToString)
   Return False
End Function

'and what is printed is:
'  at blah.blah.ExceptionFilter(Exception ex)
'  at blah.blah.Main()   <-- This is interesting!
'  at blah.blah.MakeExceptionHappen()
'  at blah.blah.Helper()
'  at blah.blah.Main()
'  at System.AppDomain.nExecuteAssembly ....yadda.yadda......

So what appears to be happening is that the first phase of the exception
handling is walking up the stack looking for a qualifying exception handler
and then injecting a 'call' to a fragment inside Main which in turn calls
the ExceptionFilter. This means that everything down to the point of the
thrower is still available just as though the thrower had called the
ExceptionFIlter code itself.

Okay, so forget about all that stuff for a moment because it's not really
relevant. The question remains, can I get the current values of vars still
in scope via Reflection, Introspection, Debugging API, whatever... I'd like
to get statics, object instance vars, method parameters, and method locals.

Thanks for your help so far Ben.
-LZ

The minidump file is the Windows analogue to a core file.  It can be opened
with your normal debugger, and you'll be able to see stack trace, local
variables, static variables, threads, walk through the trees of contained
objects, etc.  In addition, you keep your .pdb files in your development
environment.

Under most circumstances, the fact that your users can't connect the
contents of a minidump file with the variable names is "A Good Thing".