The MS page on this is of course not much use: I tried your ‘SendMessage’ breakpoint but no dice. When reading about the facility, I immediately thought “I’ll be amazed if this works”, and sure enough it doesn’t. I want to do this kind of thing at the moment. June 15th, 2009 at 7:56 You type the expression into the New Breakpoint dialog, not the Watch window. When I type into the watch window, I get the error “CXX0036: Error: bad context specification” You can follow any responses to this entry through the RSS 2.0 feed.īoth comments and pings are currently closed.ġ0 Responses to “Setting a Visual Studio breakpoint on a Win32 API function in user32.dll” On Thursday, March 5th, 2009 at 12:08 am.
(By the way, Raymond Chen’s series of posts on LockWindowUpdate are required reading for anyone thinking of using it: What does LockWindowUpdate do?) LockWindowUpdate was exported at 27d5c, so a quick bit of maths pointed me to 7D957D5C, and hence the real name of the function: I used Dependency Walker to find the symbol’s address: my breakpoint for SendMessage was at 7D94B5BA and Dependency Walker told me that its export address was 1b5ba. Interestingly, the exported symbol as reported by Dependency Walker is called LockWindowUpdate – it’s only in the debug symbols that it’s NtUserLockWindowUpdate.
It turns out that the function is called NtUserLockWindowUpdate as far as the debugger is concerned, so you need to use don’t know which other APIs have that NtUser prefix, but I bet there are some. I knew that works for setting a breakpoint on SendMessage (which is also in user32.dll), so why doesn’t the same thing work for LockWindowUpdate? So I wanted to set a Visual Studio breakpoint on that API’s location. Maybe one of the libraries I use (MFC?) was doing it.
I knew that the LockWindowUpdate API could cause that, but I also knew I didn’t use it. I recently had a problem with my Windows application causing the desktop icons to flicker. Thursday, March 5th, 2009 by Richie Hindle