The balloon tooltip appears to be a Windows tooltip common control with the TTS_BALLOON style.

To replicate this functionality, I decided to write a function called ShowMsgBalloon() which, given a control and the various balloon tooltip parameters, creates and shows the balloon tooltip below the control.

The key insight to making ShowMsgBallon() work as intended was to use the TTF_TRACK option to create a tracking tooltip. This will immediately show the tooltip without requiring the user to position the mouse over the control. The main downside to using TTF_TRACK is that the tooltip will not move with the control if the window is moved; you need to manually move the tooltip using TTM_TRACKPOSITION as required. One could probably make this automatic by subclassing the tooltip’s parent control and handling WM_WINDOWPOSCHANGED messages.

Here is the source code to ShowMsgBalloon(). When you are done with the balloon, call DestroyWindow() on the returned HWND. Note: you may want your application to use comctl32.dll version 6 as it will lead to a nicer visual style, including a close button.

Update 2008-11-01 3:08PM: If you are targeting comctl32.dll version 6 or later, I recommend using the EM_SHOWBALLOONTIP message.  Comctl32.dll version 6 or later also automatically shows the caps lock warning balloon for edit boxes with the ES_PASSWORD window style.

What happens if this function is exported as an ordinal function from a DLL (not an inlined piece of code inside a header) and you call it from an EXE?

It works most of the time. When it doesn’t, it corrupts your heap and causes a spectacular mess.

In Windows you must free memory with the same allocator that allocated it. However, your EXE may not share the same allocator as the DLL. Perhaps the two modules are linked against different versions of libc, or perhaps one of the modules is using a static version of libc. If your EXE and DLL do not share an allocator and if AppendChar resizes the string s, you will almost certainly cause a heap corruption.

The STL performs a lot of reallocations behind the scenes for you; this is one of its major benefits. Unfortunately, if you are writing a general-purpose DLL these behind-the-scene allocations are deadly. You cannot know or dictate what version of libc your clients will use.

Therefore, I reiterate my previous recommendation:

Avoid passing STL objects as parameters to DLLs.

My first task was to write a program which would launch the application we wanted to trace and log its calls to the Windows memory allocation functions. As I recommend on my Win32 LD_PRELOAD page, I used Microsoft Research’s Detours, rather than Win32 LD_PRELOAD, for the mechanism to intercept Windows function calls. The only functions I chose to intercept were HeapAlloc and HeapFree; these functions seem to be the workhorses of the Windows memory allocation world.

When my code detects a call to HeapAlloc or HeapFree, it logs basic information about the call to a file and then forwards the call to their real implementations. Reentrancy was an issue; the process of logging could potentially cause another allocation, so I had to guard against that. A more robust application would also consider multithreading scenarios more carefully.

For performance and space considerations, I decided the allocation logger would write log entries as binary records into a file. An allocation log record is 17 bytes long; a free, 13 bytes. However, memory operations are so frequent that a one minute browsing session in Firefox (including a quick visit to Google Reader), generated a 14 megabyte log file. Furthermore, the logger introduced a noticeable, although not drastic, performance hit.

With the Firefox log file in hand, I wrote a few post-processing scripts in Python to calculate some useful data, including total cumulative memory usage and a memory allocation frequency histogram. I then used Gnuplot to graph the results.

Here is the total cumulative memory usage graph for my short Firefox browsing session:

Here is the memory allocation frequency histogram. Note the log-log scale; Firefox (like most applications) is so dominated by very small allocations that the graph is useless without it. The graph has a huge spike of allocations with very small object sizes and, somewhat interestingly, a moderate one with sizes just under 10 KB.

Here is the source code to the memory trace logger.

First, start with the following scratch program (which is a slightly modified version of Raymond Chen’s scratch program):

Next, we’ll add a tooltip to this window. We’re not going to do anything fancy like tooltip multiplexing so we’ll use TTF_SUBCLASS.

