SetWindowsHookEx сбой

Question

У меня есть плагин NPAPI, который использует SetWindowsHookEx под капотом, чтобы сделать некоторые скребки экрана. Этот плагин, похоже, успешно работает на большинстве протестированных мной машин. Однако на одной машине (32-разрядная Windows 7), когда я запускаю плагин под Chrome (26.0.1410.43m), вызов SetWindowsHookEx приводит к сбою процесса, в котором размещается плагин. Дело не в том, что SetWindowsHookEx возвращает ошибку - это просто приводит к сбою процесса. И снова это происходит только на одной машине: она отлично работает на всех остальных, которые мы тестировали.

Но вот странная вещь. Как вы знаете, Chrome имеет несколько способов размещения плагинов. Как правило, наш setup.exe создает несколько записей в реестре, которые указывают на плагин, например, так (с установщиком NSIS):

WriteRegStr HKLM "Software\MozillaPlugins\@alanta.com/WinVncCtl\" "Path" "$INSTDIR\npWinVnc.dll" 
WriteRegStr HKLM "Software\MozillaPlugins\@alanta.com/WinVncCtl\" "ProductName" "Alanta Remote Desktop Server" 
WriteRegStr HKLM "Software\MozillaPlugins\@alanta.com/WinVncCtl\MimeTypes\application/x-alanta-vnc" "Description" "Alanta's VNC Server NPAPI Plugin" 

Когда Chrome загружает плагин из этого места, он падает на SetWindowsHookEx вызова.

Однако, если я удалю плагин, то скопируйте точно такую ​​же DLL в %ProgramFiles%\Mozilla Firefox\Plugins\, а затем Chrome загрузит и запустит плагин просто отлично, и вызов SetWindowsHookEx() преуспеет.

Для чего это стоит, вот фактический (довольно болотно-стандарта) вызов:

// Add the CallWnd hook 
hCallWndHook = SetWindowsHookEx(
       WH_CALLWNDPROC,     // Hook in before msg reaches app 
       (HOOKPROC) CallWndProc,   // Hook procedure 
       hInstance,      // This DLL instance 
       0L        // Hook in to all apps 
       // GetCurrentThreadId()   // DEBUG : HOOK ONLY WinVNC 
       ); 

отладчик показывает, что все параметры, указывающие на законные, действительные вещи.

Любые предложения по устранению неполадок? Кто-нибудь знает о любых странностях в SetWindowsHookEx, которые могут появиться в этом сценарии?

EDIT: CallWndProc выглядит следующим образом:

LRESULT CALLBACK CallWndProc(int nCode, WPARAM wParam, LPARAM lParam) 
{ 
    // Do we have to handle this message? 
    if (nCode == HC_ACTION) 
    { 
     // Process the hook if the WinVNC thread ID is valid 
     if (vnc_thread_id) 
     { 
      CWPSTRUCT *cwpStruct = (CWPSTRUCT *) lParam; 
      HookHandle(cwpStruct->message, cwpStruct->hwnd, cwpStruct->wParam, cwpStruct->lParam); 
     } 
    } 

    // Call the next handler in the chain 
    return CallNextHookEx (hCallWndHook, nCode, wParam, lParam); 
} 

Breakpoints в CallWndProc, кажется, не получить удар, так что я подозреваю, что авария происходит во время установки крючка, а не во время его позже обработка.

Answer 1

Если одна и та же DLL ведет себя по-разному при размещении в другом каталоге, это предполагает, что это изменение порядка загрузки плагинов.

(каталог через DLL грузы из не влияет на путь поиска, используемый для поиска и загрузки его зависимости)

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

После этого я предлагаю удалить и переустановить Chrome, возможно, в новом каталоге, если один из двоичных файлов Chrome поврежден или поврежден.

Answer 2

Оказывается, это была агрессивная программа обеспечения безопасности. По-видимому, его эвристика позволяла использовать некоторые DLL, не позволяя другим. Он убивал процесс хостинга, как только он увидел звонок SetWindowsHookEx(). Замена его на что-то разумное исправила проблему.