Larry Osterman's WebLog : Things you shouldn't do.

I can make it arbitrarily fast if I don’t actually have to make it work.

LarryOsterman — Wed, 30 Sep 2009 00:49:37 GMT

Digging way back into my pre-Microsoft days, I was recently reminded of a story that I believe was told to me by Mary Shaw back when I took her Computer Optimization class at Carnegie-Mellon…

During the class, Mary told an anecdote about a developer “Sue” who found a bug in another developer’s “Joe” code that “Joe” introduced with a performance optimization. When “Sue” pointed the bug out to “Joe”, his response was “Oops, but it’s WAY faster with the bug”. “Sue” exploded “If it doesn’t have to be correct, I can calculate the result in 0 time!” [1].

Immediately after telling this anecdote, she discussed a contest that the CS faculty held for the graduate students every year. Each year the CS faculty posed a problem to the graduate students with a prize awarded to the grad student who came up with the most efficient (fastest) solution to the problem. She then assigned the exact same problem to us:

“Given a copy of the “Declaration of Independence”, calculate the 10 most common words in the document”

We all went off and built programs to parse the words in the document, inserting them into a tree (tracking usage) and read off the 10 most frequent words. The next assignment was “Now make it fast – the 5 fastest apps get an ‘A’, the next 5 get a ‘B’, etc.”

So everyone in the class (except me :)) went out and rewrote their apps to use a hash table so that their insertion time was constant and then they optimized the heck out of their hash tables[2].

After our class had our turn, Mary shared the results of what happened when the CS grad students were presented with the exact same problem.

Most of them basically did what most of the students in my class did – built hash tables and tweaked them. But a couple of results stood out.

The first one simply hard coded the 10 most common words in their app and printed them out. This was disqualified because it was perceived as breaking the rules.
The next one was quite clever. The grad student in question realized that they could write the program much faster if they wrote it in assembly language. But the rules of the contest required that they use Pascal for the program. So the grad student essentially created an array on the stack and introduced a buffer overflow and he loaded his assembly language program into the buffer and used that as a way of getting his assembly language version of the program to run. IIRC he wasn’t disqualified but he didn’t win because he circumvented the rules (I’m not sure, it’s been more than a quarter century since Mary told the class this story).
The winning entry was even more clever. He realized that he didn’t actually need to track all the words in the document. Instead he decided to track only some of the words in the document in a fixed array. His logic was that each of the 10 most frequent words were likely to appear in the first <n> words in the document so all he needed to do was to figure out what "”n” is and he’d be golden.

So the moral of the story is “Yes, if it doesn’t have to be correct, you can calculate the response in 0 time. But sometimes it’s ok to guess and if you guess right, you can get a huge performance benefit from the result”.

[1] This anecdote might also come from Jon L. Bentley’s “Writing Efficient Programs”, I’ll be honest and say that I don’t remember where I heard it (but it makes a great introduction to the subsequent story).

[2] I was stubborn and decided to take my binary tree program and make it as efficient as possible but keep the basic structure of the solution (for example, instead of comparing strings, I calculated a hash for the string and compared the hashes to determine if strings matched). I don’t remember if I was in the top 5 but I was certainly in the top 10. I do know that my program beat out most of the hash table based solutions.

The story behind the mysterious “Ding” in Windows Vista.

LarryOsterman — Fri, 04 Sep 2009 03:29:20 GMT

I just ran into this fairly old post on Channel 9. mstefan reported that his applications played a “Ding” noise when selecting an item in a listview (or tree) control.

It turns out that I’d had the problem independently reported to me by one of the people here at Microsoft. Here were his reproduction steps:

Clean Install Windows
Open the sounds control panel
Set the “Select” sound to a value
Clear the “Select” sound (set it to “(None)”).
Change the selection in a listview

Complicating matters is that this didn’t occur with many apps, just a couple of Windows Forms applications that the person at Microsoft had. So I dug into it a bit.

I quickly realized that the problem was that the application was calling PlaySound without the “SND_NODEFAULT” flag. I’ve written about this flag before (in fact I wrote that post shortly after investigating this issue, so that post contains part of the story).

Digging in deeper, I realized that the application was using version 5 of the common controls (there are two versions in Windows, v5 and v6). The problem didn’t occur in the version 6 common controls (this is why most applications didn’t reproduce the problem).

So why did the problem occur?

The common controls have a single routine which calls PlaySound and that code attempts to be somewhat clever. Instead of simply calling PlaySound, the code instead read the HKEY_CURRENT_USER\AppEvents\Schemes\.Default\CCSelect registry key. If the key didn’t exist, it skipped calling PlaySound. If the CCSelect registry key existed, it would call PlaySound specifying the CCSelect alias.

