Entrian Solutions
 

Setting a Visual Studio breakpoint on a Win32 API function in user32.dll

Thursday, March 5th, 2009 by

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:

NtUserLockWindowUpdate

(By the way, Raymond Chen’s series of posts on LockWindowUpdate are required reading for anyone thinking of using it: What does LockWindowUpdate do?)

9 Responses to “Setting a Visual Studio breakpoint on a Win32 API function in user32.dll”

  1. Asher Says:

    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”

  2. Richie Hindle Says:

    @Asher: You type the expression into the New Breakpoint dialog, not the Watch window.

  3. Innes Says:

    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

  4. Innes Says:

    …and I got it working.

    I guess I should have read the words ‘native only’ on the MS page, and actually paid attention!

  5. Mehdi Says:

    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

  6. Richie Hindle Says:

    @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!

  7. Justin Dearing Says:

    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.

  8. Richie Hindle Says:

    @Justin: That’s a great tip – thanks very much!

  9. Juan Monachesi Says:

    What I do is open the PDB file (ie: user32.pdb) and look inside for the name of the function and that’s all.

Leave a Reply