Tips/Support

A customer asked, "Does NTFS support files with a null string as the name?"

No, NTFS does not support files with no name. None of the commonly-used Windows file systems do. Files must have a name. But what a strange question that is. The customer was kind enough to explain why they cared.

"We have a zip file that the Compressed Folders (Zip folders) feature that comes with Windows cannot deal with. When we try to extract the contents of the zip file, we get the error message 'Windows has blocked access to these files to help protect your computer.' We've attached a copy of the file."

The Compressed Folders functionality in Explorer has many known limitations, such as lack of support for ZIP64 and AES encryption. Neither of those applied to the zip file in question, however.

The customer explained what they did. "We created the zip file with a third party zip tool. In particular, after adding a directory tree to the zip file, we renamed the root of the tree to have a blank name. In the zip file we sent you, we added A/file.txt, and then we used the zip tool to rename 'A' to the empty string."

And indeed if you looked at the zip file in a hex editor, the file name was "/file.txt".

Now the pieces fell into place. The Compressed Folders code was blocking the file because it was attempting to perform a directory traversal; specifically, it was trying to drop a file in the root directory. The ZIP Application Note says that the "file name" field consists of "The name of the file, with optional relative path." Note that the path must be relative. The next sentence emphasizes this point: "The path stored should not contain a drive or device letter, or leading slash." Therefore, the zip file is invalid, and the Compressed Folders code is within its rights to reject it. (And one wonders why the zip tool allowed the user to create an invalid zip file.)

It's unclear what the customer was trying to do by renaming "A" to the empty string. So the recommendation back to the customer was "Don't do that."

A customer liaison asked why their customer's Windows 7 machines could run Magnifier only in Docked mode. Full Screen and Lens mode were disabled. The customer liaison was unable to reproduce the problem on a physical machine, but was able to reproduce it in a virtual machine.

Full Screen and Lens mode require that desktop composition be enabled. Windows will enable desktop composition by default if it thinks your video card is capable of handling it. (Finding the minimum hardware requirements for desktop composition is left as an exercise.)

This was visible in the screen shots provided by the customer liaison. In the screen shot where Full Screen and Lens modes were enabled, the Aero theme was being used, whereas in the screen shot where they were disabled, the theme was Windows 7 Basic. The Windows 7 Basic theme is used when desktop composition is disabled.

A quick way to check whether desktop composition is enabled is to hit Alt+Tab and see whether windows get the Aero Peek effect when you select them. Aero Peek is a feature that is provided by the desktop compositor.

A customer asked if there was a command-line tool for managing Windows 7 Libraries so that they could create and deploy libraries across their organization.

Not only is there such a tool, it even comes with source code.

The Shell Library Command Line Sample shows how to manage Windows 7 libraries programmatically via the IShell­Library interface. And it's actually a useful program on its own.

Usage: shlib.exe SUBCOMMAND

Displays and modifies the attributes of Shell Libraries.

Supported commands:
  create      Creates a library at the specified path.
  info        Prints info about the given library.
  enum        Enumerates the folders in the library.
  setattrib   Modifies the attributes of the library.
  add         Adds the specified folder to the specified library.
  remove      Removes the specified folder from the library.
  setsaveloc  Sets the default save location of the library.
  resolve     Resolves the specified folder in the library.
  resolveall  Resolves all locations in the library in bulk.
  manage      Displays the Manage Library Dialog for the library.

For example, to see all the folders that are part of your Documents library, use the command

shlib enum FOLDERID_DocumentsLibrary

Each of the commands has further sub-options.

Usage: create shlib.exe [OPTIONS]  [...]

Creates a library at the specified path.

Options:
 -create[:ARG]       Specifies that a new library should be created.
   <none>              Fail if the library already exists.
   overwrite           Overwrite any existing library.
   uniquename          Generate a unique name in case of conflict.

The library may be specified by a file system path,
or by a KNOWNFOLDERID (e.g. "FOLDERID_DocumentsLibrary").

And the source code shows how to perform each of these actions programmatically.

The IShellLibrary interface is also supported by the Windows API Code Pack for .NET, so you C# folks can use it too.

