SetWindowsHookEx und WH_SHELL

[PeterPanino]

Hallo!

Ich möchte informiert werden, wenn systemweit irgend eine App ein Top-Level-Fenster erzeugt. Zu diesem Zweck habe ich eine DLL geschrieben, in der dieser Code ausgeführt wird:

Delphi-Quellcode:

hHook := SetWindowsHookEx(WH_SHELL, @ShellProc, HInstance, 0);

In der Host-App wird in FormCreate die DLL aufgerufen (sowohl Host-App als auch DLL sind 32-Bit). Die Host-App wird natürlich im Windows 10 File-Explorer gestartet (nicht von der IDE).

Die Benachrichtigung funktioniert auch sehr gut - nur: Kurze Zeit nach dem Klick auf den UNHOOK-Button verabschiedet sich die Delphi IDE aus dem Speicher! :( Irgend etwas scheint mit dem Ent-Hooken nicht zu funktionieren?

Vielleicht gibt es hier jemanden, der mehr Erfahrung mit Hooks hat als ich? Wäre toll, wenn wir das gelöst kriegten!

Hier sind die Quell-Dateien:

Anhang 56327

Mein System: Delphi 11 in Windows 10

[Kas Ob.]

Not an answer but i don't have CodeSite installed, so i changed these calls to OutputDebugString.

My observation on Delphi XE8
1) It is working in the Debugger and no IDE crash.
2) There is a problem when it is running with the debugger, BUT the output is stopping after the first hook report, then nothing being captured in IDE EventLog.

with DebugView and the application running without a debugger the output is correct and there is no failure, so my deduction is the debugger is faulty or CodeSite is not prepared for MultiThreading inside the debugger with external Threads.

Also i remember a thing from the past, these hooks use OS threads, meaning they are external for the debugger and these are privileged threads, also TThread is faulty when it comes to ExternalThread in its implementation, as ThreadID will not give you the real thread ID if it is called from the thread itself, it will return DWORD(-2) always, so if the debugger is depending on TThread to external threads like the hook one in this case, then there is a big chance it is messing with its own threads causing the catastrophic failure.

Same about threadID can go with codesite.

Just guessing and hope it help.

[PeterPanino]

Zitat:

Zitat von Kas Ob. (Beitrag 1528042)

Not an answer but i don't have CodeSite installed, so i changed these calls to OutputDebugString.

My observation on Delphi XE8
1) It is working in the Debugger and no IDE crash.
2) There is a problem when it is running with the debugger, BUT the output is stopping after the first hook report, then nothing being captured in IDE EventLog.

with DebugView and the application running without a debugger the output is correct and there is no failure, so my deduction is the debugger is faulty or CodeSite is not prepared for MultiThreading inside the debugger with external Threads.

Also i remember a thing from the past, these hooks use OS threads, meaning they are external for the debugger and these are privileged threads, also TThread is faulty when it comes to ExternalThread in its implementation, as ThreadID will not give you the real thread ID if it is called from the thread itself, it will return DWORD(-2) always, so if the debugger is depending on TThread to external threads like the hook one in this case, then there is a big chance it is messing with its own threads causing the catastrophic failure.

Same about threadID can go with codesite.

Just guessing and hope it help.

This may be a misunderstanding: I do not launch the host app from the IDE. I compile the host app and launch it from the file explorer. The IDE (and other Win32 programs) are apparently terminated because the injected DLL is not properly unhooked when the host app is terminated.

[Kas Ob.]

Zitat:

This may be a misunderstanding: I do not launch the host app from the IDE. I compile the host app and launch it from the file explorer. The IDE (and other Win32 programs) are apparently terminated because the injected DLL is not properly unhooked when the host app is terminated.

Thank you for clearing that.

It is strange indeed, the little time before the IDE crash is (most likely) a stack overflow, it could be a bug in the IDE.

[PeterPanino]

Zitat:

Zitat von Kas Ob. (Beitrag 1528066)

Thank you for clearing that.

It is strange indeed, the little time before the IDE crash is (most likely) a stack overflow, it could be a bug in the IDE.

I am glad you're experiencing the same bug - this confirms that I am not the only one. Can you check whether other Win32 programs are crashing as well?

[Kas Ob.]

I am sorry for this misunderstanding but i didn't experience this crash with the IDE, i guessed based on your notes that there is a delay between unhook and the ide disappearing

Zitat:

nur: Kurze Zeit nach dem Klick auf den UNHOOK-Button verabschiedet sich die Delphi IDE aus dem Speicher!

[Kas Ob.]

But yet, i did remove CodeSite calls and changed them to OutputDebugString, so, if there is an expert/addon for CodeSite running on the IDE also it could be something to investigate.