I’ve actually run into this pattern a bunch in WIndows – teams decided that calling PlaySound was “too slow”, or had “too much overhead” so they tried to avoid the call to PlaySound if the call to PlaySound wasn’t going to do anything (once upon a time it was important to avoid calling PlaySound because it could sometimes hang your application for several seconds – this isn’t the case any more if you specify SND_ASYNC).

The problem is that when you hit step 2 above (setting the “Select” sound), the control panel created the CCSelect registry key with a default value of the sound file you’re setting. When you set it to “None” the control panel cleared the value of the sound contained under the key. But the key itself wasn’t deleted. So the check above that checked for the registry key’s existence succeeded and it called PlaySound. But because the call didn’t specify SND_NODEFAULT, the PlaySound API decided to play the default sound when it realized that there wasn’t a sound associated with the CCSelect alias.

I wanted to understand how this bug was introduced so I looked back at the source history of the file containing the bug. It turns out that this was actually a bug fix made to Windows XP that wasn’t incorporated into Windows Server 2003. When Windows Vista was created, the team started with the Windows Server 2003 code base and incorporated all the bug fixes made since Windows XP forked into the Win2K3 code base. For whatever reason, this particular fix was missed when the team did the merge. Because the behavior was so subtle (to trigger the change you MUST go through steps 2 through 4 to get the registry key created and your app must use the v5 of the common controls).

Needless to say, it’s fixed in WIndows 7.

What’s wrong with this code, part 26 – the answer

LarryOsterman — Mon, 29 Jun 2009 21:22:11 GMT

Yesterday I posted a code snippet from inside a real piece of code inside the client side of a client/server utility in a Microsoft product.

static DWORD WINAPI _PlayBeep(__in void* pv)
{
    UNREFERENCED_PARAMETER(pv);
    PlaySound(L".Default", NULL, SND_SYNC | SND_ALIAS);
    return 0;
}

LRESULT WndProc(...)
{
    :
    :
    case WM_KEYDOWN:
        if (!_AcceptInputKeys(wParam, lParam))
        {
            QueueUserWorkItem(_PlayBeep, NULL, 0);
        }
        break;
}

The bug here was that the call to PlaySound is synchronous. Like many Win32 APIs, PlaySound is made thread-safe by taking a critical section around the code that does the work inside the call to PlaySound (since the semantics of PlaySound are that only one PlaySound call plays at any time, this is a reasonable thing to do). Because the call to PlaySound specifies SND_SYNC, that processing is done on the thread that calls PlaySound and thus blocks the _PlayBeep call until the sound completes. The “.Default” sound is approximately 1 second long, so the call to _PlayBeep takes about a second to complete.

Unfortunately keyboards repeat at a lot faster than 1 keystroke/second and each keystroke causes a call to QueueUserWorkItem. Because there’s no thread available to process the request, the thread pool logic creates a new thread to process the next work item for each keystroke. This quickly backs up and eventually you run into the 500 thread limit in the default process threadpool. So you’re going to have the machine play “Ding’s” for hours before this cleans itself up.

But in this case the effects were was even worse.

Remember when I told you that it was a client/server utility? In this case, it meant that it used async RPC to communicate with the server. And async RPC uses the default thread pool for on certain applications. When the response to a server request came in, there were no RPC threads running so RPC tried to create a thread in the default threadpool. Which failed because the default threadpool was full.

So the client/server utility stopped working. It took about 15 seconds of hammering on invalid keys to get the utility into this state, NOT pretty.

The first fix was to change the WM_KEYDOWN to WM_KEYUP (so that you actually had to release the keys instead of letting the typematic feature repeat for you). That didn’t work because it still could be reproduced, it just took longer.

The final fix was:

static DWORD WINAPI _PlayBeep()
{
    PlaySound(L".Default", NULL, SND_ASYNC | SND_ALIAS);
    return 0;
}

LRESULT WndProc(...)
{
    :
    :
    case WM_KEYDOWN:
        if (!_AcceptInputKeys(wParam, lParam))
        {
            _PlayBeep();
        }
        break;
}

So instead of queueing a work item, the team changed the code to simply call PlaySound with SND_ASYNC and they were done. When you specify SND_ASYNC, the PlaySound call queues the request to an internal-to-playsound worker thread, and it cancels the old sound before it starts playing a new sound (thus the sounds don’t back up).

The object lesson here is: Don’t queue long running items to the thread pool because it can lead to unexpected results. And even a 1 second “Ding” can count as “long running” if it can be queued rapidly enough.

What’s wrong with this code, part 26 – a real-world example

LarryOsterman — Thu, 25 Jun 2009 22:26:14 GMT

This is an example of a real-world bug that was recently fixed in an unreleased Microsoft product. I was told about the bug because it involved the PlaySound API (and thus they asked me to code review the fix), but it could happen with any application.