If you compile and run the program, you should see a tooltip with the text “Hello World!” pop up.

To use custom draw, we must handle the NM_CUSTOMDRAW message. First we’ll write the WM_NOTIFY handler to forward the message to our function.

Now we’ll implement the custom draw function. For simplicity’s sake, we will simply write the text “Hello World!” just as the tooltip did before we used custom draw.

It is important to note that the tooltip control will continue to draw the static text even if we are using custom draw. To get around this problem, we’ll have the tooltip control draw the text in the same color as the background, effectively making it invisible.

We now can use the full range of GDI functions to render the content of the tooltip, including multiple fonts, lines, ellipses, etc. However, drawing is limited to the size of the tooltip’s client window, and this is determined based on the text passed to the tooltip window in OnCreate(). If we want to control the size of the tooltip, we must handle the TTN_SHOW message:

We now have a sizable, custom-drawable tooltip control.

The code is trivial but the function took me forever to find.

This library makes the IXmlWriter in Implementing IXmlWriter Series obsolete for Windows developers.

Formatting a Number for a Locale

The function GetNumberFormat() formats a number for a particular locale. Its simplest usage looks something like:

buf now contains the number 1234567.89 formatted for the user’s default locale. For example, for the English-United States locale, buf will contain “1,234,567.89″; for German-Germany, “1.234.567,89″; for Hindi, “12,34,567.89″.

The format of the lpValue parameter is important. From GetNumberFormat()’s MSDN documentation:

lpValue

[in] Pointer to a null-terminated string containing the number string to format. This string can only contain the following characters. All other characters are invalid. The function returns an error if the string indicated by lpValue deviates from these rules.

• Characters ‘0′ through ‘9′.
• One decimal point (dot) if the number is a floating-point value.
• A minus sign in the first character position if the number is a negative value.

Given these constraints, I’ve found the easiest way to convert, say, a double to a string for use as lpValue is to use StringCchPrintf() (or, equivalently, wnsprintf() or _sntprintf()), as in:

One caveat: GetNumberFormatDbl() does not deal well with very small numbers (below 1e-5 or so).

Parsing a Localized Number String

I spent a lot of time trying to figure out the best way to parse a localized number string until Michael Kaplan mentioned VariantChangeTypeEx(). Once I had that, the rest was (relatively) easy:

Using VarR8FromStr() instead of VariantChangeTypeEx() is also an option.

Customizing of the Output of GetNumberFormat()

If you pass NULL as the lpFormat parameter to GetNumberFormat(), you use the locale’s default number formatting information. I often find this to be unacceptable — for example, many times I want to control the number of fractional digits I display. To do this, you need to provide a filled-in NUMBERFMT structure to GetNumberFormat().

I suggest starting with the locale’s default NUMBERFMT and then change only the members you require. Because Windows does not seem to provide a way to retrieve a locale’s default NUMBERFMT, we’ll have to roll our own.

To populate the members of NUMBERFMT we are going to use the function GetLocaleInfo(). The map between NUMBERFMT members and LCTYPEs to pass to GetLocaleInfo() is as follows:

GetLocaleInfo() always returns strings, but many of these strings need to be converted to UINTs. Furthermore, the conversion between the LOCALE_SGROUPING string and the Grouping member is quite tricky; read How to fill in that number grouping member of NUMBERFMT for more information.

We now have enough information to write the function to retrieve a locale-default NUMBERFMT:

Now that we have these functions, we can use them to better control the output from GetNumberFormat(), as in:

One might expect that the creation of the file C:\Program Files\sol.lnk would be silently redirected by Vista using file virtualization and CreateLink() would succeed, but it doesn’t — the call to IPersistFile::Save() returns E_ACCESSDENIED.

For more information about developing on Vista, see the document Windows Vista Application Development Requirements for User Account Control Compatibility.

To begin with, let’s write an application that crashes with a null pointer dereference:

// DerefNullPointer.c: Crash by dereferencing the null pointer.

static void DoCrash()
{
    *((char*) 0) = 1;
}

int main(int argc, char* argv[])
{
    DoCrash();
    return 0;
}

I placed the null pointer dereference in its own function for reasons that will later become clear. Now, let’s compile the application from the command line:

C:\\Proj\\Crashes> cl /Od /nologo /c DerefNullPtr.c
C:\\Proj\\Crashes> link /SUBSYSTEM:CONSOLE /OUT:DerefNullPtr.exe DerefNullPtr.obj

Now run the application:

C:\\Proj\\Crashes> DerefNullPtr

The standard Windows crash dialog pops up:

Normally users will click “Send Error Report” or “Don’t Send”. If you have access to the machine and a debugger installed you can click “Debug”. Alternatively, you can view the error report details right away by clicking “click here.” If you do, the following dialog pops up:

As you can see, I have put what I consider the most important piece of information from this dialog into a red box: the offset of the instruction which caused the crash. Note that this value is an offset — it’s the address of the crashing instruction relative to where DerefNullPtr.exe is loaded into memory.

We now have enough information to see the instruction which is causing the crash. One way to do this is to use Doron Holan’s windbg¹ dump file trick:

C:\\Proj\\Crashes> windbg -z DerefNullPtr.exe

Microsoft (R) Windows Debugger  Version 6.6.0003.5
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [C:\\Proj\\Crashes\\DerefNullPtr.exe]
Symbol search path is: SRV*C:\\websymbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
ModLoad: 00400000 00408000   C:\\Proj\\Crashes\\DerefNullPtr.exe
eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=00000000 edi=00000000
eip=00401041 esp=00000000 ebp=00000000 iopl=0         nv up di pl nz na pe nc
cs=0000  ss=0000  ds=0000  es=0000  fs=0000  gs=0000             efl=00000000
*** WARNING: Unable to verify checksum for DerefNullPtr.exe
*** ERROR: Module load completed but symbols could not be loaded for DerefNullPtr.exe
DerefNullPtr+0x1041:
00401041 6a18             push    0x18
0:000> u DerefNullPtr+0x1013
DerefNullPtr+0x1013:
00401013 c6050000000001   mov     byte ptr [00000000],0x1
0040101a 5d               pop     ebp
0040101b c3               ret
0040101c 833dc872400002   cmp  dword ptr [DerefNullPtr+0x72c8 (004072c8)],0x2
00401023 7405             jz      DerefNullPtr+0x102a (0040102a)
00401025 e8f0040000       call    DerefNullPtr+0x151a (0040151a)
0040102a ff742404         push    dword ptr [esp+0x4]
0040102e e870030000       call    DerefNullPtr+0x13a3 (004013a3)

The crashing instruction is mov byte ptr [00000000],0x1. Clearly the bug is a null pointer dereference.

Had we produced a map file at link time, we could have done even better. Let me show you:

C:\\Proj\\Crashes> link /SUBSYSTEM:CONSOLE /MAP:DerefNullPtr.map /OUT:DerefNullPtr.exe DerefNullPtr.obj

The map file looks like:

 DerefNullPtr

 Timestamp is 462fae49 (Wed Apr 25 14:38:49 2007)

 Preferred load address is 00400000

 Start         Length     Name                   Class
 0001:00000000 00003b68H .text                   CODE
 0002:00000000 000000c4H .idata$5                DATA
...
 0003:00000030 00000274H .data                   DATA
 0003:000002c0 00000598H .bss                    DATA

  Address         Publics by Value              Rva+Base     Lib:Object

 0000:00000000       __except_list              00000000     <absolute>
 0000:00000002       ___safe_se_handler_count   00000002     <absolute>
 0001:00000000       _main                      00401000 f   DerefNullPtr.obj
 0001:0000001c       __amsg_exit                0040101c f   LIBC:crt0.obj
 0001:00000041       _mainCRTStartup            00401041 f   LIBC:crt0.obj
