November, 2011

  • The Old New Thing

    We've traced the call and it's coming from inside the house: A function call that always fails

    • 64 Comments

    A customer reported that they had a problem with a particular function added in Windows 7. The tricky bit was that the function was used only on very high-end hardware, not the sort of thing your average developer has lying around.

    GROUP_AFFINITY GroupAffinity;
    ... code that initializes the GroupAffinity structure ...
    if (!SetThreadGroupAffinity(hThread, &GrouAffinity, NULL));
    {
     printf("SetThreadGroupAffinity failed: %d\n", GetLastError());
     return FALSE;
    }
    

    The customer reported that the function always failed with error 122 (ERROR_INSUFFICIENT_BUFFER) even though the buffer seems perfectly valid.

    Since most of us don't have machines with more than 64 processors, we couldn't run the code on our own machines to see what happens. People asked some clarifying questions, like whether this code is compiled 32-bit or 64-bit (thinking that maybe there is an issue with the emulation layer), until somebody noticed that there was a stray semicolon at the end of the if statement.

    The customer was naturally embarrassed, but was gracious enough to admit that, yup, removing the semicolon fixed the problem.

    This reminds me of an incident many years ago. I was having a horrible time debugging a simple loop. It looked like the compiler was on drugs and was simply ignoring my loop conditions and always dropping out of the loop. At wit's end, I asked a colleague to come to my office and serve as a second set of eyes. I talked him through the code as I single-stepped:

    "Okay, so we set up the loop here..."

    NODE pn = GetActiveNode();
    

    "And we enter the loop, continuing while the node still needs processing."

    if (pn->NeedsProcessing())
    {
    

    "Okay, we entered the loop. Now we realign the skew rods on the node."

     pn->RealignSkewRods();
    

    "If the treadle is splayed, we need to calibrate the node against it."

     if (IsSplayed()) pn->Recalibrate(this);
    

    "And then we loop back to see if there is more work to be done on this node."

    }
    

    "But look, even though the node needs processing «view node members», we don't loop back. We just drop out of the loop. What's going on?"

    Um, that's an if statement up there, not a while statement.

    A moment of silence while I process this piece of information.

    "All right then, sorry to bother you, hey, how about that sporting event last night, huh?"

  • The Old New Thing

    Debugging why a user's taskbar disappeared

    • 20 Comments

    A customer reported that they had gone to the Screen Saver control panel, selected a screen saver that they had recently downloaded, then hit the Test button to see what it looked like. He was pleased with what he saw, and he went home, leaving the screen saver running.

    When he returned the following morning, he found that the screen saver had crashed. (There was an error message on the screen.) After dismissing the crash dialog, he found that his taskbar was missing. What happened?

    We were unable to determine for sure, but debugging the customer's machine revealed that the taskbar no longer had the WS_VISIBLE style, most likely because the screen saver had done a Show­Window(hwnd, SW_HIDE) on the taskbar window in a misguided attempt to ensure that the taskbar was not visible while the screen saver was running.

    The authors of the screen saver intended to re-show the taskbar when the screen saver was dismissed, but since it crashed, it never got its chance.

    This is another case of using a global setting to solve a local problem. The local problem is "I don't want the taskbar to be visible while my program is running," and this can be accomplished with a local solution. Instead, they used a global setting (even worse, an undocumented global setting) and since the program crashed, it never got its chance to restore that global setting to its previous value, leaving the setting borked.

  • The Old New Thing

    The power of statistical photography

    • 12 Comments

    Inside Microsoft, there was an employee photography contest to provide images to be included in Windows 7, either in one of the pre-release versions or in the final product. Each subsidiary selected the photos to be included in their localized version of Windows, choosing images which best reflect that region's culture, history, and natural beauty. The employee-submitted photos were in direct competition against the professional photographs; as a result, some regions ended up selecting multiple employee-contributed images and others picked none. The Swiss delegation, in characteristically Swiss fashion, put it to a public vote.

    (As you may recall, Windows Vista included photographs drawn from the community. That article is another great example of No matter what you do, somebody will call you an idiot. Microsoft decides to involve the community in a fun way, and the result is condemnation from the professional photographic community.)

    Around 2000 photographs were submitted by Microsoft employees, and one of the photos selected for the U.S. version of Windows 7 Beta was taken by a member of the user interface team. In response to congratulations, he humbly replied, "I'm a statistical photographer. I rely on sheer quantity to produce occasional quality."

    Bonus reading: A Look Behind the Backgrounds of Windows 7.

Page 3 of 3 (23 items) 123