static DWORD WINAPI _PlayBeep(__in void* pv)
{
    UNREFERENCED_PARAMETER(pv);
    PlaySound(L".Default"NULL, SND_SYNC | SND_ALIAS);
    return 0;
}

LRESULT WndProc(...)
{
    :
    :
    case WM_KEYDOWN:
        if (!_AcceptInputKeys(wParam, lParam))
        {
            QueueUserWorkItem(_PlayBeep, NULL, 0);
        }
        break;
}

This is actual code from inside the client side of a client/server component in Windows that was attempting to “beep” on invalid input (I’ve changed the code slightly to hide the actual origin and undoubtedly introduced issues). And it has a whopper of a bug in it.

Given the simplicity of the code above, to get the answer right, it’s not enough to say what’s wrong with the code (the problem should be blindingly obvious). You also need to be able to explain why this is so bad (in other words, what breaks when you do this).

Bonus points if you can identify the fix that was eventually applied.

Delay Load is not a good way to check for functionality

LarryOsterman — Fri, 06 Mar 2009 23:19:26 GMT

On my previous post, Koro made the following comment:

“Don't ever check windows versions. Instead check for functionality being present or not."

You can't always do that.

Do I want to add a __try/__except to catch delay-load exceptions around every UxTheme call or just do:

g_bTheme=(g_bWinNT&&(g_nWinVer>0x00050001));

Then check that flag before calling OpenThemeData?

In some other cases too (all the Crypt Hash functions - trying to compute an MD5) the functions is documented as working fine in Win98 but it just fails - there is no way to know except of checking the version beforewards.

At least, as implied earlier, I just pack the Windows version in a DWORD at program startup to avoid nasty version comparision errors.

IMHO Koro’s misusing the delayload functionality.

DelayLoad is primarily a performance tool – when you DelayLoad a function, a tiny stub for the DelayLoad function is inserted into your application which calls LoadLibrary/GetProcAddress on the function. That then means that when your application is launched, the loader doesn’t resolve references to the DelayLoaded function and thus your application will launch faster.

For example many components in the OS delay load WINMM.DLL because all they use in WINMM is the PlaySound API, and even then they only use it on relatively rare circumstances. By delayloading WINMM.DLL they avoid having the performance penalty of having WINMM.DLL loaded into their address until it’s needed.

As Koro mentioned, DelayLoad can also be used as a mechanism to check to see if a particular piece of OS functionality is present, but the challenge is that now you need to wrap every API call with an exception handler (or you need to specify a delay load handler that provides a more reasonable default behavior). Personally I wouldn’t do that – instead I’d manually call LoadLibrary/GetProcAddress to load the required functions because it allows you to have complete control over when you access over your error handling. It also allows you to avoid using structured exception handling (which should be avoided if at all possible).

If you DO have need to use DelayLoad as a functionality check, you could try this trick (which works only for Koro’s problem). Instead of wrapping all the theme API calls with SEH, you just add code to your app like this (I haven’t compiled this code, it’s just an example):

BOOL g_EnableThemes = FALSE;
__try
{
    g_EnableThemes = IsThemeActive();
}
__except(<Your Exception Filter>)
{
}

if (g_EnableThemes)

{
    g_ThemeHandle = OpenThemeData(…)





}

In other words check for functionality being enabled once with an exception handler and later on use just the EnableThemes global variable to key off the behavior.

But this doesn’t change the fact that (IMHO) you’re abusing the DelayLoad functionality and using it as a versioning mechanism.

Checking file versions is surprisingly hard.

LarryOsterman — Fri, 06 Mar 2009 02:34:30 GMT

I was wandering around the web the other day and ran into this post. In general I don’t have many issues with the post, until you get to the bottom of the article. The author mentions that his code only runs on Win7 or newer so he helpfully included a check to make sure that his code only runs on WIn7:

// Example in C#.

internal bool SupportsTaskProgress() {
    if (System.Environment.OSVersion.Version.Major >= 6) {
        if (System.Environment.OSVersion.Version.Minor >= 1) {
            return true;
        }
    }
    return false;
}

This is a great example of why it’s so hard to write code that checks for versions. The problem here is that this code is highly likely to fail to work on the next version of Windows (or whenever Windows 7.0 is released). In that case SupportsTaskProgress will incorrectly return false.

Personally I wouldn’t even bother writing the SupportsTaskProgress function this way. Instead I’d check for the “new TaskbarLib.TaskbarList()” call to return NULL and assume that if it returned NULL the API call wasn’t supported (the non COM interop equivalent would be to check for a failure on the call to CoCreateInstance). That way the code would work even if (for some obscure reason) the taskbar logic was ported to a previous OS version.

If I simply HAD to keep the SupportsTaskProgress function, I’d rewrite it as:

// Example in C#.

