none
windows7 C# SetWindowHookex RRS feed

  • 질문

  • 개발 완료되어 사용중인 application 이 Windows7으로 OS 변경에 따라 사용이 불가한 상태입니다.

    키보드 후킹과 관련된 내용이며, User32.dll의 SetWindowHookex API를 사용하고 있습니다.

    자료를 찾아본 결과 windows7 이상에서는 SetWindowHookex API 사용시 OS에서 일정시간이후 해당 Hook을 제거하는걸로 알고있습니다.

    폐쇄망에서 대민서비스를 제공해야하는 프로그램이며, 수정 변경하기엔 굉장히 시급한 사안이라 문의드립니다.

    Windows7에서 보안정책상 SetWindowHookex API가 사용가능하도록 즉시 적용 가능한 방안을 주시면 감사하겠습니다.

    적용후 수정 개선 방안으로 키보드 후킹에 사용가능한 API가 있다면 방법을 함께 알려주시면 감사하겠습니다.


    빠른 답변 부탁드립니다.

    삼원FA 기술연구소 정문교선임 (010-4145-8458)

    2018년 7월 11일 수요일 오전 9:12

모든 응답

  • 안녕하세요,

    다음 내용을 참고하여 주시기 바랍니다.

    "I believe that this method (increasing timeout to 10 sec) was wrongly marked by moderator as the answer to the problem. 
    By such logic - another "answer" would be to exchange computer to faster one, because it probably will solve the problem.
    This really shows that the reason is the bug in Windows 7 : "No low level mouse hook calls will be made after any exceeding of
    the LowLevelHooksTimeout occurs. And it is true only for Windows7"

       More of that, such change could lead to system performance issues and not acceptable solution for the commercial programs.

    I have the following workaround:
    Create and start during initialization a separate thread which sets the mouse_ll hook and proceeds win message queue,
    like this:

    DWORD WINAPI mouseLLHookThreadProc(LPVOID lParam)
    {
        MSG msg;

        _hMouseLLHook = SetWindowsHookEx( WH_MOUSE_LL, .....);

        while(GetMessage(&msg, NULL, 0, 0) != FALSE)
        {
            TranslateMessage(&msg);
            DispatchMessage(&msg);
        }

        return 0;
    }

    This will make your mouse_ll processing independent of main GUI thread of the application.
    But, again, this is just workaround for Win7 bug behavior"

    2018년 7월 12일 목요일 오전 1:08