(One thing I noticed that is missing from the sample is a seticon command. Shouldn't be hard to implement. You just call IShell­Library::Set­Icon.)

Some jump lists show Recent documents, and others show Frequent documents.

(Images stolen from Sasha Goldshtein.)

Our friend xpclient wanted to know how the taskbar decides which one to use, because it seemed random. (Ironically, xpclient is asking a question about the Window 7 client.)

The default is to show Recent documents. But an application can customize its jump list, and in that case, the application can select which category to show based on the guidance in the documentation. (Or the application might choose to ignore the guidance in the documentation and show both.)

Okay, but what about Explorer itself? You can find that Explorer will sometimes show Frequent locations (e.g., on My Computer) and sometimes Recent locations (e.g., on Control Panel). How is this possible if the decision is made on per-application basis?

Because the taskbar uses the shell application user model to associate windows with applications. We've taken advantage of this model a number of times before, like when we prevented a program from being pinned, or made one application look like two or many. Explorer sets its jump lists to show Frequent, but if an Explorer window sets a custom application ID, then that window is treated by the taskbar as a separate program and therefore the Explorer default does not apply (and it gets Recent instead).

To make things even more complicated, xpclient was running a third-party taskbar hacking application which manipulated application ID of windows which belong to other applications. And just like in real life, if you mess with stuff that isn't yours, you can cause trouble for the real owner. In this case, manipulating the application IDs broke Explorer's jump list customizations.

This is another case of somebody doing some weird customization and then complaining that their system acts all strange (which often leads to the accusation that Microsoft developers are a bunch of idiots) when the strange behavior was caused by their customization. I mean, if you're running a taskbar hacking application, then you really shouldn't be surprised if the taskbar occasionally behaves erratically.

Bonus chatter: The Recent and Frequent categories are variable-length, which you can customize by setting the Number of recent items to display in Jump Lists.

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

When I do a shift-right-click on a shortcut to a program, I see the following:

• On Windows Server 2008, shift-right-click does not offer the option Run as different user.
• On Windows 7, shift-right-click does offer the option Run as different user.

  On Windows Server 2008 R2 (the server counterpart to Windows 7), shift-right-click does offer the option Run as different user.

The option to run a program as another user (other than Administrator) was present in Windows XP, but it was lost in Windows Vista. It appears that we responded to those complaints by restoring the functionality in Windows 7.

Is that right?

The odd thing is that my customer has the Run as different user option available on their Windows 7 machines, but not on their Windows Server 2008 R2 machines. Does whether you have access to Run as different user depend on how you installed Windows Server 2008 R2? (If it matters, my customer installed it via the Microsoft Deployment Toolkit.)

I found this question interesting for a variety of reasons.

First of all, it comes dangerously close to being one of those Please tell me I'm not hallucinating type of requests. These support requests take the following peculiar form:

We did X, then Y, then Z, and then Q happened. Is that right?

"Um, if you say so. I wasn't there."

But in this case, it started out looking like it was going to turn into a Please tell me I'm not hallucinating request, then veered into "Is X the reason the feature was added back?"

This is a rather peculiar question, because knowing the answer one way or the other doesn't actually take you any closer to a solution to the problem. (And I don't know the answer, but fortunately, it wasn't relevant to solving the customer's problem.)

Another interesting thing about the customer's question is that he never actually comes out and asks the question. He sort of says a few related things, and asks a tangential question, but never comes right out and asks, "How do I get the Run as different user option to work on my Windows Server 2008 R2 machine?"

It's like a kid who pointedly hangs around a candy bowl, hoping that an adult will say, "Here, have a piece of candy."

You're a grown-up now. You don't have to linger around the candy bowl hoping somebody will figure out that you want some candy. You should just ask, "May I have a piece of candy?"

My psychic powers tell me that they have set the Require trusted path for credential entry policy. The Run as different user feature is disabled if you set this policy.

The customer liaison replied, "It appears that the option for Require trusted path for credential entry is not enabled. The customer is going to do a clean install and test on a non-domain-joined machine to avoid any GPOs."

Some time passed, and the customer liaison reported back with a resolution.

The culprit was indeed the Require trusted path for credential entry policy. It didn't show up in a GPO search because they were setting the policy via a script rather than deploying a group policy object.

It was very nice of the customer liaison to reply with confirmation that the problem was solved. This is, unfortunately, a notable event. Most of the time, people never report back if your suggestion solved their program; they only come back if your suggestion didn't help. Which means you're not sure if your suggestion solved the problem, or if it didn't solve the problem but they decided to continue the investigation somewhere else.