internal bool SupportsTaskProgress() {
    if (System.Environment.OSVersion.Version.Major >= 6) {
        if (System.Environment.OSVersion.Version.Major == 6) {
            if (System.Environment.OSVersion.Version.Minor >= 1) {
                return true;
            }
            return false;
        }
        return true;
    }
    return false;
}

That way it would only check for minor version being greater than 1 if the major version is 6. I suspect that this code could be tightened up further as well.

This is a part of the reason that picking a version number for the OS is so complicated.

PlaySound(xxx, SND_MEMORY | SND_ASYNC) is almost always a bad idea.

LarryOsterman — Fri, 20 Feb 2009 01:31:57 GMT

Whenever you submit a crash report to OCA, a bug gets filed in the relevant product database and gets automatically assigned to the developer responsible for the code. I had a crashing bug in the PlaySound API assigned to me.

In this case, the call was crashing deep inside of the waveOutOpen API and it was crashing because the input WAVEFORMATEX structure was bogus. The strange thing is that the PlaySound API does some fairly thorough validation of the input WAVEFORMATEX read from the .WAV file and that validation had to have passed to get to the call to waveOutOpen.

I looked a bit deeper and came to the realization that every single one of the crashes (in maybe a dozen different applications) had specified SND_MEMORY | SND_ASYNC in their call to PlaySound.

I’ve talked about that particular combination before in my blog, but I wanted to call it out in a top level post in the hopes that people will stop making this common mistake.

When you call PlaySound with the SND_MEMORY flag, it tells the PlaySound API that instead of reading the audio data from a file, you’re passing in a pointer to memory which holds the wave contents for you. That’s not controversial, and can be quite handy if (for instance) you want to build a .WAV file in memory instead of calling the wave APIs directly.

When you call PlaySound with the SND_ASYNC flag, that flag tells PlaySound that instead of blocking until the sound has finished playing, the API should return immediately instead of blocking while the sound is played.

Neither of these flags is controversial and neither of them is particularly dangerous until you combine the two together.

The problem is that there’s really no way of knowing when the sound has finished playing and thus when the application frees the memory, it’s entirely possible that the PlaySound API is still using it. That means that if you ever call PlaySound with both of these flags, you stand a very high chance of crashing due to the combination of these behaviors.

The unfortunate thing is that this behavior has existed since the SND_MEMORY flag was added back in Windows 3.1. The only safe way of dealing with this that works on all current Windows operating systems is to call PlaySound(NULL, 0, 0) before freeing the memory – the call to PlaySound(NULL, 0, 0) will block until the currently playing sound has completed playing (or abort the playsound if it hasn’t started yet).

Fixing a customer problem: “No Audio Device is Installed” when launching sndvol on Windows Vista

LarryOsterman — Tue, 06 Jan 2009 22:26:03 GMT

Yesterday someone forwarded me an email from one of our DirectShow MVPs – he was having problems playing audio on his Windows Vista machine.

Fortunately David (the MVP) had done most of the diagnostic work – the symptoms he saw were that he was receiving a “No Audio Device is Installed” error launching sndvol (and other assorted problems).

David tried the usual things (confirming that the driver for his audio solution was correctly installed (this probably fixes 99% of the problems)). He also tried reinstalling the driver to no avail.

He next ran the Sysinternals Process Monitor tool to see what was going on. He very quickly found the following line in the output from process monitor:

"RegOpenKey", "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\MMDevices\Audio\Render\{e4ee1234-fc70-4925-94e9-4117395f7995}", "ACCESS DENIED", "Desired Access: Write"

With that information, he looked for the ACL on that registry key:

He then looked at the configuration for the Windows Audio service:

Woah – the Windows Audio service doesn’t have access rights to that registry key – the Windows Audio service is running as LocalService and the LocalService account doesn’t have any access to the registry key.

At this point he decided to contact Microsoft with his problem.

I looked at his info and quickly realized that the problem was that somehow the ACL on the registry key had been corrupted: something had removed the entries for the audio services. On a normal Windows Vista installation this registry key’s ACL should look something like:

Something that ran on David’s machines went in and reset the permissions for this registry key to the ACL that is on the root node of the HKEY_LOCAL_MACHINE\Software registry hive. I have no idea what did this, but messing with the ACLs on the registry is a known cause of various compatibility problems. That’s why Microsoft KB 885409 has such strong warnings about why it’s important to not apply blind modifications to files or registry keys in Windows. It’s unfortunate, but the warnings in the KB articles that say that modifying registry keys or permissions can cause your machine to malfunction are absolutely right – it’s not hard to make modifications to registry keys that can really screw up a machine, if you make the right ones. From the KB article:

For example, modifications to registry ACLs affect large parts of the registry hives and may cause systems to no longer function as expected. Modifying the ACLs on single registry keys poses less of a problem to many systems. However, we recommend that you carefully consider and test these changes before you implement them. Again, we can only guarantee that you can return to the recommended out-of-the-box settings if you reformat and reinstall the operating system.

