Всем привет

значит появился у меня в программе WH_MOUSE_LL хук ...

LRESULT CALLBACK LowLevelMouseProc(          int nCode,
                                   WPARAM wParam,
                                   LPARAM lParam
                                   )
{
    if (nCode < 0)
        return CallNextHookEx(0, nCode, wParam, lParam);

    // bla bla bla ...

    return CallNextHookEx(0, nCode, wParam, lParam);
}

и отлаживаться стало невозможно ...

когда отладчик брякается или просто делаю пошаговое выполнение то отладчик останавливает поток
которые прокачивает сообщения через этот хук (для этой цели я создал специальный фоновый поток
который состоит только из цикла с GetMessage) из за этого указатель мыши начинает очень сильно
тормозить при передвижении и работать невозможно ...

хоть не отлаживайся ...

как сказать отладчику не оставливай этот конкретный поток никогда ?

VS 2008

спасибо

или как можно определить что к нам цепляют отладчик ? есть IsDebuggerPrsent но пока до нее дойдет уже испытываеш огромные тормоза с мышкой ...

видимо он сначала морозит весь проццесс (тут начинаются тормоза смышкой) грузит все что надо потом запускает процесс и только потом снимается хук на IsDebuggerPresent

Здравствуйте, jyuyjiyuijyu, Вы писали:

J>хоть не отлаживайся ...

Вынести хук в отдельную dll ?

Здравствуйте, jyuyjiyuijyu, Вы писали:

J>или как можно определить что к нам цепляют отладчик ? есть IsDebuggerPrsent но пока до нее дойдет уже испытываеш огромные тормоза с мышкой ...

А _DEBUG не подойдет никак?
Не цеплять хук в _DEBUG, а в релизе отлаживать через логирование...

Здравствуйте, jyuyjiyuijyu, Вы писали:

J>как сказать отладчику не оставливай этот конкретный поток никогда ?

Вынести поток с хуком в отдельный процесс.

Можно запускать приложение на другом десктопе (см например Desktops) ну или дебагер на другом десктопе а приложение — на дефолтовом.

Здравствуйте, rus blood, Вы писали:

RB>Вынести хук в отдельную dll ?

а что это даст ? поток то один и тот же ...

Здравствуйте, rus blood, Вы писали:

RB>А _DEBUG не подойдет никак?
RB>Не цеплять хук в _DEBUG, а в релизе отлаживать через логирование...

не очень хорошо если в _DEBUG сборке эта функциональность будет недоступна а отлаживать через логирование это кошмар ...

Здравствуйте, Alexander G, Вы писали:

AG>Вынести поток с хуком в отдельный процесс.

это конечно решение но отдельный процесс ...

Здравствуйте, ononim, Вы писали:

O>Можно запускать приложение на другом десктопе (см например Desktops) ну или дебагер на другом десктопе а приложение — на дефолтовом.

не в теме ... а можно в двух словах как это поможет ?

как сказать отладчику не оставливай этот конкретный поток никогда ?

ZwSetInformationThread(NtCurrentThread(), ThreadHideFromDebugger, 0, 0);

Здравствуйте, anonymous185, Вы писали:

A>ZwSetInformationThread(NtCurrentThread(), ThreadHideFromDebugger, 0, 0);

странно выполняю такой код NTSTATUS == 0 но поток виден в отладчике и мышка так же тормозит

DWORD WINAPI hookth(void*)
{
    NTSTATUS code = NtSetInformationThread(NtCurrentThread(), ThreadHideFromDebugger, 0, 0);
    llmhook = SetWindowsHookEx(WH_MOUSE_LL, LowLevelMouseProc, GetModuleHandle(0), 0);
    MSG msg;
    while (GetMessage(&msg, 0, 0, 0))
    {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }
    return 0;
}

O>>Можно запускать приложение на другом десктопе (см например Desktops) ну или дебагер на другом десктопе а приложение — на дефолтовом.
J>не в теме ... а можно в двух словах как это поможет ?
Хуки работают в пределах десктопа. Если хуки будут стоять не на том десктопе что дебаггер — они на него влиять не будут и ниче не будет виснуть.

я ошибся(точнее написал не подумав) — после set ThreadHideFromDebugger — перестают приходить отладочные события от этого потока отладчику, но если отладочное событие(например breakpoint или singlestep исключение) происходит в другом потоке — то все остальные потоки суспендятся то тех пор пока отладчик не вызовет DbgUiContinue.
так что ZwSetInformationThread здесь не поможет.