Własny debugger - trudności przy debugowaniu procesów wielowątkowych

**Działanie:
**
Określony byte w pamięci procesu zmieniam na 0xCC, gdy któryś z wątków wykona tę instrukcję otrzymuję wyjątek. Cofam IP w kontekście wątku, ustawiam flagę, że wątek ma wrócić po wykonaniu jednej instrukcji (by móc znów nadpisać orginalną instrukcję bajtem 0xCC). Problem polega na tym, że po analizie okazało się, że zdarza się, że po puszczeniu wątku i oczekiwaniu na jego powrót po wykonaniu orginalnej instrukcji w tym samym czasie (prawie - w każdym razie zanim ustawimy znów 0xCC) inny wątek wykonuje ten kod. **

**Problem: **
W skutek tego istnieje (dość rzadko) szansa na to, że pewien wątek "ucieknie debuggerowi" i nie rzuci wyjątku z int3 tylko wykona kod bez kontroli debuggera.

Co robić, jak żyć ?

dodatkowo zapytałem też tu:
http://stackoverflow.com/questions/34180775/custom-debuger-based-on-windows-api-debugging-multithreaded-process

Sposób prosty:
Wstrzymaj inne wątki. I tak nie chcesz żeby Ci mieszały w stanie programu.

Sposób szybszy (kinda):
Instrukcję którą nadpisałeś wrzuć gdzieś indziej (tj. w dodatkowy fragment pamięci który jest Read/Write/Execute). Przy breakpoint, a raczej przy wznawianiu, przenieś EIP/RIP na tą skopiowaną instrukcję, zapal Trap Flag i ją wykonaj (po tym dostaniesz jakiś single step break) . A po tym przenieś EIP/RIP za tą instrukcje w oryginalnym miejscu.
Są tu trzy specjalne przypadki:

1. Skoki
2. Instrukcje pobierające EIP/RIP (jawnie bądź nie).
3. Instrukcje generujące wyjątki.

• od strony bezpieczeństwa procesu niefajnie jest mieć strony RWX (chociaż ryzyko jest zaniedbywalne, chyba ze to jakaś instrumentacja serwerów produkcyjnych).

3. Jak wyżej, tylko że instrukcja nadpisans (a raczej jej efekty) jest emulowana przez debugger - trudnawe, ale szybkie.

(przepraszam za literowki, pisane z komórki)

Super wyjaśnienie, dzieki ;)