The good news is that it should be relatively simple to fix David’s problem – As far as I know, he has two options. The first is to reinstall Windows Vista – that should reset the ACLs on the property key to their default values (because it will recreate the property keys), which should resolve the problem.

The second solution is to add an ACL to the registry keys under the MMDevices registry key to allow the LocalService account to have permissions to modify this registry key.

I get more spam :)

LarryOsterman — Sat, 22 Nov 2008 03:58:51 GMT

I just received this phishing letter, I liked it simply because it was so remarkably brazen:

--

Dear Webmail User,

This message was sent automatically by a program on Webmail which periodically checks the size of inbox, where new messages are received. The program is run weekly to ensure no one's inbox grows too large. If your inbox becomes too large, you will be unable to receive new email.

Just before this message was sent, you had 18 Megabytes (MB) or more of messages stored in your inbox on Webmail. To help us re-set your SPACE on our database prior to maintain our INBOX, you must reply

to this e-mail and enter your Current UserID: ( ) and

Password ( ) Select server ( ) if any

You will continue to receive this warning message periodically if your

inbox size continues to be between 18 and 20 MB. If your inbox size grows

to 20 MB, then a program on Webmail will move your oldest

email to a folder in your home directory to ensure that you will

continue to be able to receive incoming email. You will be notified by email

that this has taken place. If your inbox grows to 25 MB, you will be unable to

receive new email as it will be returned to the sender.After you read a

message, it is best to REPLY and SAVE it to another folder.

Thank you for your cooperation.

Webmail Help Desk

---------------------------------------------------------------------------

3webXS HiSpeed Dial-up...surf up to 5x faster than regular dial-up alone...

just $14.90/mo...visit www.get3web.com for details

The email was in plain text from “Webmail Service Support [general@3web.net]” (I don’t feel bad about including their real email address on a post on the web, after all they deserve to get spam, right?

As I said, I thought it was remarkably brazen and very low budget. Why bother trying to set up a domain when you can get the victim to send you their credentials by email :).

What’s wrong with this code, part 25

LarryOsterman — Mon, 17 Nov 2008 19:43:00 GMT

Wow, 25 already.

This one’s pretty straightforward. Once again, it’s a UI issue, since I’ve been spending most of my time doing UI lately.

In this particular case, the code comes from the constructor for an auto-layout class that is used internally in one of our tools. It saves away window handles for a control and the dialog which holds the control, then saves the size of the dialog and relative location of the control within that dialog. There’s other code that handles resizing and adjusting the layout of the control when the dialog is resized.

CControlLayout::CControlLayout(const HWND hWndControl, const HWND hWndDlg)
    : m_hWnd(hWndControl)
    , m_hWndDlg(hWndDlg)
{
    // Get the parent (dialog) rect, and the control rect
    ::GetClientRect(m_hWndDlg, &m_rcRefDlg);
    ::GetWindowRect(m_hWnd, &m_rcRef);
    ScreenToClientRect(hWndDlg, m_rcRef);
}

void ScreenToClientRect(/* [in] */ const HWND hWndClient, 
                        /* [in/out] */ RECT &rcInOut)
{
 CPoint ptTopLeft(rcInOut.left, rcInOut.top);
 CPoint ptBottomRight(rcInOut.right, rcInOut.bottom);

 ::ScreenToClient(hWndClient, &ptTopLeft);
 ::ScreenToClient(hWndClient, &ptBottomRight);

 rcInOut.left = ptTopLeft.x;
 rcInOut.top = ptTopLeft.y;
 rcInOut.right = ptBottomRight.x;
 rcInOut.bottom = ptBottomRight.y;
}

m_rcRefDlg holds the reference rect for the dialog and m_rcRef holds the reference rect for the control relative to the dialog.

This code has been in the UI for quite a while and recently one of our testers discovered a nasty bug while running a test pass.

The question is: What’s wrong with this code. I believe we shipped Windows Vista with this bug (I’m not 100% sure, since I don’t have a Windows Vista machine to test it), so it’s pretty subtle.

Edit: OOPS - I forgot to include ScreenToClientRect.

I get spam :)

LarryOsterman — Tue, 14 Oct 2008 19:13:04 GMT

I just received this spam message the other day:

From: Microsoft [mailto:customerservice@microsoft.com]

Sent: Saturday, October 11, 2008 11:13 PM

To: Larry Osterman

Subject: Security Update for OS Microsoft Windows

Dear Microsoft Customer,

Please notice that Microsoft company has recently issued a Security Update for OS Microsoft Windows. The update applies to the following OS versions: Microsoft Windows 98, Microsoft Windows 2000, Microsoft Windows Millenium, Microsoft Windows XP, Microsoft Windows Vista.

