Deadlocks and or heap corruption. You are in a special debugging context
that could be in the middle of a heap allocation or processing of a
synchronization object.

Signature
Steve Maillet
EmbeddedFusion
www.EmbeddedFusion.com
smaillet at EmbeddedFusion dot com
So, if i was not in the middle of a heap allocation, or not in the middle of
processing a synchronization object (when exec enters the vectored handler),
then would it be safe to do a malloc or acquire a mutex lock?
> Deadlocks and or heap corruption. You are in a special debugging context
> that could be in the middle of a heap allocation or processing of a
> synchronization object.
Steve Maillet (eMVP) - 18 Oct 2004 19:03 GMT
No it's not safe to do those in the handler- at ANY time. Why do you doubt
the documentation? Don't try and hack around to find some case where it
might be OK because some new patch or update later it won't be.

Signature
Steve Maillet
EmbeddedFusion
www.EmbeddedFusion.com
smaillet at EmbeddedFusion dot com
Vivek - 19 Oct 2004 11:57 GMT
Thanks for the responses Steve.
The reason i'm asking is,
My debugger design needs some thread synchronization because I have 2
threads,
Thread 1 – handles interaction with a debugger client
Thread 2 – is the thread on which the application that is being debugged (in
other words, the debugee) runs
After Thread2 hits a breakpoint execution enters the VectoredHandler.
I want to wait in the vectored handler until Thread1 (the debugger client),
that is interacting with the user tells me what to do next (which could be
one of continue, step etc.). An easy way to implement this wait in the
Vectoredhandler would have been to use synchronization objects. But the msdn
documentation forbids this. Is there a way to get around this issue that I
seem to be having in my design? OR is my design totally flawed?
Thanks!
Vivek