Im not sure if this is a bug, or im just doing something wrong, or it is actually desired behaviour- anyway:

Setting a BPX on the wndproc of a window using the window list will only break on the original wnd proc.

ie. if a windows wndproc was changed via setwindowlong etc, the new procedure will not be considered the windows wndproc.

Is this a bug? Or does anyone know a good way of setting breakpoints on the new procedure?

i think i you can break on subclassed class proc too
right click and study all options if it is subclassed then there must be an option in the context to break on it

Greets,

the problem with WinProc column in windows list missing after breaking on ::SetWindowLog( .... GWL_WNDPROC ... ) import is in fact some sort of bug.
You can work around it by closing the "windows" window and reopen it.
It should then show all subclassed window procs.
One can then simply follow the subclassed procedure by ENTER or using context menu.

You should mail the author about this "feature"

Regards,

A. Focht

yeah i think you have to press actualize before the subclassed proc is visible or close and open the windows window
most of the time actualize works and it is always good to actualize before seeing anyinfo in any windows in olly coz when you are debugging excel.exe kind of proggie for debugging a macro written in vba which runs 1000s and thousands of other shit along with it is always good to actualize before hand

Yeah I realise you have to actualize or 'refresh' the view somehow. However, even after doing that the WndProc seems to always point to the original.

ie. I am trying to debug a plugin in Winamp. The plugins in Winamp make extensive use of SetWindowLong(GWL_WNDPROC) to modify the wndproc for the windows.

However, no matter how much I try to actualize the window list, the wndproc always points to the original in the winamp.exe module even though its been subclassed multiple times by different plugins.

Its quite easy to find the new wndproc's, but I was just wondering if this is a bug or intended behaviour. It seems ollydbg is obtaining the wndproc address by methods other than spying on the real time wndproc of the windows. I've tried the 'allow code insertion to find wndproc' setting, but it doesn't seem to make a difference.

Or it could be, that winamp is just using some trick to make sure it is always at the top of the list. - or Im just missing something completely.

UPDATE: Just did a quick test. Run winamp in ollydbg and also run spy++. You'll notice that the reported wndproc's are different for windows that are subclassed. (note that this may actually be desired behaviour, but I think it would be good to be able to follow the new wndproc as well)

Eevn better would be for ollydbg to keep a list of all the wndprocs that have entered the chain for a window. This could be done with some clever logging of setwindowlong though I suppose.