August, 2010

  • The Old New Thing

    Shutdown reason codes are reason codes, not error codes or HRESULTs


    A customer liaison asked the following question on behalf of his customer:

    My customer is finding that their Windows Server 2003 system has restarted, and they want to find out why. I've found some event log similar to the ones below, but I don't know what error code 0x84020004 is. I've searched the Knowledge Base but couldn't find anything relevant. Please let me know why the system restarted.

    Event Type: Information
    Event Source: USER32
    Event Category: None
    Event ID: 1074
    Date: 3/20/2009
    Time: 11:51:30 AM
    User: GROUP1\infraadmin
    Computer: DATA2
    The process Explorer.EXE has initiated the shutdown of computer SYSP1 on behalf
    of user GROUP1\infraadmin for the following reason: Operating System: 
    Reconfiguration (Planned)
    Reason Code: 0x84020004
    Shutdown Type: restart

    The value 0x84020004 is not an error code. It says right there that it's a reason code:

    Reason Code: 0x84020004

    The system shutdown reason codes are documented in MSDN under the devious heading System Shutdown Reason Codes. In this case, the value 0x84020004 is a combination of

    SHTDN_REASON_FLAG_PLANNED               0x80000000
    SHTDN_REASON_FLAG_CLEAN_UI              0x04000000 // reason.h
    SHTDN_REASON_MINOR_RECONFIG             0x00000004

    That value for SHTDN_REASON_FLAG_CLEAN_UI is missing from the MSDN documentation for some reason, but's listed in reason.h. The flag means that the system was shut down in a controlled manner, as opposed to SHDTN_REASON_FLAG_DIRTY_UI which means that the system lost power and did not go through a clean shutdown.

    In other words, this was a planned shutdown that was the result of an operating system reconfiguration. Perhaps somebody changed a system setting in the Control Panel, and in response to the question "The change you made requires that the system be restarted. Restart now?", the person said Yes.

  • The Old New Thing

    Be on the alert: Mainstream and alternative medicines mixed together on the store shelves, not clearly distinguished


    I was in the supermarket looking for cold medicine, and as is my wont, I like to read the fine print before choosing a product. Most of the products listed their active ingredients in the form Active Ingredient: XYZ 150mg. But there were a few that said Active Ingredient: XYZ 6X.

    What is this 6X? How much is 6X? Six times what?

    A closer look at the box reveals the word Homeopathic unobtrusively written towards the bottom of the box. The 6X notation means that the active ingredient's concentration is one part in 106, or one part in a million.

    Suppose the dosage is one teaspoon. That's about five milliliters, or about five grams of medicine. One millionth of that is 5 × 10-6 of a gram or 0.005 milligrams. By comparison, non-homeopathic medicines contain 13mg of the same medicine per dose. But that's okay, because practitioners of homeopathy believe that a medicine becomes more powerful the more heavily it is diluted.

    The Food and Drug Administration does not regulate homeopathic medicines very much at all because they contain little or no active ingredients.

    Do practitioners of homeopathy not wash their hands? After all, diluting the germs with water makes them stronger, right? The more you wash, the more powerful they become!

    Bonus homeopathy video: Homeopathic A&E as performed by British comedy show That Mitchell and Webb Look. (A&E = Accidents and Emergencies, what in the United States is commonly called the Emergency Room.)

    Bonus homeopathy satire: New Age terrorists develop homeopathic bomb.

    Obligatory XKCD link.

  • The Old New Thing

    Reflections create Xbox logo on neighbor's roof


    In other parts of the world, religious images emerge from random patterns. Out here, we get Microsoft marketing.

    If I were on it, I could've charged admission.

  • The Old New Thing

    On LockWindowUpdate: Locking the taskbar


    Andy Visser posted to the Suggestion Box something that wasn't so much a suggestion as a comment, presumably to get around the fact that comments on the original item had been closed: "I've found that the start bar seems to behave like it may be using this call incorrectly. I put my start bar on the left hand side of the screen. When I try to resize the bar (dragging its edge left and right), the system tray will dynamically move icons (based on tray width), seemingly disregarding the lock. The rest of the bar waits until MouseUp to redraw."

    Actually, the taskbar (that's the name of the thing you're referring to) does not call LockWindowUpdate at all, so what you're seeing is not the result of any incorrect use of LockWindowUpdate. I've also been unable to reproduce the behavior you describe. I tried Windows XP, Windows Vista, and Windows 7 both with and without Show window contents while dragging enabled, and the notification area (that's the name of the thing you're referring to) repaints at the same time as the rest of the taskbar. I don't see it "bypassing" anything.

    This comment demonstrates one of the common problems with bug reports submitted from the field: The description of the problem rarely includes the system configuration under which the problem occurs—they often don't even mention what operating system they're running! The person submitting the comment generally assumes that you will somehow know how their computer is configured (or believes that the problem is not configuration-dependent). This leaves people like me trying to reproduce the problem on various systems with various configurations before finally giving up and saying "Sorry, I don't see it."

    In some cases, the configuration setting that created the unwanted behavior is a setting whose sole purpose is to establish the unwanted behavior. For example, a customer reported, "Windows Vista is not displaying the user's picture on the Start menu or the logon screen. We discovered that the Apply the default user logon picture to all users policy prevents the user's customized picture from being displayed. We removed that policy, but that did not solve the problem. Is there anything else that might be causing this?"

    I found it interesting that the customer initially wondered why the user's custom picture wasn't showing up, when they had explicitly set the policy that says "Do not use the user's custom picture." But at least they figured that part out on their own.

    After some more questions, the customer explained that removing the policy restored the user's custom picture to the Start menu, but it nevertheless did not appear on the logon screen. (Thereby illustrating the problem of vague antecedents. When they wrote "that did not solve the problem", they weren't clear what the problem was. It turns out that they meant "that only solved part of the problem": The user picture appears on the Start menu, but not on the logon screen.)

    After additional rounds of troubleshooting, the customer eventually revealed that they had also set the policy Do not display last logged on user name. Um, if you disable showing the name of the last logged-on user, then the picture of the user doesn't appear either. (Maybe they took too literal a reading of the policy, expecting it to hide the name but not the picture? What would be the purpose of that? Exercise: Why isn't the policy called the more accurate Do not display information about last logged on user?)

  • The Old New Thing

    If you return from the main thread, does the process exit?


    If instead of calling ExitProcess you merely return from the main thread of a process, does the process terminate?

    No, but maybe yes.

    This is another one of the places where the C runtime behaves differently from raw Win32.

    Under raw Win32, a process exits when any thread chooses to exit the process explicitly (usually by calling ExitProcess) or when all threads have exited. Exiting the main thread will not result in the process exiting if there are any other threads still active. According to the old-fashioned model of how processes exit, a process was in control of all its threads and could mediate the shutdown of those threads, thereby controlling the shutdown of the process. (Of course, nowadays, with the thread pool, COM worker threads, and other threads doing random background work, the idea of being in control of all the threads in the process is now just a reminder of those simpler days.)

    On the other hand, the C runtime library automatically calls ExitProcess when you exit the main thread, regardless of whether there are any worker threads still active. This behavior for console programs is mandated by the C language, which says that ( "a return from the initial call to the main function is equivalent to calling the exit function with the value returned by the main function as its argument." The C++ language has an equivalent requirement (3.6.1). Presumably, the C runtime folks carried this behavior to WinMain for consistency.

    This also means that if you decide to exit your main thread by calling ExitThread directly, then you aren't returning from the main function. Instead, you've leapt into the Win32 world where the process will not exit until all threads are gone.

  • The Old New Thing

    How do I recover the window handle passed to ShellExecute?


    A customer had the following question:

    I'm using the ShellExecute function to launch a new process and am passing the handle to my application's main window as the hwnd parameter. From the new process, I want to get information from the old process, and to do that, I need the window handle. How can I recover that window handle from the new process?

    You can't.

    That window handle is used by the ShellExecute function only to host any user interface operations that occur as a result of the attempt to execute the program. For example, it is the owner window used for any error dialogs. The ShellExecute function does not pass the window handle to the launched process. (It couldn't even if it wanted to: There is nowhere to pass it. There is no window handle among the parameters to CreateProcess nor is there a window handle in the STARTUPINFO structure.)

    If you want to pass this information to the process being launched, you'll have to come up with your own mechanism for transferring this information. For example, you can pass it on the command line, or if you have a lot of information to pass, you can use a shared memory block.

  • The Old New Thing

    What young children do when they hear a foreign language


    My young nieces live in a Chinese-speaking household, which is great for them because it means that when they grow up, they will be fluent in two languages. But it makes things a bit tricky at the beginning.

    The niece who is the subject of this story had just turned two at the time this story takes place, so her language skills even in Chinese are pretty rudimentary. Her language skills in English are restricted to a collection of set phrases like Excuse me!, I'm sorry!, What'you doing?, I want ice cream!, and any catch phrase from the character Dora the Explorer.

    (I'm also fairly sure she doesn't know what What'you doing? actually means. She'll come into a room and say, What'you doing? and then appear completely uninterested in the answer. I think she believes it to be a form of greeting and not an actual question.)

    She also loves to answer the phone, and this usually isn't a problem since most callers are relatives who can speak Chinese. But occasionally, it'll be somebody who speaks only English. (In general, these are just telemarketers, since most members of the household use their mobile phones as their main number.)

    Sometimes she'll run to the phone, pick it up, say "喂" (Hello), listen for a few seconds, and then just hang up.

    — Who was that on the phone? we'll ask.

    "人" is her one-word reply.

    It's hard to explain why this is a funny answer.

    The word 人 means man, person, so her response was a casual "A person." The offhand way she says it expresses her attitude that "The purpose of the telephone is to amuse me, but this was just some guy who provided no entertainment at all."

    The 人 phase lasted for only a month or so. In the next phase, she still picked up the phone and hung up when there was somebody speaking English on the other end, but when we asked her who it was, she gave a more detailed reply:

    "有人說ABC", which translates roughly as "It's some guy speaking A-B-C." ("A-B-C" being her word for the English language.)

  • The Old New Thing

    Why did the Explore option disappear from the context menu of folders in the second column of the Start menu?


    A customer noticed that when you right-click on Computer in the second column of the Start menu on Windows Vista, the first two options are Open and Explore. On the other hand, in Windows 7, the Explore option is gone, leaving just Open. The customer also noticed that in Windows Vista, the two commands had the same effect and wondered if Explore was removed because it was redundant.

    The response from the product team was a very simple "Yes."

    It's interesting when a customer notices a relatively insignificant UI change, figures out the likely reason for the change, and then asks for confirmation. It's not like the reason for the change affects anything. My guess is that the customer already paid for a support contract so they're just going to use it, even when the issue wouldn't normally be worth raising a support incident over.

  • The Old New Thing

    Windows 95: It sucks less


    Today marks the 15th anniversary of the public release of Windows 95.

    During the development of Windows 95, one of the team members attended a Mac conference. And not as a secret agent, either. He proudly wore a Windows 95 team T-shirt as he strolled among the booths.

    The rest of us back at the mother ship wished him well and started discussing how we could get access to his dental records so we could identify his remains when they were sent back to us from the conference.

    When he returned, we didn't kill a calf in his honor, but we did marvel at his survival skills and asked him how it went.

    I got a lot of funny looks. And one guy, upon confirming that I really did work on the Windows 95 project, said to me, "I have to commend you guys on Windows 95 so far. It sucks less."

    That backwards compliment tickled the team's funny bone, and it quickly became the unofficial team motto: Windows 95: It sucks less.

  • The Old New Thing

    Be careful that your splash screen doesn't squander the foreground love


    Commenter Erbi has a program which creates a splash screen on a background thread while the main thread initializes. "I create and then destroy this splash screen window just before creating and displaying the main window." The problem is that the main window fails to obtain foreground activation. Commenting out the code that creates the splash screen fixes the problem, but then there isn't a splash screen any more (obviously). "Is there an explanation for this behavior?"

    This behavior is explained by two earlier blog posts, plus a PDC talk. The first blog post came out years before this question was asked: The correct order for disabling and enabling windows. Destroying a window is a rather extreme case of disabling it, but the effect is the same. When you destroy the splash screen, foreground activation needs to move to some other window, and since your main window isn't around to inherit it, foreground activation leaves your program. When the main window appears, it's too late.

    The PDC talk came next, followed shortly thereafter by a blog post version of the same talk. As marketing folks like to remind you, "You get only one chance to make a first impression." Similarly, you get only one chance to use your foreground activation permission, and you decided to blow it on a splash screen. That's fine as far as it goes, but if you want to transfer that permission to another window, you have to manage it yourself. The recommended way is to establish an owner/owned relationship between them; that's the case that the "disabling and enabling windows" article focuses on.

Page 1 of 3 (29 items) 123