Reply To: Record hook not freed??

Product Compare Forums Multi-Edit Support Record hook not freed?? Reply To: Record hook not freed??

#5555
Michal Vodicka
Participant

OK, I’ll try to write down step by step instructions with WinDbg. Just tried it and it may not be as easy as I expected because of Windows interraction with debugger at hooks. Let’s try, I believe it can be a nice experience for you ;-) Please note it is good to have Internet connection at this computer because WinDbg loads symbols from MS symbol server. That’s why the first use would take some time; then, symbols are stored locally and access is much faster. Examine File | Symbol Search Path and fix local part if necessary. In my case it is like this srv*e:\websymbols*http://msdl.microsoft.com/download/symbols and symbols are stored under e:\websymbols directory. Change default if necessary but don’t change the second part.

1. Start MEW and verify the problem can be reproduced (to avoid unnecessary work)

2. Start WinDbg from command line: windbg -pn mew32.exe. It should attach to running MEW and display list of loaded DLLs and stop at ntdll!DbgBreakPoint in command window.

3. Arrange WinDbg windows. Dock command window, add one disassembly and registers one and dock them so they can be visible at once. The most difficult point ;-)

4. Go to command window and invoke u user32!NtUserUnhookWindowsHookEx command. It should display something like this:

[code:2xc41fa9]0:002> u user32!NtUserUnhookWindowsHookEx
user32!NtUserUnhookWindowsHookEx:
77d6f29f b83a120000 mov eax,0x123a
77d6f2a4 ba0003fe7f mov edx,0x7ffe0300
77d6f2a9 ff12 call dword ptr [edx]
77d6f2ab c20400 ret 0x4[/code:2xc41fa9]

5. Put breakpoint there using bp user32!NtUserUnhookWindowsHookEx command. You can verify it using bl command.

6. Let MEW running using g command.

7. Start macro recording and stop it. Debugger should stop at the breakpoint. Now it is possible Windows stop responding and even mouse cursor disappears. Don’t panic and press Ctrl-Alt-DEL which should switch to logon desktop and after returning at least taskbar and debugger should work. I presume it is becase access to hooks is serialized and desktop locks-up on the breakpoint. Nasty but we’d avoid it later.

8. Now you should be at the breakpoint in disassembly window. Make several steps using F10 key (or p command) until you reach return from the function — ret 0x4 code. Make yet another step and you should be in MEW code. Something like this:

[code:2xc41fa9]004e6919 50 push eax
004e691a e8e5b6fcff call MeLib+0x2004 (004b2004)
004e691f 85c0 test eax,eax
004e6921 751e jnz MeLib!FreeUndoBuffer+0x11a5 (004e6941)
004e6923 6a30 push 0x30
[/code:2xc41fa9]

and you should be at test eax,eax instruction. This is where we wanted to be. Put breakpoint there using bp command; copy&paste instruction address to the command line. Verify it using bl command:
[code:2xc41fa9]
0:000> bp 004e691f
0:000> bl
0 e 77d6f29f 0001 (0001) 0:*** user32!NtUserUnhookWindowsHookEx
1 e 004e691f 0001 (0001) 0:*** MeLib!FreeUndoBuffer+0x1183 [/code:2xc41fa9]

9. Disable the first breakpoint so desktop freeze is avoided using bd command and verify using bl again:

[code:2xc41fa9]0:000> bd 0
0:000> bl
0 d 77d6f29f 0001 (0001) 0:*** user32!NtUserUnhookWindowsHookEx
1 e 004e691f 0001 (0001) 0:*** MeLib!FreeUndoBuffer+0x1183
[/code:2xc41fa9]

Now everything is prepared for debugging. Leave debugger (g) and try to reproduce the problem with MEW. When recording is done, execution should stop in the debugger at test eax,eax instruction. When eax is zero, problem was reproduced and !gle command should be used to get info I’d like to know:

[code:2xc41fa9]0:000> g
Breakpoint 1 hit
eax=00000001 ebx=00af5128 ecx=0012fb68 edx=7c90eb94 esi=20440001 edi=00000000
eip=004e691f esp=0012fb74 ebp=0012fd9c iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206
MeLib!FreeUndoBuffer+0x1183:
004e691f 85c0 test eax,eax
0:000> r eax
eax=00000001
0:000> !gle
LastErrorValue: (Win32) 0 (0) – The operation completed successfully.
LastStatusValue: (NTSTATUS) 0xc0000135 – {Unable To Locate Component}[/code:2xc41fa9]

Above is the state when problem wasn’t reproduced, and eax is 1 as you can see. When reproduced, error code would be displayed. Please note there would be an error after above mentioned desktop freeze and desktop switch at point 7. It is uninteresting because it is because of this situation.

Now I’m really curious if above description is usable for somebody who isn’t familiar with WinDbg. Don’t hesitate to ask if something is unclear.