...
 0003:00000850       __FPinit                   00407850     <common>
 0003:00000854       __acmdln                   00407854     <common>

 entry point at        0001:00000041

 Static symbols

 0001:00000010       _DoCrash                   00401010 f   DerefNullPtr.obj
 0001:000002a2       _doexit                    004012a2 f   LIBC:crt0dat.obj
 0001:0000078b       _parse_cmdline             0040178b f   LIBC:stdargv.obj

The first thing to note is that all addresses in the map file are relative to the preferred load address, 0x00400000. Therefore, we’re looking for the function which contains the address 0x00400000 + 0x00001013 = 0x00401013. To do so, we should look for the function which has the largest address less than or equal to the address of the crash. The function _DoCrash() is at the address 0x00401010, so the crash appears to be at the address _DoCrash+0x3.

Better still is to create a PDB file alongside your retail builds, as in:

C:\\Proj\\Crashes> cl /Zi /Od /nologo /c DerefNullPtr.c
C:\\Proj\\Crashes> link /DEBUG /SUBSYSTEM:CONSOLE /PDB:DerefNullPtr.pdb /MAP:DerefNullPtr.map /OUT:DerefNullPtr.exe DerefNullPtr.obj

Note that the /DEBUG option may be a little confusing — it really should named /CREATEPDB.

Unfortunately, this change will invalidate the previous crash address. (This wouldn’t be a problem if building retail PDBs was part of your normal process) However, we can reproduce the bug within the debugger:

C:\\Proj\\Crashes> windbg DerefNullPtr.exe

Microsoft (R) Windows Debugger  Version 6.6.0003.5
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: DerefNullPtr.exe
Symbol search path is: SRV*C:\\websymbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
ModLoad: 00400000 0040d000   DerefNullPtr.exe
ModLoad: 7c900000 7c9b0000   ntdll.dll
ModLoad: 7c800000 7c8f4000   C:\\WINDOWS\\system32\\kernel32.dll
(3e4.7f4): Break instruction exception - code 80000003 (first chance)
eax=00241eb4 ebx=7ffd9000 ecx=00000000 edx=00000001 esi=00241f48 edi=00241eb4
eip=7c901230 esp=0012fb20 ebp=0012fc94 iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
ntdll!DbgBreakPoint:
7c901230 cc               int     3
0:000> g
(3e4.7f4): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=003214a8 ebx=7ffd9000 ecx=00000001 edx=7c90eb94 esi=00000a28 edi=00000000
eip=00401023 esp=0012fedc ebp=0012fedc iopl=0         nv up ei pl zr na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246
*** WARNING: Unable to verify checksum for DerefNullPtr.exe
DerefNullPtr!DoCrash+0x3:
00401023 c6050000000001   mov     byte ptr [00000000],0x1 ds:0023:00000000=??
0:000> kb
ChildEBP RetAddr  Args to Child
0012fedc 00401018 0012ffc0 00401245 00000001 DerefNullPtr!DoCrash+0x3 [c:\\proj\\crashes\\derefnullptr.c @ 3]
0012fee4 00401245 00000001 00321470 003214a8 DerefNullPtr!main+0x8 [c:\\proj\\crashes\\derefnullptr.c @ 9]
0012ffc0 7c816fd7 00090000 00a7fa9c 7ffd9000 DerefNullPtr!mainCRTStartup+0x173 [f:\\vs70builds\\3077\\vc\\crtbld\\crt\\src\\crt0.c @ 259]
0012fff0 00000000 004010d2 00000000 78746341 kernel32!BaseProcessStart+0x23

Using PDBs, you have the ability to map instruction addresses to a file and line number, even with retail builds. I recommend producing PDBs as part of your build process and placing them somewhere accessible by all developers on your team.

1. Windbg is an extremely powerful debugger included with Microsoft’s free Debugging Tools for Windows.