)
Setting a Visual Studio breakpoint on a Win32 API function in user32.dll
I recently had a problem with my Windows application causing the desktop icons to flicker. I knew that the LockWindowUpdate API could cause that, but I also knew I didn’t use it. Maybe one of the libraries I use (MFC?) was doing it.
So I wanted to set a Visual Studio breakpoint on that API’s location. I tried
{,,user32.dll}_LockWindowUpdate@4 but that didn’t work. I knew that {,,user32.dll}_SendMessageA@16 works for setting a breakpoint on SendMessage (which is also in user32.dll), so why doesn’t the same thing work for LockWindowUpdate?
It turns out that the function is called NtUserLockWindowUpdate as far as the debugger is concerned, so you need to use {,,user32.dll}_NtUserLockWindowUpdate@4
I don’t know which other APIs have that NtUser prefix, but I bet there are some.
Interestingly, the exported symbol as reported by Dependency Walker is called LockWindowUpdate – it’s only in the debug symbols that it’s NtUserLockWindowUpdate. 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. LockWindowUpdate was exported at 27d5c, so a quick bit of maths pointed me to 7D957D5C, and hence the real name of the function:
(By the way, Raymond Chen’s series of posts on LockWindowUpdate are required reading for anyone thinking of using it: What does LockWindowUpdate do?)
June 15th, 2009 at 7:13 pm
I don’t know how these expressions work.
When I type {,,user32.dll}_SendMessageA@16 into the watch window, I get the error “CXX0036: Error: bad context {…} specification”
June 15th, 2009 at 7:56 pm
@Asher: You type the expression into the New Breakpoint dialog, not the Watch window.
June 1st, 2010 at 10:19 am
I want to do this kind of thing at the moment. When reading about the facility, I immediately thought “I’ll be amazed if this works”, and sure enough it doesn’t. I tried your ‘SendMessage’ breakpoint but no dice. I wonder what I could be doing wrong. The MS page on this is of course not much use: http://msdn.microsoft.com/en-us/library/d16ayc6z.aspx
June 1st, 2010 at 10:49 am
…and I got it working.
I guess I should have read the words ‘native only’ on the MS page, and actually paid attention!
June 16th, 2011 at 7:25 pm
Why dont take the function adress directly: declare a pointer to the api function where you want to put the breakpoint, in this case:
BOOL (*ptFunction)(HWND) = ::LockWindowUpdate ;
then debug your program, in the watch take the value of ptFunction and add it in the “Break at Function” dialog
June 20th, 2011 at 1:41 pm
@Mehdi: I’m sure that would work, but it requires you to change your source code. Just adding “NtUser” to the name is much easier if it works – if it doesn’t, your method would be very useful!
May 5th, 2013 at 2:52 pm
There is a much easier way to do this. If you set _NT_SYMBOL_PATH to contain the microsoft public symbol server and run the 32 bit version of dumpbin.exe /exports, it will list the decorated function names. You can’t use the 64 bit version, because 64 bit dll exports don’t have decorations anyway.
One interesting thing about dumpbin is that the dlls you examine with it are subject to the same SYSWOW64 swapping as dlls actualloy loaded by LoadLibraryEx. E.g:
dumpbin /exports c:\Windows\SysWOW64\advapi32.dll
and
dumpbin /exports c:\Windows\system32\advapi32.dll
Would be rerouted to each other idepending on which version of dumpbin you ran.
May 9th, 2013 at 9:43 pm
@Justin: That’s a great tip – thanks very much!
September 3rd, 2020 at 7:58 pm
In my case, I needed to set a breakpoint in ShellExecuteEx using VS 2017, and using {..shell32.dll)_ShellExecuteExW@4 syntax didn’t work for me.
What did work was Breakpoints | New | Function Breakpoint and then use just the function name:
_ShellExecuteExW@4
September 3rd, 2020 at 8:30 pm
@Dave: Useful to know – thanks!