ANSI subclassing works, but Unicode does not
-
I'm subclassing TrayClockWClass on Win2K3 using a DLL hook. If I use an ANSI build of the DLL, the hook works with no problem. If I use a Unicode build of the DLL, I get a "The instruction at '0x00000000' referenced memory at '0x00000000'. The memory could not be 'read'." error in explorer.exe. When I click OK on the error dialog explorer.exe restarts and for an instant I can see my subclassed window instead of the normal clock. I've placed some logging statements in the code. SetWindowLong() is successful. And my new WndProc() is being called multiple times with valid values. But it crashes for a reason I cannot determine. The last entry in my log is for a window message that was handled successfully multiple times. And the weirdest thing is that TrayClockWClass is a Unicode window, so I figure it would get along with a Unicode DLL. I only plan to use the code on WinXP and Win2K3 so I'd rather use native Unicode rather than a thunked ANSI DLL. Has anyone had any experience with ANSI hooks working, but Unicode hooks not working? Or any clues as to debugging what the problem is? If you want to take a look at the source code, a Visual Studio 2005 solution is in a Subversion repository (http://fuzzyclock.googlecode.com/svn/trunk/ fuzzyclock).
-
I'm subclassing TrayClockWClass on Win2K3 using a DLL hook. If I use an ANSI build of the DLL, the hook works with no problem. If I use a Unicode build of the DLL, I get a "The instruction at '0x00000000' referenced memory at '0x00000000'. The memory could not be 'read'." error in explorer.exe. When I click OK on the error dialog explorer.exe restarts and for an instant I can see my subclassed window instead of the normal clock. I've placed some logging statements in the code. SetWindowLong() is successful. And my new WndProc() is being called multiple times with valid values. But it crashes for a reason I cannot determine. The last entry in my log is for a window message that was handled successfully multiple times. And the weirdest thing is that TrayClockWClass is a Unicode window, so I figure it would get along with a Unicode DLL. I only plan to use the code on WinXP and Win2K3 so I'd rather use native Unicode rather than a thunked ANSI DLL. Has anyone had any experience with ANSI hooks working, but Unicode hooks not working? Or any clues as to debugging what the problem is? If you want to take a look at the source code, a Visual Studio 2005 solution is in a Subversion repository (http://fuzzyclock.googlecode.com/svn/trunk/ fuzzyclock).
I don't know if this is relevant or helps in any way, but... Testing on XP Pro SP2, Unicode DLL build: During the SetWindowsHookEx() call, I get a "Data Execution Prevention" dialog with the message "To help protect your computer, Windows has closed this program" HookProc() is never callled. Non-Unicode build runs fine. Mark
Mark Salsbery Microsoft MVP - Visual C++ "Go that way, really fast. If something gets in your way, turn."
-
I don't know if this is relevant or helps in any way, but... Testing on XP Pro SP2, Unicode DLL build: During the SetWindowsHookEx() call, I get a "Data Execution Prevention" dialog with the message "To help protect your computer, Windows has closed this program" HookProc() is never callled. Non-Unicode build runs fine. Mark
Mark Salsbery Microsoft MVP - Visual C++ "Go that way, really fast. If something gets in your way, turn."
If I run the release Unicode build on XP Pro SP2, I get an unhandled exception in explorer.exe. But the log file I create (c:\log.txt) has output from HookProc():
SetWindowLong() returns 1001b1f. NewWndProc is c412e0.
Thanks for taking a look. I guess I'll just stick with the ANSI build. -- modified at 16:01 Sunday 22nd July, 2007
HookProc()needs to be_stdcall. Once I did that, the Unicode build worked.