how support invoking a priv lib routine and pass it the app PEB/TEB state?

_From [bruen...@google.com](https://code.google.com/u/109494838902877177630/) on October 24, 2013 10:29:47_

With the client from issue #1292 , if I call
dr_switch_to_app_state(drcontext) prior to the call to MiniDumpWriteDump I
get an assert:

ASSERT ntdll_redir.c:255 !dynamo_initialized || dynamo_exited || standalone_library || get_thread_private_dcontext() == NULL || !os_using_app_state(get_thread_private_dcontext())

05 196fed70 636e1da2 dynamorio!internal_error+0x124 [c:\src\dr\git\src\core\utils.c @ 183]
06 196fed90 636e1fef dynamorio!redirect_heap_call+0x62 [c:\src\dr\git\src\core\win32\drwinapi\ntdll_redir.c @ 255]
07 196feda4 63e22be3 dynamorio!redirect_RtlAllocateHeap+0xf [c:\src\dr\git\src\core\win32\drwinapi\ntdll_redir.c @ 324]
08 196fedb8 63e1ac44 dbghelp!MiniDumpCreateLiveAllocationProvider+0x39
09 196fee10 74161273 dbghelp!MiniDumpWriteDump+0x57
0a 196feeb4 196c109c minidump!snap_cb3+0xa3 [c:\src\dr\bugs\minidump\minidump.c @ 102]

Hmm, so we have a fundamental problem: we need to be in priv state to run
the privlib code correctly and safely and not step on the app state. Yet
we want this routine to get the app state when it creates the minidump.

Today we have no simple way to support doing this. We already document for
dr_switch_to_app_state():
- Invoking non-DR library routines while
- the application state is in place can lead to unpredictable
- results: call dr_switch_to_dr_state() (or the _ex version) before
- doing so.

The question is, how can we support this? We've thought about exposing
ldmp creation in a DR API before, but some might prefer the standard dump
formats. We could have DR also produce those formats if they are
documented.

_Original issue: http://code.google.com/p/dynamorio/issues/detail?id=1301_