Please notice, that present update applies to high-priority updates category. In order to help protect your computer against security threats and performance problems, we strongly recommend you to install this update.

Since public distribution of this Update through the official website http://www.microsoft.com would have result in efficient creation of a malicious software, we made a decision to issue an experimental private version of an update for all Microsoft Windows OS users.

As your computer is set to receive notifications when new updates are available, you have received this notice.

In order to start the update, please follow the step-by-step instruction:

1. Run the file, that you have received along with this message.

2. Carefully follow all the instructions you see on the screen.

If nothing changes after you have run the file, probably in the settings of your OS you have an indication to run all the updates at a background routine. In that case, at this point the upgrade of your OS will be finished.

We apologize for any inconvenience this back order may be causing you.

Thank you,

Steve Lipner

Director of Security Assurance

Microsoft Corp.

-----BEGIN PGP SIGNATURE-----

Version: PGP 7.1

AN86DCS206WKI6IK8LIFD5S1VODA48SHXDCG6KT8V4C50MO21RUHP8O84T6P73YGX

EO755U27OA5JVX3U51QF8N2E97FQQDOC6IRHH7T3TSQJRFYYPR3434M634A375LAO

49ICIMQZ680BR307KVS857K6U9UYSBHE20RNI16HUB45SMTDF0DDMQZ4YIR2QIHLD

UVPMVD54LRY8HNLDA020KWMIFYYD9B1A07AM1VWIA0YO8QZO2WLY27KAPXBFDN6DT

48VYUVW7M7JZ5P2NIU7FGDRIGCM819WMKJ2==

-----END PGP SIGNATURE-----

Attached to the message was an attachment named “KB266311.exe”.

I’ve heard that these before but I’ve never received one. Apparently the email was sent from “koln-5d8184e2.pool.einsundeins.de (93.129.132.226)”, which I suspect is a trojaned machine in Germany. In this case I’m pretty impressed with the email – it’s in plain text with the name of a real Microsoft employee, it has a PGP signature (which tends to give credence to the email). On the other hand it has some grammatical errors (“Please notice that Microsoft company has…”, “We apologize for any inconvenience this back order may be causing you”) that give the scam away. I also don’t know what trojan was inside KB266311 because it was filtered by our email servers before it got to me.

For those that are wondering how I knew it came from koln-5d8184e2.pool.einsundeins.de, here’s what I did:

I started with the raw email headers (some servers and IP addresses obscured):

Received: from XXX.microsoft.com (n.n.n.n) by
YYY.microsoft.com (m.m.m.m) with Microsoft SMTP
Server (TLS) id 8.2.83.0; Sat, 11 Oct 2008 23:13:52 -0700
Received: from koln-5d8184e2.pool.einsundeins.de (93.129.132.226) by
ZZZ.microsoft.com (o.o.o.o) with Microsoft SMTP Server id
8.1.291.1; Sat, 11 Oct 2008 23:13:41 -0700
Received: from [93.129.132.226] by QQQ.hotmail.com; Sun, 12 Oct 2008 07:13:17
+0100
From: Microsoft <customerservice@microsoft.com>
To: <<Larry’s Email Address>>
Subject: Security Update for OS Microsoft Windows
Date: Sun, 12 Oct 2008 07:13:17 +0100
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_000E_01C92C39.FF9CE480"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Thread-Index: Aca6Q862Q89QD80AN22RHXR0U7WZ61==
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Message-ID: <01c92c39$ff9ce480$e284815d@60GC7Q>
Return-Path: 60GC7Q@hotmail.com
X-MS-Exchange-Organization-PRD: microsoft.com
Received-SPF: TempError (XXX.microsoft.com: error in
processing during lookup of customerservice@microsoft.com: DNS timeout)
X-MS-Exchange-Organization-PCL: 2
X-MS-Exchange-Organization-Antispam-Report: DV:3.3.7011.600;SV:3.3.7011.1437;SID:SenderIDStatus
TempError;OrigIP:93.129.132.226
X-MS-Exchange-Organization-SCL: 0
X-MS-Exchange-Organization-SenderIdResult: TEMPERROR

RFC 2821 says that SMTP servers should prepend a Received: header to an email message whenever they process the email message. In this case the last email server was XXX.microsoft.com. XXX.microsoft.com received the message from YYY.microsoft.com which in turn received the message from koln-5d8184e2.pool.einsundeins.de (einsundeins.de appears to be a german ISP). The next bit of trace is confusing. The machine at 93.129.132.226 says that it received the message from QQQ.hotmail.com.

