Is it possible to run certain threads when Debug Engine stopped in "break mode"?

[Oxdeadc0de]

I need to continue execution of some threads when debugger stopped on breakpoint.
Something like calling

ContinueDebugEvent(***, ***, DBG_REPLY_LATER)

in the my Concord component. I've tried to call ContinueDebugEvent with DBG_REPLY_LATER flag in the IDkmRuntimeBreakpointNotification.OnRuntimeBreakpoint callback, but of course Concord didn't like that.

In documentation I've found this enum:

DkmStoppingEventProcessingNextAction
    // This status value is used when one or more threads are not at a safe point, so the
    // target process must be slipped. The target process is expected to hit one or more
    // stopping events (breakpoint or exception) in order to indicate that a safe point
    // has been reached.
	SlipTarget = 1,

which is used in the DkmProcess.StoppingEventProcessingContinue function. Looks like exactly what I need, but there's no any other information how to use it.
Can anyone help me with this problem?

Context:
I'm writing my own debugger with C++ and custom scripting language mixed-mode debugging support. Debugger contains two Debug Engines: my own AD7 debug engine (controls scripting language breakpoints, variables, callstack and etc), and standart Visual Studio C++ debug engine (DkmEngineId.NativeEng). They are packed and work together:

DebugLaunchSettings settings;
settings.LaunchDebugEngineGuid = DkmEngineId.NativeEng;
settings.AdditionalDebugEngines.Add(_MyScriptingDebugEngineGuid_);

To interact with scripting language VM (which is hosted inside debugged C++ program) - to set breakpoints / get callstack frames / and other stuff - I use RPC calls from my debugger to the VM service thread.
Everything is working fine. Until I stopped in the native C++ breakpoint. When this happens, all debugged process threads are frozen and I can't communicate with VM...
So, is it possible to continue executing some threads when debugger has stopped at breakpoint?

[gregg-miskelly]

Attempting to run threads while the debugger is stopped is intentionally unsupported. Because of shared locks and other state in Windows APIs, it is extremely hard to get this correct. The recommended way to do this is to read/write the data that the interpreter is using from out-of-process using either ReadProcessMemory/WriteProcessMemory (or really the DkmProcess APIs on top of that) and/or shared memory. You can also optionally use symbol information for the interpreter to do things like find the RVA of global variables in the interpreter. You can also use func-eval for cases where that is supported (ex: evaluation).