Bonus chatter: This shows yet another reason why you should use Group Policy Objects to manage group policies rather than custom scripts that whack registry keys. In addition to the fact that registry key whacking may not work, there are tools for processing Group Policy Objects that make this sort of investigation much easier.

Last time, we looked at the evolution of the control panel settings which control the language groups for which Windows will install fonts, code page information, and other support collateral. This was in the context of a customer who was trying to migrate from Windows 2000 to Windows XP, and the customer wanted to convert their workflow to the new operating system.

They made the appropriate changes, and... the problem was not fixed.

At this point, the customer liaison decided to tell us what the actual problem was. (I don't know whether the information was originally withheld by the customer or the customer liaison, so I intentionally phrased the situation vaguely.)

The customer's original workflow involved installing Bulgarian language support, and from your explanation it appears that Bulgarian language support is installed by default on Windows XP. But we still have the problem where if they run one of their internal programs, the text comes out incorrectly unless they also set the Language for non-Unicode programs to Bulgarian.

It took two days before the penny dropped and I figured out what the customer's actual problem was and what they were trying to do.

Even though the customer's original question was asking what happened to "selecting multiple languages from the Language settings for the system" section of the control panel, their actual question is "What happened to the Set default... button that appears below the list box?"

The Set default... button moved to the Languages for non-Unicode programs section of the control panel.

Selecting Bulgarian from the dropdown is equivalent to clicking the old Set default... button and picking Bulgarian.

Back in 2000, some wiseguy named Michael Kaplan walked through the old Windows 2000 control panel and explained what each piece means.

The customer liaison reported back that they could get their program to behave the way they wanted, but for only one language at a time. Reportedly, under Windows 2000, once they added support for Bulgarian and Slovak, they could use the program in both Bulgarian and Slovak mode. But in Windows XP, they have to pick one or the other. If they pick Bulgarian, then the Slovak mode comes out garbage, and vice versa.

The customer's application is Web-based, so the problem may be in the way the program performed language negotiation with the server. But the customer hasn't done any actual debugging; they're just running around fiddling knobs hoping that one of them will magically solve the problem.

What the customer really needs to do is start debugging: For example, they can capture a network trace of the communication between the client and the server on a Windows 2000 machine, and compare it to the trace they get on a Windows XP machine. If there are differences, that may guide the next level of investigation. (And if there aren't any differences, then the problem is strictly on the client.)

In 2011, a customer had a question about migrating from Windows 2000 to Windows XP. (That's right, this customer was still using Windows 2000 in the year 2011.) Specifically, they noted that in Windows 2000, they can select multiple languages in the "Language settings for the system" portion of the Regional Options control panel, and they couldn't find the corresponding control panel setting in Windows XP.

In Windows 2000, "Language settings for the system" provides the option to install support (such as code pages, keyboard layouts, and fonts) for various language groups. In Windows XP, the big list of language groups was reduced to three categories:

• Basic (Baltic, Central Europe, Cyrillic, Greek, Turkish, Western Europe)
• Complex (Arabic, Armenian, Georgian, Hebrew, Indic, Vietnamese, Thai)
• East Asia (Chinese Simplified, Chinese Traditional, Japanese, Korean)

The Basic category is always installed. To install the Complex or East Asia categories, use the "Supplemental language support" section of the Regional and Language Options control panel.

Someday, that customer might upgrade to Windows Vista, so I may as well answer the question right now. In Windows Vista and onward, things were simplified even more: All language groups are installed at all times. The dialog box went away completely since there were no options remaining.

As it turns out, the customer's problem had nothing to do with language support. Of course, they didn't come out and describe the problem they were having; rather, they reduced the problem into multiple pieces, and then asked for help on one specific piece. They tried out a solution based on this new information, but it didn't solve the problem, because as it turns out, the Language settings for the system control panel was a red herring. If they had told us what their original problem was, we could have told them "But this setting will do nothing to solve your problem. What you really need is over there."

Tomorrow, we'll look at the customer's actual problem. (So please don't try to guess or you'll ruin the surprise. I can't believe I had to write that.)

A customer reported that even after uninstalling thier application, the notification icon entry remains in the Notification Area Icons control panel.

Yup, that's right. Explorer remembers the icon, even after the underlying program has been uninstalled, because you might have uninstalled it with the intention of immediately reinstalling it, so Explorer remembers the icon in case it comes back. But after one week, Explorer gives up and finally forgets about the icon. "It's been a week, and the user hasn't reinstalled the application. I'm going to give up waiting for it."

The customer wanted to know how they could remove their icon immediately upon uninstall. They reported that having the icon remain in the Notification Area Icons control panel made it appear that the uninstall was unsuccessful.

There is no documented mechanism for removing the icon (and the undocumented mechanisms destroy all the icon history, not just the icon history for your icon, so don't do that either). You'll just have to wait seven days for the icon to go away.

(One possibility that was considered was to have the Notification Area Icons control panel check if the application is still installed before showing it on the list. This runs into problems, though, if the application resides on the network or removable media. It means that opening the Notification Area Icons control panel can stall on network I/O, generate security audits if you lost access to the network share, and spin up external media. Remember how much people hated it when Windows 95 spun up your CD-ROM drive the first time you clicked on the address bar?)

If you type SysFader into your favorite search engine, you'll find lots of hits from people asking, "What is SysFader, and why is it always crashing Internet Explorer?"

When a program encounters a fatal error, the system crash dialog appears. And it needs to put somebody's name in the title of the dialog to indicate which application crashed. Sure, it has the process name (iexplore.exe), but it has this nagging feeling that it can do better. After all, not everybody will know that "AcroRd32.exe" is "The menu for my favorite restaurant that I was looking at in Adobe Acrobat Reader". So it goes looking for a window that belongs to the thread so it can steal the window's title and use that to help the user understand what it was that crashed.

And if can't find any visible windows, it will go for invisible ones, on the theory that, "Well maybe the application crashed before it could show the window."

Now let's see what happens when we apply this logic to SysFader.

SysFader is a helper window used by Internet Explorer to perform fade-out animations. It really doesn't do much, but it is a window, albeit an invisible one when there are no animations in progress.

SysFader happens to run on a shared worker thread. If that worker thread is being borrowed by some other background task, and that background task crashes, then when the crash dialog appears and looks around for a window to put in the title, it says "Rats, I don't have any visible windows, but I do have this invisible one, so I'll go ahead and put that one in the title bar. Better than nothing."

It's sort of the error-reporting version of the Politician's Fallacy:

1. A window must be blamed.
2. This is a window.
3. Therefore, we must blame it.

It's like your photo appearing in a newspaper article headlined Robbery at Woodgrove Bank, Suspect At Large, not because you're the suspect, but because you happen to have been in the building at the time of the robbery.

Bonus chatter: You probably recognize the exception code as an unhandled C++ exception. Internet Explorer doesn't use C++ exceptions, so the exception most likely came from a plug-in.

[Raymond is currently away; this message was pre-recorded.]

A customer reported an issue with the title "The notification balloon for Low Disk Space does not appear even if the free disk is very low." They provided the following steps:

• Install Windows 7 64-bit on a SATA drive.
• Copy files to the system drive until disk space becomes low.
• Observe that the notification balloon for Low Disk Space does not immediately appear.
• The balloon appears approximately ten minutes later.

You read through the steps nodding, "uh huh, uh huh", and then you get to the last step and you say, "Wait a second, the subject of your report was that the balloon doesn't appear at all, and now you're saying that it appears after ten minutes. So it does appear after all. What is the problem?"

The customer explained that on earlier versions of Windows, the Low Disk Space warning balloon appeared within one minute, whereas in Windows 7 it can take up to ten minutes for the balloon to appear.

Yup, that's right.

In previous versions of Windows, Explorer checked for low disk space once a minute. The Windows performance folks requested that the shell reduce the frequency of checks to improve overall system performance, and the shell team agreed to reduce the frequency to once every ten minutes. (The performance team made other suggestions to reduce the impact of that code that runs every ten minutes.)

So yes, in Windows 7, it may take up to ten minutes for Explorer to report that you are low on disk space. But Explorer never promised that those reports would be timely. Or that they would even appear in the first place. The behavior is not contractual; it's just a courtesy notification.

Related: How full does a hard drive have to get before Explorer will start getting concerned? and How do I disable the low disk space notifications?