It’s possible that this spam email originated from hotmail, but I don’t think so. First off, as far as I know, you can’t relay through the hotmail SMTP servers and the sender of the email is “customerservice@microsoft.com” (the sender is included in the Received-SPF header which indicates that the “MAIL FROM” header in the SMTP exchange was “customerservice@microsoft.com”. Secondly the hotmail servers don’t set the X-Mailer header, but this header indicates that it was sent from Outlook 2003. Instead, I think that the bottom Received: header was forged to throw off people trying to figure out where the email came from.

Needless to say, Microsoft will never EVER send a security update to customers by mail, and customers should immediately delete any emails that claim to have security fixes from Microsoft.

What’s wrong with this code part 24 (From an MSDN article)?

LarryOsterman — Tue, 07 Oct 2008 02:52:00 GMT

I ran into this bug earlier today and realized that it’d make an awesome “What’s wrong with this code”.

I started pulling together a test app when I realized that this MSDN magazine article contains sample code that perfectly exhibits the bug:

CRect rectangle;
VERIFY(m_splitButton.GetWindowRect(
    &rectangle));

TPMPARAMS params = { sizeof(TPMPARAMS) };
params.rcExclude = rectangle;

CMenuHandle menu = m_menu.GetSubMenu(0);

VERIFY(menu.TrackPopupMenuEx(TPM_LEFTBUTTON,
    rectangle.left, rectangle.bottom,
    m_hWnd, &params));

There’s not much to the code – it’s from the handler for the BCN_DROPDOWN notification message. And it’s got a very ~~nasty~~ subtle bug in it.

So what’s the bug?

Edit: s/nasty/subtle/

What’s wrong with this code, Part 23 – The Answers

LarryOsterman — Tue, 09 Sep 2008 01:19:05 GMT

My last post was all about a problem with what appeared to be some really simple ATL code.

It turns out that the problem was easier than I had expected. James Skimming came up with the answer on the second comment. The problem here was that the following code (snipped a bit)

IMMDeviceEnumerator *GetDeviceEnumerator()
{
    CComPtr<IMMDeviceEnumerator> deviceEnumerator;

    HRESULT hr = deviceEnumerator.CoCreateInstance(__uuidof(MMDeviceEnumerator));
    if (FAILED(hr))
    {
        return NULL;
    }
    return deviceEnumerator.Detach();

}
int _tmain(int argc, _TCHAR* argv[])
{
    CoInitialize(NULL);
    {
        CComPtr<IMMDeviceEnumerator> deviceEnumerator(GetDeviceEnumerator());
        CComPtr<IMMDeviceCollection> deviceCollection;

        if (deviceEnumerator != NULL)
        {
            HRESULT hr = deviceEnumerator->EnumAudioEndpoints(eAll, DEVICE_STATE_ACTIVE, &deviceCollection);
            if (SUCCEEDED(hr))
            {

That’s because the CComPtr<T> constructor takes a reference to the input T* object. As a result, the code leaks a reference to the MMDeviceEnumerator object. The correct fix for the problem generated a fair amount of discussion in the comments and on email internally.

The root cause of the problem is that the code in question mixes raw interface pointers and smart pointers. In this case there’s an impedance mismatch between the GetDeviceEnumerator (which returns a raw pointer) and it’s caller (which is expecting a smart pointer).

My preferred solution to the problem is:

CComPtr<IMMDeviceEnumerator> GetDeviceEnumerator()
{
    CComPtr<IMMDeviceEnumerator> deviceEnumerator;

    HRESULT hr = deviceEnumerator.CoCreateInstance(__uuidof(MMDeviceEnumerator));
    if (FAILED(hr))
    {
        return NULL;
    }
    return deviceEnumerator;

}

The reason I prefer this solution is that it consistently uses the smart pointer class. There are two downsides to it. The first is that it loses the result of the call to CoCreateInstance. The other downside is that it constructs a temporary object on the stack and has two additional calls to AddRef()/Release().

There are other possible solutions. The second possible solution changes the GetDeviceEnumerator function:

HRESULT GetDeviceEnumerator(IMMDeviceEnumerator *Enumerator)
{
    CComPtr<IMMDeviceEnumerator> deviceEnumerator;

    if (Enumerator == NULL)
    {
        return E_POINTER;
    }
    HRESULT hr = deviceEnumerator.CoCreateInstance(__uuidof(MMDeviceEnumerator));
    if (FAILED(hr))
    {
        *Enumerator = NULL;
        return hr;
    }
    *Enumerator = deviceEnumerator.Detach();

    return S_OK;
}

With this change, the caller looks like:

    {
        CComPtr<IMMDeviceEnumerator> deviceEnumerator;
        if (SUCCEEDED(GetDeviceEnumerator(&deviceEnumerator))
        {
            CComPtr<IMMDeviceCollection> deviceCollection;
            HRESULT hr = deviceEnumerator->EnumAudioEndpoints(eAll, DEVICE_STATE_ACTIVE, &deviceCollection);
            if (SUCCEEDED(hr))

This solution fits closely with the COM usage pattern so it is quite attractive. You also don’t lose the result of the CoCreateInstance API call, which can be extremely useful for diagnostics. The major negative with this is that it depends on the fact that the CComPtr<T> operator& returns a raw pointer to the underlying object.

The third possible solution keeps the “return a value” idea of the original code but works around the additional reference applied in the constructor. Keep the original implementation of GetDeviceEnumerator and change the tmain function as follows:

int _tmain(int argc, _TCHAR* argv[])
{
    CoInitialize(NULL);
    {
        CComPtr<IMMDeviceEnumerator> deviceEnumerator;
        deviceEnumerator.Attach(GetDeviceEnumerator());
        CComPtr<IMMDeviceCollection> deviceCollection;

The big problem with this solution is that to me it’s “unnatural” – the whole point of using smart pointers is that their use is supposed to be intuitive, however in this case there’s nothing intuitive about the use – it certainly fixes the problem but it relies on internal behaviors of the smart pointer class. To me this is the least attractive solution to the problem.

As I mentioned, Kudos to James Skimming for figuring the problem out quickly.

What’s wrong with this code, Part 23..

LarryOsterman — Fri, 05 Sep 2008 18:45:38 GMT

I recently tracked down a bug that was causing problems in my code. Once I figured out the bug, I realized it made a good “what’s wrong with this code”…

#include "stdafx.h"
#include <mmdeviceapi.h>


IMMDeviceEnumerator *GetDeviceEnumerator()
{
    CComPtr<IMMDeviceEnumerator> deviceEnumerator;

    HRESULT hr = deviceEnumerator.CoCreateInstance(__uuidof(MMDeviceEnumerator));
    if (FAILED(hr))
    {
        return NULL;
    }
    return deviceEnumerator.Detach();

}
int _tmain(int argc, _TCHAR* argv[])
{
    CoInitialize(NULL);
    {
        CComPtr<IMMDeviceEnumerator> deviceEnumerator(GetDeviceEnumerator());
        CComPtr<IMMDeviceCollection> deviceCollection;

        if (deviceEnumerator != NULL)
        {
            HRESULT hr = deviceEnumerator->EnumAudioEndpoints(eAll, DEVICE_STATE_ACTIVE, &deviceCollection);
            if (SUCCEEDED(hr))
            {
                UINT deviceCount;
                hr = deviceCollection->GetCount(&deviceCount);
                if (SUCCEEDED(hr))
                {
                    printf("There are %d audio endpoints on the machine\n", deviceCount);
                }
            }
        }
    }
    CoUninitialize();
    return 0;
}

Simple code, right? But there’s a nasty bug hidden in there, and it was NOT obvious to me what the bug was.

As always, kudos to the person who gets the bug first. And of course mea culpa's for bugs I accidentally included.

What’s wrong with this code, part 22 – Drawing Text…

LarryOsterman — Sat, 02 Aug 2008 01:07:43 GMT

Recently I’ve been working on something that I’ve never done before in my almost 24 years at Microsoft.

For the past 23ish years, I’ve been a plumber – all the work I’ve done has been under the covers. But for the next version of Windows, I decided to stretch my boundaries a bit and try some UI programming. I’ve just spent the past few days working on a cool change to the volume control (it’s not important what it is, and most people will never know about the change, but those that do will probably agree with me :)).

As part of the change, I needed to measure the dimensions of a text string. This is a dummy version of some code I wrote, I simply called DrawText with the DT_CALCRECT into a memory DC that I created.

BOOL InitInstance(HINSTANCE hInstance, int nCmdShow)
{
   HWND hWnd;

   hInst = hInstance; // Store instance handle in our global variable

   hWnd = CreateWindow(szWindowClass, szTitle, WS_OVERLAPPEDWINDOW,
      CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL, hInstance, NULL);

   if (!hWnd)
   {
      return FALSE;
   }

<BEGIN LARRYS CODE>
   HDC hdc = CreateCompatibleDC(NULL);

   RECT rcText = {0, 0, 88, 34};

   DrawText(hdc, L"My Text String", -1, &rcText, DT_CENTER | DT_END_ELLIPSIS | DT_EDITCONTROL | DT_WORDBREAK | DT_NOPREFIX | DT_CALCRECT);

   CAtlString string;
   string.Format(L"Text String occupies: %d x %d pixels", rcText.right - rcText.left, rcText.bottom - rcText.top);
   MessageBox(hWnd, string, L"String Size", 0);
<END LARRYS CODE> 
   ShowWindow(hWnd, nCmdShow);
   UpdateWindow(hWnd);

   return TRUE;
}

This is just code I took by using Visual Studio to create a Windows Win32 project and inserting the code between “BEGIN LARRYS CODE” and “END LARRYS CODE”. The meat of the code is just 3 lines of code.

Even though there’s almost no code here, it still has a bug in it that was quite subtle and took me several hours to find.