Tips/Support

  • The Old New Thing

    How do I configure the timeout used by UI0Detect (Interactive Services Detection service)?

    • 10 Comments

    Windows Vista introduced Session 0 Isolation which enforces the rule that services should not display UI. If a service tries to display UI, another service known as the Interactive Services Detection service detects this situation and signals the user that a service wants to display UI and gives the user an opportunity to switch to the service desktop, respond to the UI, and then switch back. If the user ignores the service for about one minute, it switches back automatically, on the assumption that something went bad with the detection and the service is actually finished with its UI. (That way, the user doesn't get stuck staring at session 0 forever.)

    More than one customer wanted to know how to configure this one minute timeout.

    The correct solution to the problem is not to configure Interactive Services Detection but rather to fix your service so it doesn't show UI in session 0.

    It's like saying, "When I mail a letter and get the postal code wrong, the letter reaches the destination eventually, but it takes much longer than a letter sent with the correct postal code. How can I get letters sent with the incorrect postal code to reach their destination faster?"

    The answer is to stop putting the incorrect postal code on your letters.

    In other words, stop throwing garbage on the sidewalk.

    Bonus reading: Troubleshooting Interactive Services Detection.

  • The Old New Thing

    Why don't all of my documents show up when I arrange my Documents library by Name?

    • 29 Comments

    A customer reported that when they opened their Documents library on Windows 7, some files were missing if they selected Arrange by: Name or Arrange by: Author or in fact any arrangement other than Arrange by: Folder. What's going on?

    When you arrange the Documents library by anything other than Folder, the Documents library uses the content indexer to obtain results quickly, rather than kicking off a recursive disk search (ugh). (The Folder arrangement does not require a recursive search, so it can use the traditional Find­First­File/Find­Next­File loop to get the results.

    A member of the search indexer team suggested that a common cause for items being missing from the index is if they have the FILE_ATTRIBUTE_TEMPORARY attribute set. The indexer ignores temporary files because the creator of the file said, "Don't worry about me, this is just a temporary file that I will be deleting as soon as I close the handle." No point indexing a file that is going to be deleted soon.

    You can check whether the file has the Temporary attribute by viewing its Properties and going to the Details tab. If the file is marked Temporary, the Attributes will include the letter T. (Note that the attrib program does not report the Temporary flag.)

    Sure enough, the customer found that the files which were mysteriously missing from the view were all marked as Temporary files. This allowed the customer to proceed to the next step of the investigation, which is figuring out why those files were being marked Temporary in the first place.

  • The Old New Thing

    Wait, so does moving a file recalculate inherited permissions or doesn't it?

    • 15 Comments

    A customer had a question about whether moving a file recalculated inherited permissions. They found that on their Windows Server 2008 R2 machine, if they moved a file between directories with different inheritable ACEs, then the security descriptor is recalculated to match the destination folder, if they perform the move from the machine itself. The same thing happens if they go to a machine running Windows 7, However, if they repeat the experiment from a machine running Windows XP or Windows Server 2003, then the security descriptor is preserved across the move.

    The customer is confused. Why does the behavior change based on the version of Windows running on the client, even though the files themselves are kept on the same server?

    The explanation is given in a few places:

    Even with these explanations, the customer remained confused.

    "Why does the permission depend on the operating system running on the client? The files are on the server, so regardless of the client operating system, it should be following the rules which apply to the server, right?"

    There are two different operations here.

    Suppose I told you, "When you buy clothes from the store, it will have the store sticker on it. You must remove the sticker yourself, and you should also wash the clothes before wearing it the first time, because the store puts powder in the bag to keep the clothes from getting moldy."

    You then say, "That is not true. When I go to my closet to get clothes I recently bought from the store, the store stickers are already gone, and there is no powder."

    That's because you live with your parents, and your mother takes your clothes, removes the stickers, washes the clothes, and then hangs them up in your closet.

    The underlying file system "move" operation preserves the ACLs from the source.

    On the other hand, if you use Explorer to move the files, then you are not using the underlying file system "move" operation directly. Your mother is moving the files. And when mother Explorer moves the files, she also edits the ACLs based on the nature of the source and destination folders, as described in the aforementioned Knowledge Base articles. Furthermore, different versions of mother Explorer edit the ACLs in different ways.

    That is why the behavior is dependent upon the client operating system. When you move the file from a client machine connected to the server, the client machine asks the server to move the files (which preserve the ACLs since that's what the low-level "move" operation does), and then the client machine goes back in and edits the ACLs in a client-specific way.

    It is therefore the client operating system which controls how the ACL editing is performed, because it is the client operating system which is editing the ACLs.

  • The Old New Thing

    How permanent is the "Remove from this list" action on the Start menu?

    • 22 Comments

    From Windows XP to Windows 7, the Start menu showed the programs it thinks you've run most frequently, by employing a conceptually simple but complicated-in-practice algorithm. You can right-click an item on the menu and select Remove from this list. What exactly does this option do? Does it reset the points back to zero, or does it ban the program from the Start menu for all eternity, or something in between?

    It resets the points back to zero and marks the program as has never been run by the user.

    This causes it to vanish from the frequently-used list, but if you start running it, it will start earning points again, and if you keep running it enough, it will claw its way back onto your frequently-used list.

    If you want to ban a program, you can mark it as No­Start­Page.

  • The Old New Thing

    How can I find out which process and user is modifying a file?

    • 26 Comments

    When troubleshooting a problem, you may discover that a file is being modified that shouldn't, and you figure out would be nice if there were some way of finding out which process is modifying the file (so you can get it to stop).

    Enter the security auditing system.

    Every securable object has an associated system access control list (SACL) which controls what audit events are raised when a request is made to access the object. You can say, for example, "Log an event in the security event log if somebody tries to open this file for writing but is denied access," or "Log an event in the security event log if somebody successfully creates a new file in this directory."

    Here's how it works. Let's say that you want to access successful requests from any user to write to a particular file.

    View the Properties of the file, go to the Security tab, and click Advanced, then go to the Auditing tab and elevate to administrator if necessary.

    Next, click Add. What happens next depends on what version of Windows you're using, since the interface varies slightly (but the basic idea remains the same). When asked for the security principal, set the Location to the local computer and use the object name Everyone.

    Older vesions of Windows will give you a grid of options. Look for the row corresponding to the operation you want to audit and check the box under Successful if you want to audit successful accesses or the box under Failed to audit failed accesses. (Or check both to audit both successful and failed accesses.) Repeat for each access you want to audit. In our case, we would check the Create files / write data and Create folders / append data boxes under the Successful column.

    Newer versions of Windows break the grid up into two questions. The first is whether you want to audit Success, Fail, or All access. In our case, we want to audit Success. The next question is what type of access you want to audit, and in our case we would check Write. (Or for finer control, click Show advanced permissions and check Create files / write data and Create folders / append data.)

    OK your way out of all the dialog boxes to save the changes.

    All right, let's take this thing out for a spin. Open the file in Notepad, make some change, and then Save them. Now open the Event Viewer and go to the Security event log.

    And... no log entry.

    That's because I forgot a step: You have to enable object access auditing.

    Open the Control Panel and look in the Administrative Tools folder. From there, you can run the Local Security Policy snap-in. If you are a command line nerd, you can run secpol.msc.

    Under Local Policies, Audit Policy set the Audit object access policy to enable global auditing of successful or failed accesses, depending on what you need.

    Okay, let's try it again. Modify the file and save it. Now go back to the security event viewer and you'll see audit success events in your log. Again, depending on what version of Windows you're using, the successful audit event will appear differently. For example, older versions of Windows might show

    Event Type: Success Audit
    Event Source: Security
    Event Category: Object Access
    Event ID: 567
    Date: ...
    Time: ...
    User: ...
    Computer: ...
    Description:
    Object Access Attempt:
    Object Server: Security
    Handle ID: 208
    Object Type: File
    Process ID: 1964
    Image File Name: C:\WINDOWS\system32\notepad.exe
    Access Mask: WriteData (or AddFile)
    AppendData (or AddSubdirectory or CreatePipeInstance)

    whereas newer versions might show

    Keywords: Audit Success
    Date and Time: ...
    Source: Microsoft Windows security auditing
    Event ID: 4663
    Task Category: File System
    An attempt was made to access an object.
    Subject:
    Security ID: computer\user
    Account Name: user
    Account Domain: computer
    Logon ID: 0x27ADB
    Object:
    Object Server: Security
    Object Type Name: File
    Object Name: C:\test.txt
    Handle ID: 0x15c
    Resource Attributes: S:AI
    Process Information:
    Process ID: 0xdb0
    Process Name: C:\Windows\System32\notepad.exe
    Access Request Information:
    Accesses: WriteData (or AddFile)
    AppendData (or AddSubdirectory or CreatePipeInstance)
    Access Mask: 0x6

    Either way, you can see which process obtained write access to the file, running as what user, at what time.

    Newer versions of Windows include a bit more information in the event log entry to make it easier to find the access request you're looking for as well as chase the access further. (For example, from the Logon ID, you can figure out which logon session modified the file.)

    This feature has been around since the beginning of Windows NT, but it seems that very few people know about it. Whenver I point it out to people, they say, "Hey, that's cool. How long has that feature been there?"

    Now you too can look smart.

  • The Old New Thing

    Why doesn't the "Automatically move pointer to the default button in a dialog box" work for nonstandard dialog boxes, and how do I add it to my own nonstandard dialog boxes?

    • 30 Comments

    The Mouse control panel has a setting called Automatically move pointer to the default button in a dialog box, known informally as Snap to default button or simply Snap To. You may have discovered that it doesn't work for all dialog boxes. Why not?

    The Snap To feature is implemented by the dialog manager. When the window is shown and the setting is enabled, it will center the pointer on the default button. If your application does not use the dialog manager but instead creates its own custom dialog-like windows, then naturally the code in the standard dialog manager will not run.

    If you want your nonstandard dialog box to support the Snap To feature, you get to implement it yourself.

    Here's a Little Program that creates a window with a default pushbutton inside it, and which centers the mouse on the button when the window is shown. Start with our scratch program and make these changes:

    POINT GetRectCenter(LPCRECT prc)
    {
      POINT pt = {
        prc->left + (prc->right - prc->left) / 2,
        prc->top + (prc->bottom - prc->top) / 2
      };
      return pt;
    }
    

    The Get­Rect­Center helper function calculates center of a rectangle.

    BOOL OnCreate(HWND hwnd, LPCREATESTRUCT lpcs)
    {
      CreateWindow(TEXT("button"),
                   TEXT("Button 1"),
                   WS_CHILD | WS_VISIBLE | BS_DEFPUSHBUTTON,
                   0, 0, 200, 50,
                   hwnd,
                   (HMENU)1,
                   g_hinst,
                   0);
      return TRUE;
    }
    

    When our main window is created, we put a default button inside it.

    #define WM_CHECKSNAPDEFBUTTON WM_APP
    
    void OnShowWindow(HWND hwnd, BOOL fShow, UINT status)
    {
      if (fShow && status == 0)
      {
        PostMessage(hwnd, WM_CHECKSNAPDEFBUTTON, 0, 0);
      }
    }
    
    void OnCheckSnapDefButton(HWND hwnd)
    {
      BOOL fSnapToDefButton;
      if (SystemParametersInfo(SPI_GETSNAPTODEFBUTTON, 0,
                               &fSnapToDefButton, 0) &&
                               fSnapToDefButton &&
                               hwnd == GetForegroundWindow())
      {
        RECT rcButton;
        GetWindowRect(GetDlgItem(hwnd, 1), &rcButton);
        POINT ptCenter = GetRectCenter(&rcButton);
        SetCursorPos(ptCenter.x, ptCenter.y);
      }
    }
    

    When the window is shown, we post a message to check the Snap To setting after things have settled down. Once things settle down, we check the Snap To setting, and if it's enabled, and if our window is still the foreground window, then we center the cursor on our button.

    It's important to check that our window is still the foreground window, because it would be rude to move the cursor to our button even if we opened in the background.

    That's why we need to post a message to perform the check later. The WM_SHOW­WINDOW message is sent early in the Show­Window calculations, before the activation actually changes. If we performed the check then, the answer would always be, "No, you're not the foreground window," and we would always back off.

    Naturally, we need to hook up our new messages.

      HANDLE_MSG(hwnd, WM_SHOWWINDOW, OnShowWindow);
      case WM_CHECKSNAPDEFBUTTON: OnCheckSnapDefButton(hwnd); break;
    

    And there you have it, a program that honors the Automatically move pointer to the default button in a dialog box setting in its custom nonstandard dialog.

    Exercise: What assumptions are made about the rectangle by the Get­Rect­Center function? How do they differ from the assumptions made by this alternate version:

    POINT GetRectCenter(LPCRECT prc)
    {
      POINT pt = {
        (prc->left + prc->right) / 2,
        (prc->top + prc->bottom) / 2
      };
      return pt;
    }
    
  • The Old New Thing

    Adding a confirmation dialog to every drag/drop operation does not solve the problem

    • 42 Comments

    A customer wanted to know how to enable a confirmation dialog whenever the user inadvertently perform a drag/drop operation in Explorer to move files within a volume.

    For example, if I have an S drive mapped to \\server\share, I would like to display the confirmation dialog when users inadvertently drag and drop a file or folder within the S drive.

    Okay, first of all, the problem statement doesn't match the question. But that's good, because the question was misguided.

    The question was "How do I add a confirmation dialog to every drag/drop operation?" But the problem statement was "We have users who inadvertently drag and drop files."

    So they didn't actually want the confirmation on every operation; they only wanted it on the accidental ones.

    Of course, the computer can't read your mind, so it doesn't know what you were thinking when you performed a drag/drop operation in order to determine whether the operation was intentional or accidental. The customer asked for a dialog box to appear after every operation just in case it was inadvertent. But since most actions are intentional, the result is that users get confirmation dialog after confirmation dialog. Soon, dialog fatigue sets in, and users just get into the habit of ignoring them.

    But let's go back to that inadvertent adjective. The way to reduce the likelihood of accidental drag/drop operations is to adjust the drag sensitivity so that the mouse must move a "significant" distance before a drag/drop operation is initiated. What constitites a "significant" distance is something you can choose based on your own experiments.

  • The Old New Thing

    Why does Explorer sometimes show my server name in parentheses?

    • 27 Comments

    A customer wanted to know why Explorer showed one of their servers in the folder list the normal way:

    ⊞ servername

    but another server showed up "where the server name is parentheses and the node name is in front."

    ⊞ nodename (servername)

    "Where is Explorer getting that information, and why are the two servers showing up in different ways?"

    It's all in the server comment.

    From the command line, you can view the server comment by typing net view \\servername. For example,

    Shared resources at \\servername
    
    Printer server next to the third floor bathroom
    
    Share name  Type  Used as  Comment
    
    ----------------------------------
    ...
    

    You can set the comment with the command line

    net config server /srvcomment:"Printer server next to the third floor bathroom"
    

    If a server has a comment, then the comment is shown to the user on the expectation that the comment is something that is more meaningful to the user than some cryptic server name. Microsoft's own server names are hyper-cryptic, like TK5EX14MBXW603. Of course if you talk to a support technician, they'll tell you that the name is clear as day. "The TK means that the server is physically in our Tukwila data center. The 5 means that..." (I never manage to stay awake long enough to learn what the 5 stands for.)

    I guess this created more confusion than clarification, because the comment-name-followed-by-parenthesized-server-name convention appears no longer to be in use starting in Windows Vista.

    Communications breakdown: When we provided this information back to the customer, the customer liaison simply replied back, "Thanks, we figured that out on our own."

    That was not a very clear reply. Is the customer liaison saying, "That's the information we were looking for, thanks. We managed to figure that out on our own in the meantime." Or maybe the customer liaison was trying to say "Thanks for the information, but we already knew that. We were looking for something else."

    I asked the customer liaison whether they needed any more information from us, and there was no reply. I guess that's passive-aggressive way of saying, "No."

  • The Old New Thing

    Windows 7 no longer tries to guess application size and other information

    • 34 Comments

    Back in the old days, if an application did not provide information like its Estimated Size or Install Date, then the Add/Remove Programs control panel tried to guess the values by searching your hard drives for files and directories that bore a superficial resemblance to the application. (Note that I use the word drives in the plural. It actually searched all of your drives, because some applications may have been installed to secondary drives. I can imagine the bug report that led to this extended search. "I installed LitWare 2000 to my D: drive, and the Add/Remove Programs control panel shows no information for it. You should have found it on my D: drive, because (like many power users) I install all my applications to my D drive to maintain free space on my C drive.")

    Time passed, and the name of the Add/Remove Programs control panel changed several times. It became Add or Remove Programs in Windows XP, changing the slash to the word or. In Windows Vista, its name changed to Programs and Features, but at least the name has been stable since then.

    In Windows 7, the "search your hard drive looking for the application" fallback algorithm was removed. If an application did not provide information such as its estimated size or install location, then Windows now just says, "Well, tough on you." My guess is that the search was removed because the vast majority of applications now provide the information directly, so the extra cost of trying to hunt it down for the last few application was not worth the benefit.

    There is still one tiny thing that Windows will guess: The installation date. But it doesn't have go hunting through your hard drive to guess that. It merely infers it from the last-modified date on the uninstall metadata itself!

  • The Old New Thing

    Why don't hotkeys for items on my Start menu work when I am in a fullscreen application?

    • 38 Comments

    You can set a hotkey on the shortcuts in your Start menu, and Explorer will launch that shortcut when you press the hotkey, but not if you are in a fullscreen application, like when you set Paint into fullscreen mode, or when you are displaying a PowerPoint presentation. Why are shortcut hotkeys ignored when a fullscreen application is running?

    This feature was added by customer request.

    The issue is that you're playing a game like World of Warcraft or Unreal Tournament, and you're mashing your keys like crazy, and whoops you slip and hit Ctrl+Alt+C instead of Ctrl+Shift+C, and now you inadvertently launched Calc or something. Whack, you get taken out of your game into Calc, and by the time you get back into the game, your character has been mortally wounded, and you've lost the game.

    To prevent this from happening, Explorer temporarily ignores custom hotkeys for Start menu shortcuts when a fullscreen application is running.

    Note, however, that there is a bug in older versions of Windows: If you press a hotkey for a Start menu shortcut when there is a fullscreen application running, the hotkey is blocked. (So far so good.) But even if you clear the fullscreen application, the hotkey is still blocked because the hotkey got "stuck" in the blocked state. To unstick the hotkey, press a system hotkey involving the Windows key, then try the original hotkey again. (I use Win+B since it is relatively harmless.)

Page 2 of 24 (233 items) 12345»