Silver's Simple Site - Weblog - Tags - Windows

So I was bored, and reading Faux's weblog archive, and found this one on mouseless use.

That got me thinking - just how many shortcuts does Windows have, that most people don't know? I'd wager it's more than you think.

The most well-known set are <Win> plus a letter. So here's the list for Windows XP Professional x64:

• <Win> - Start menu
• <Win>+B - Focus Shell Notification Area
• <Win>+D - Show Desktop (toggle)
• <Win>+E - Open Explorer
• <Win>+F - Open Find for Files
• <Win>+<Control>+F - Open Find for Computers
• <Win>+L - Lock Workstation
• <Win>+M - Minimise all windows (<Win>+<Shift>+M to undo)
• <Win>+R - Run dialog
• <Win>+U - Run Utility Manager (accessibility stuff lies this way)

<Win>+B took me by surprise, so I figure not everyone knows all of the above list, however common some of them are.

The others, people only seem to know a few, and I suspect there will be at least one new one here for everyone.

• <Win>+F1 - Open Help and Support Center
• <Win>+<Break> - System Properties
• <Win>+<Tab> - Focus and select taskbar programs (try this - you'll like it)
• <Control>+D - Delete in Explorer
• <Control>+<Esc> - Start menu for luser keyboards
• <Control>+<Shift>+<Esc> - Task Manager
• <Shift>+<Menu> - Extra context items (like Run As and Open With)
• <Shift>+F10 - Context menu (<Shift>+<Menu> for luser keyboards)
• <Shift>+[No] on Explorer dialogs - No to all

Those are all the ones I can remember and/or find right now. I am certain that there are more, but they will have to be documented another day.

The reason for all this was because Faux's description of using <Win>+D then <Tab> to get to the start menu button seemed excessive, and has the side-effect of minimising all running programs. <Win>, <Esc> is much easier to focus the button, but for what he's suggesting, you just need to hit <Win> and use the arrow keys. Or, if you want to play with your open applications, <Win>, <Esc> then <Tab> to the taskbar, though I prefer <Win>+<Tab> to do that directly.

Now if only my weblog had a shortcut for [Post]...

Fast User Switching, the Welcome Screen and <Control>+<Alt>+<Delete>

First of all, let's start with a brief explanation of Windows' multi-layered sand-boxing and separation of logins and the user's desktop.

The basic structure is thus:

• Windows kernel and Object Manager
• "Sessions"
• Window Stations
• Desktops
• Your desktop 'n' stuff.

I.e. the kernel can maintain any number of "sessions", all of which can have any number of window stations, all of which can have any number of desktops, all of which can have, well, the windows themselves.

Certain things are sand-boxed at different levels. Named kernel objects (e.g. events, critical sections, etc.) are stored in a session-specific location. Atoms and the clipboard, for example, are part of the Window Station, where as hooks are part of the Desktop. You can only send messages between processes with the same desktop, too.

All the sessions use the same setup:

• WinSta0 (Window Station)
  • Winlogon (Desktop) AKA "secure desktop"
  • Default (Desktop)

The login screen, locked dialog and <Control>+<Alt>+<Delete> dialog all run in WinSta0\Winlogon. All your applications run in WinSta0\Default.

It should be noted that applications can create their own Window Stations and Desktops; indeed, my main system currently has 5 extra Window Stations (created by services, like Task Scheduler).

Windows NT and 2000

With Windows NT and 2000, things were simple. Session 0 was the one and only local "interactive" session (the one attached to the physical display device, physical input devices, etc.). Remote Desktop created other sessions for each remote login, as you might expect.

Windows XP

With Windows XP, two things were done to make life easier for the home user - Fast User Switching, and the Welcome Screen.

As you might have guessed, Fast User Switching utilises the "sessions" layer, allowing completely isolated user sessions. Adding this local disconnect/connection required enough work on the session system for an entire book, but it's not relevant here - what is, though, is that any session may be connected to the local physical devices.

Now that the system can do this magic, a UI is needed. Enter the Welcome Screen. The Welcome Screen (logonui.exe) runs in the secure desktop (WinSta0\Winlogon) when necessary, such as when a user logs off or locks the computer. It is interesting to note that the actual process is started by these events and does not run all the time.

• Initial system
  • Active desktop: \Sessions\0\WinSta0\Winlogon
  • Welcome Screen running. No user's logged in.
• Initial login
  • Active desktop: \Sessions\0\WinSta0\Default
  • No secure desktop processes.

At this point, I will point out that Start > Log off > Switch Users does exactly the same thing as <Win>+L (Lock).

• Locking initial login
  • Active desktop: \Sessions\0\WinSta0\Winlogon
  • Welcome Screen running. One user logged in.
• Second login
  • Active desktop: \Sessions\1\WinSta0\Default
  • Welcome Screen creates new session and connects local system to it. No secure desktop processes afterwards.
• Locking second login
  • Active desktop: \Sessions\1\WinSta0\Winlogon
  • Welcome Screen running. Two users logged in.

This is where things get more interesting. The Welcome Screen can unlock either session, but is currently still connected to the second login. This has a bearing on, for example, sound - which is still connected, so your music will keep playing when you lock the computer (as it always has done). If you unlock the initial login, however, it will be disconnected.

• Unlock initial login
  • Active desktop: \Sessions\0\WinSta0\Default
  • Welcome Screen connects to session 0, and unlocks. No secure desktop processes afterwards.

Just for fun, you can also disconnect the local session (from Task Manager, f.e.), which starts a new session just for the Welcome Screen:

• Disconnect local session
  • Active desktop: \Sessions\2\WinSta0\Winlogon
  • Welcome Screen running. Two users logged in.

There are two UI points that change other than the login screen:

• Security (<Control>+<Alt>+<Delete>) dialog.
• Locked Workstation dialog.

Most people will see that the Locked Workstation dialog is counter-productive when Fast User Switching is enabled, and thus you get the Welcome Screen instead of it.

The Security dialog is a slightly different story. Winlogon uses GINA modules show various login UI. This includes all the classic login dialogs, the locked workstation dialog and the security dialog. The GINA module can be replaced with a 3rd-party one, such as NetWare's login screens and there is no telling what a 3rd-party security dialog might do. This means that the <Control>+<Alt>+<Delete> behaviour must still exist for non-local situations, and it makes sense (for consistency) to keep showing it when you also have the classic login UI.

In other words, although being in a domain or other network environment does mean sacrificing the Welcome Screen, there is no hard and fast reason for not having the <Control>+<Alt>+<Delete> dialog when using the Welcome Screen. It's just nicer not too. ;-)

Windows Vista

With Windows Vista, things change again. GINA modules are gone, presumably replaced with something else. This is what allows it to present the Welcome Screen for domain setups, and a pretty version of the classic security dialog has been added too. Nice one.

Disclaimer: all reasons behind design decisions, why X does Y, etc. are all based on 2nd-hand data, debugging and intelligent guesswork. I make no claims to them being strictly accurate.

I was recently reading a weblog post on Linux and measuring memory used by individual applications, and it reminded me just how complex most OSes' memory management really is. Just when you think you've got it, another spanner hits you on the shin. So, let's have a look at Windows' memory management:

1. Non-paged pool
2. Paged pool
3. Driver code
4. Kernel code
5. System cache
6. Applications
7. "Available"

All physical memory (available to the OS - we're ignoring anything that the BIOS is owning here) is used by one of the 7 categories above. Applications and "available" are the most interesting ones, and there is a reason I'm quoting "available", which I'll come to later.

Items 1-5 are all kernel memory, and the remaining two user memory.

1 Non-paged pool

Drivers are allowed to allocate memory from two pools; this is the lesser-used one, and for good reason - all memory allocated from the non-paged pool is, not surprisingly, never paged out. It is useful for operations that require this, such as DMA transfers, but not a very good thing to use for normal driver allocations.

You can see the size of this pool in Task Manager (Kernel Memory, Nonpaged) or with Performance Monitor (counter \\.\Memory\Pool Nonpaged Bytes).

2 Paged pool

The normal driver memory pool; all this memory can be paged out at the kernel's whim, and is ideal for storing driver structures that aren't used by hardware.

You can see the total allocated size of this pool in Task Manager (Kernel Memory, Paged) or with Performance Monitor (counter \\.\Memory\Pool Paged Bytes). You can see the currently paged-in size with Performance Monitor (counter \\.\Memory\Pool Paged Resident Bytes).

3 Driver code

This is the pageable memory being used to hold drivers, both their code and data pages.

You can see the size of this with Performance Monitor (counters \\.\Memory\System Driver Total Bytes and \\.\Memory\System Driver Resident Bytes).

4 Kernel code

This is the pageable memory being used to hold the kernel's own code (e.g. nsoskrnl.exe, hal.dll, boot drivers and boot file systems).

You can see the size of this with Performance Monitor (counters \\.\Memory\System Code Total Bytes and \\.\Memory\System Code Resident Bytes).

5 System cache

This is the area of kernel memory used for caching, mostly the file cache. This memory is never paged out, it is just freed (paging out a cache would be rather pointless).

You can see the size of this with Performance Monitor (counters \\.\Memory\System Cache Resident Bytes).

6 Applications

This area is defined by one book as "total memory minus the other 6 components", which is hardly surprising - it is a really hard number to track, and for various reasons there is no Performance Monitor counter for this. |\.\Process(_Total)\Working Set will usually come close, but can just as easily be larger than the real applications usage as it can smaller.

The reason it is so hard to calculate this value is simple: shared memory. This is the same reason that ps is "wrong" on Linux, as explained pretty well in the article I mentioned at the start of this post. For exactly the same reasons, Task Manager and Performance Monitor will "lie" about the memory usage.

Shared memory can be an executable (EXE, DLL, etc.) loaded into more than one process space, or specially allocated "shared memory" which is sometimes used for inter-process communications.

Each process has a working set (counter \\Process(*)\Working Set) which reports the total amount of physical memory used by that process. Task Manager calls this column "Mem Usage". Some of this memory is almost certainly shared with other processes, and thus the total of all working sets will be greater than the actual amount used.

Each process also has private bytes (counter \\Process(*)\Private Bytes) which reports the amount of allocated memory specific to this process, e.g. malloc and other direct allocations. Task Manager calls this column, rather confusingly, "VM Size". None of this memory is shared, but you also cannot tell how much of the working set is private bytes, and how much is shared bytes. (Note that a DLL loaded into a single process is still 'shared' memory, and not private bytes, because it can be shared.)

Process Explorer tries to help things by listing "WS Private", "WS Shareable" and "WS Shared", which it does by collecting data from all processes via a kernel driver. In this case, WS Private + WS Shareable = Working Set. WS Shared is just how much of the memory that can be shared is actually being shared.

I should also note that drivers can allocate memory which falls into this group, and is impossible to track as far as I know. Very few can, or do; the most notable example is Virtual PC, which allocates the VMs' memory like this.

7 "Available"

You can see the size of this group in Task Manager (Physical Memory, Available) or with Performance Monitor (counter \\.\Memory\Available Bytes).

It is not, however, as simple as it appears. Not all of the "available" memory is free memory, and therein lines the subtlety.

"Available" memory is made up 3 types:

• Standby List
• Free List
• Zeroed List

In Windows Vista, there are some new Performance Monitor counters to measuring the size of these three types, \\.\Memory\Standby Cache Core Bytes, \\.\Memory\Standby Cache Normal Priority Bytes, \\.\Memory\Standby Cache Reserve Bytes and \\.\Memory\Free & Zero Page List Bytes).

When Windows want to trim a process' working set, the trimmed pages are moved (usually) to the Standby List. From here, they can be brought back to life in the working set with only a soft page fault (much faster than a hard fault, which would have to talk to the disk). If a page stays in the standby List for a long time, it gets freed and moved to the Free List.

In the background, there is a low priority thread (actually, the only thread with priority 0) which takes pages from the Free List and zeros them out. Because of this, there is usually very little in the Free List.

All new allocations always come from the Zeroed List, which is memory pages that have been overwritten with zeros. This is a standard part of the OS' cross-process security, to prevent any process ever seeing data from another. If the Zeroed List is empty, Free List memory is zeroed and used or, if that is empty too, Standby List memory is freed, zeroed, and used. It is because all three can be used with so little effort that they are all counted as "available".

Observed Behaviours

With all that above information, you might now be able to guess what it going on when you minimize an application and see "Mem Usage" in Task Manager drop by a large amount, and why restoring the application soon after doesn't usually involve any disk paging.

I'm sure browser plugins come with their own little Quantum Failure Generators or something. I've spent most of today trying to narrow down certain sizing issues with the Windows Media Player plugin across various OS versions and browsers. It was not (and still isn't) fun.

At one point, even Virtual PC 2007 itself crashed.

Then, starting openSUSE 10.2, it decided that it needed to fsck each and every partition just because it hadn't done it for a while. This would have been fine, except that it blocks the boot process for upwards of an hour with no indications on the graphical boot screen.

Now, I'm about to go install some beta software as part of a private beta test program; this can't possibly go wrong, can it?

General Language and Keyboard Shortcuts

Shortcut Action <Left Alt> + <Shift> Switch input language <Control> + <Shift> Switch keyboard layout

These can be changed from Control Panel, in Regional and Language Options, Keyboard and Languages tab, "Change keyboards...", Advanced Key Settings tab. Alternatively, right-click the Language Bar and select "Settings...".

Japanese IME Shortcuts (summary)

Normal Mode (not in the middle of entering a word/phrase) <Control> + <Caps Lock> Switch to Hiragana input <Alt> + <Caps Lock> Switch to full-width Katakana input <Shift> + <Caps Lock> Toggle half-width alphanumeric (English) input and Hiragana input <Alt> + <`> <Control> + <Shift> + <Caps Lock> Toggle kana and romanji input <Shift> + <Space> Enter half-width alphanumeric (English) space Conversion Mode (when entering word/phrase via IME) <Shift> + <Left> Use less characters for conversion <Shift> + <Right> Use more characters for conversion <F6> Convert to Hiragana Each of these will flip through a number of possibilities on each press. <F7> Convert to Katakana <F8> Convert to half-width Katakana <F9> Convert to alphanumeric <F10> Convert to half-width alphanumeric (English)

These can be changed from the Japanese IME itself, which can be accessed from the Language Bar (right-click and select "Settings...", then select the IME and click "Properties..."). On the Editing tab, there is a drop-down of key templates and the option to edit. The above keys are all for the default key template ("Microsoft IME").

I am currently in the progress of implementing the necessary features and components in my weblog software to allow the use of a standalone client to post entries (and ultimately edit, as well). As I'm already beta testing a bunch of other Live tools, I thought I'd start with Windows Live Writer.

The current beta version supports:

• WordPress.com
• Blogger
• TypePad
• LiveJournal
• Movable Type
• WordPress (inc. 2.2+)
• Community Server
• dasBlog
• Radio Userland

Additionally, it supports two raw APIs on anything that implements them:

• Metaweblog API
• Movable Type API

Not bad. So, I've chosen the Movable Type API for mine, but I'm jumping ahead - there's something else, something really cool, that I should mention.

Really Simple Discovery, RSD, is a method by which a tool can identify information about a page and its supported editing schemes. Including a link in the main weblog page with rel="EditURI" to point to the RSD file (which is XML), and that indicates which editing APIs are supported and their respective URIs.

Windows Live Writer checks for and uses the RSD information, which results in a 3-entry configuration: weblog URL, username and password. It doesn't get much simpler than that.

Still to come: the Movable Type API, Blogger, categories and more.

I find Microsoft Windows Vista Media Center is great in so many ways, but nothing's perfect (more's the pity).

One thing which has been irritating me for a while is how it was using the "shrink-to-fit" method of sizing local video playback instead of "expand-to-fit". This results in any wide-screen videos losing the left and right edges, as I only have a 4:3 monitor (shame on me). I believe it'd be causing equal problems with non-wide-screen videos if I had a wide-screen monitor, though.

Until a few days ago, I'd been using ffdshow's capable suite of options to force output into 4:3 (while preserving the aspect ratio, i.e. adding evil black bars). This really eats CPU, even on the fastest resize mode, increasing usage by approximately 30%, which was actually causing my AMD64 3200+ (2.0GHz) to run out of cycles on some videos.

What I found a few days ago, though, was the real solution: time to start the Registry Editor, folks. Locate the following key:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Media Center\Settings\VideoSettings

Under this key there are a large set of options, most of which you don't want to touch. In this case, however, one particular one is crucial - ZoomMode_Video. Set that to "0". Done.

Footnote: There are 3 other ZoomMode_ options (ATSC, DVD, TV) and all 3 were already set to "0" here. ZoomMode_Video, however, was set to "1". I'd be very interested to hear how many, if any, other people have any of these ZoomMode_ options not set to "0" and which ones.

Although I don't really like Joel on Software, in this case he has the most appropriate rant to give the context for this post.

"Every time you want to leave your computer, you have to choose between nine, count them, nine options: two icons and seven menu items."

Ignoring the fact that I only have six menu items (no Hibernate), he has entirely missed the fact you only need the two buttons in all normal circumstances.

Sleep (left button)

By default, the left button is sleep, and it is the new hybrid sleep added in Vista. This does a combination of hibernate and suspend from previous versions - saving your work to disk, but only putting the computer into a low power state. This lets you resume work really fast and protects from power-loss.

Lock (right button)

The right button locks the computer. But wait, it also gives you access to switch user - using that giant blue button labeled "Switch User" on the locked screen. You can even shut down (or restart, or sleep - again) from the Switch User screen.

Redundant Options?

In his rant, Joel suggests that you don't need these at all:

• Switch User
• Log Off
• Restart

While they are not usually useful, it's still useful sometimes to log off or manually restart, and switch user is a shortcut to lock+switch user which you might not remember or know.

Shutdown

In fact, there is only one option you might regularly need: shutdown. If you need this often, you're unlikely to need sleep, so the obvious thing to do is replace the sleep button with a shutdown one:

1. Control Panel > Hardware and Sound > Power Options.
2. Change when to turn off the display.
3. Change advanced power settings.
4. Power buttons and lid > Start menu power button > Setting.
5. Select shutdown from the drop-down list.
6. Done.

The original Microsoft Train Simulator was a great game at the time, and continues to be good fun (I'll save why it's better than Kuju's newer Rail Simulator for another time). It does, however, not entirely work by default on Windows Vista. There are a couple of issues:

• Resolution changes cause windows to be rearranged.
• On exit, it tries to create C:\FileIn.cns and C:\FileOut.cns and gets stuck in a loop because it can't.

You could work around the latter problem by running it as administrator, but that's clearly a substandard "fix". However, a much better solution which can solve both issues is the Compatibility Administrator in the Microsoft Application Compatibility Toolkit.

The Compatibility Administrator lets you tap in to a powerful collection of fixes already written by Microsoft for making other applications compatible with new versions of Windows. It also lets you view the fixes applied to each and every application in its system AppCompat database.

After installing the Application Compatibility Toolkit, you can launch the Compatibility Administrator as a standard user. For the purposes of this post, I'll create an AppCompat database just for fixing Train Simulator, but you can fix any number of programs with a single database, which simplifies deployment and installation.

1. Since it starts with a new database by default, just rename it by right-clicking and select "Rename". It really doesn't matter what you call it; I called mine "James Ross" in case I ever fix anything else with it.
2. Select the database, select the "Database" menu, "Create New", "Application fix...". This opens the wizard which will configure all the fixes we want for a single application.
3. Enter the details on the first page:
   • Name of the program to be fixed: "Train Simulator" (it's only for display).
   • Name of the vendor for this program: "Microsoft" (also only for display).
   • Program file location: browse to "train.exe" (e.g. "C:\Program Files\Microsoft Games\Train Simulator\train.exe"). This will be used later.

   

4. Now we get to pick from some standard fixes, including the commonly-used version lies. We don't want to select anything here, so ensure "None" is selected for the "Operating System Modes" and move on.

   

5. This is where the fun happens! There is a long list of possible fixes here, many of which can also take a command-line with options to control or limit the code that applies the individual fix. For the relatively simple problems with Train Simulator, we want to use two fixes:

   • CorrectFilePaths

     With this, we can redirect CreateFile API calls (among other file APIs) to actually access somewhere other than where the program passes. We use the following command-line:

     -b "C:\FileIn.cns;%UserAppData%\FileIn.cns" "C:\FileOut.cns;%UserAppData%\FileOut.cns"
     

     The -b (bare) turns off the standard mapping (which covers some system files that have moved over Windows versions), and then we specify two file corrections. Important to note that the double-quotes go outside the semi-colon separated pair of file paths. Also, we make use of one of the replacements (%UserAppData%), but note that these are not environment variables. There is a good weblog post about using CorrectFilePaths as well as some TechNet documentation.

   • ForceTemporaryModeChange

     This one is much simpler, and probably obvious from its name! It simply ensures that any resolution change is flagged as temporary, which prevents the window manager from shuffling things around.

   

   As you may have noticed, the wizard has "Test Run..." buttons on each page of options. You need to be an administrator to use them (as it installs an AppCompat database temporarily to do it), but they can be very handy in some cases.

6. Now we must tell Windows how it is supposed to identify that this set of fixes should be applied to a launching application. The wizard will automatically add the executable selected at the start, and tick some properties. In our case, there's no need for most of them and I unselected everything except PRODUCT_NAME.

   

   You could, if needed, add references to other files and decide which properties from them matter too; the fixes will still only be for the original executable, but it provides finer control over when to apply the fixes.

7. That's the AppCompat database created. You should now save it somewhere you'll remember (and be able to access from your administrator account).
8. Close Compatibility Administrator, and re-open it as administrator.
9. Open your AppCompat database, right-click it and select "Install".
10. Done!

Now, any time you run Train Simulator, the two fixes will be applied and joy will ensue.

I'm sure most people know that Microsoft designates the second Tuesday of each month as "Patch Tuesday" - the standard day for releasing all kinds of updates (both security and non-security) to Windows and other Microsoft products and technologies. Marking this in Windows Calendar is a trivial operation:

However, less well known is that on the Thursday before Patch Tuesday, Microsoft release an "Advance Notification" which indicates how many security patches are planned for release on the following Tuesday, what products they affect, and their severity. But how would you add that to Windows Calendar?

You can't do it via the GUI - it's simply too complex a rule. Wait, how would you describe it in any calendar anyway? Windows Calendar, like the majority of calendaring applications, uses the iCalendar format (RFC 2445). You can't specify that an event is positioned relative to another event, but iCalendar is still very flexible, as it allows you to combine restrictions on a repetition rule (see section 4.3.10 of the RFC for the gory details).

The simplest way I found to get the correct Thursday is to restrict the event using two criteria: month day must be 3 - 9 inclusive and it must be a Thursday. This works because only one day in the range 3 - 9 can be a Thursday each month, and it is five days ahead of the range of possible Patch Tuesday days (8 - 14). The rule is thus: "RRULE:FREQ=MONTHLY;BYMONTHDAY=3,4,5,6,7,8,9;BYDAY=TH".

To add such an event:

1. Start by adding a normal monthly repeating event and give it a unique summary.
2. Close Windows Calendar.
3. Find all the calendars in C:\Users\<username>\AppData\Local\Microsoft\Windows Calendar\Calendars.
4. Open the correct calendar file (they use the name set in the GUI).
5. Find the correct event by searching for the summary of the event.
6. Just above the summary is the "RRULE", which should be replaced with "RRULE:FREQ=MONTHLY;BYMONTHDAY=3,4,5,6,7,8,9;BYDAY=TH".
7. Re-open Windows Calendar, and it should appear on the Thursday before the 2nd Tuesday of every month.

Done! You can even edit anything about the event (except the recurring) from the GUI. Windows Calendar even knows it can't edit the more advanced recurrence rule:

It's well-known that the \Windows\winsxs directory in Windows Vista is large and can take up a significant portion of disk space on smaller devices. Less well-known is what it actually does, why it is huge or why it's not entirely a waste of space. I'll try and answer all three of these today.

To help dig in to this, I've written a small C++ application that will report certain information about the files in a particular directory - or individual files - and will use this to help explain the answers. Binaries and source code will be provided at the end.

What does winsxs do?

At the highest level, it is a collection of "packages" - lots of small groups of files. Each package (group of files) is identified by:

• Architecture ("x86", "amd64", "ia64", "wow64" (32bit on 64bit) and "msil")
• Name
• Signing Key
• Version
• Locale ("none", "en-us", etc.)
• Package Hash

It does more than just store the packages, though; applications can bind themselves to particular packages and specify what versions are acceptable. This is most evident with the Microsoft Visual C++ runtime files which, along with the Common Controls version 6 package, are more or less all you'll find in \Windows\winsxs on Windows XP. There are other features, like package redirections, which are in Windows XP as well.

Why is winsxs huge?

For Windows Vista, however, the main change is not so much how it works (although that was improved and made more robust as well) but in what it's used to store. In Windows Vista, all the operating system components are in packages inside \Windows\winsxs. That's all the core features (like Explorer) and everything you can enable in "Turn windows features on or off" (like IIS). That's a lot of stuff!

A consequence of putting system components in \Windows\winsxs is that they can be uninstalled reliably and with less dependence on order in Windows Vista - Windows XP keeps a load of \Windows\$NtUninstall... directories to manage it, but it has issues on ordering of installs and uninstalls.

Back in Windows 2000, you could install all the data from the CD-ROM onto the hard disk to avoid needing the CD when turning features on or off. I used it, but few people knew about it as you had to set it all up by hand (some OEMs did bother, though). This was a much simpler version of what \Windows\winsxs is in Windows Vista today. If you've ever turned on East-Asian support in Windows XP, you'll probably know how annoying it is to go and find the CD just to copy some fonts and locale support - this is just one of many places where Windows Vista already has the data available and it will never need you to rummage for the install DVD.

Why is winsxs not entirely a waste of space?

I'm sure you can appreciate that not needing to rummage for a DVD when changing features is good, but you probably don't do that often. Windows Vista might have a lot of data in \Windows\winsxs, but what about the features that are enabled? Don't they use up twice their size in disk space?

Here's the clever bit.

Installed features only consume space for their data, if they have any, but not for any of the code. How does that work? Hardlinks, a little-known feature of NTFS since Windows 2000 that allow the same file (and the same data) to be available from multiple locations in the directory hierarchy. The important part of measuring disk usage is that the vast majority of tools - Windows Explorer included - don't know or don't bother to know about hardlinks, which is partially why I wrote my own tool to explore this further.

Let's look at an example, C:\Windows\system32\shell32.dll ("Hardlink Scanner.exe" /F C:\Windows\system32\shell32.dll):

Breakdown for "C:\Windows\system32\shell32.dll"
===============================================
  Unique ID:    8e0000000a1534
  Hardlink count:            2
  Naive file size:  25,794,560 bytes
  Unique file size: 12,897,280 bytes
  Kind of file:         normal
  Filenames:
    \Windows\winsxs\amd64_microsoft-windows-shell32_31bf3856ad364e35_6.0.6001.18062_none_c808e76dca883949\shell32.dll
    \Windows\System32\shell32.dll

In this example, it's clear this is a 64bit system as it is the "amd64" architecture that is linked into \Windows\system32. More important is that although both locations appear to have their own 12MB shell32.dll, using nearly 25MB in total, there is actually only one file and only 12MB of disk space is used.

Another example, the entire directory C:\Windows\SysWOW64 ("Hardlink Scanner.exe" C:\Windows\SysWOW64):

Hardlinks:    Files              Unique Files
  <total>          4,278              4,275 ( 99%)
  1                  394 (  9%)         394 (  9%)
  2                3,101 ( 72%)       3,101 ( 72%)
  3                  725 ( 16%)         725 ( 16%)
  4                   53 (  1%)          50 (  1%)
  5                    1 (  0%)           1 (  0%)
  7                    4 (  0%)           4 (  0%)

Here, about 90% of the files in the directory have at least one other hardlink that is outside this directory (you can work this out by comparing the "Files" and "Unique Files"; if the hardlinks were all inside this directory, the unique counts would be significantly lower). The higher-than-2 hardlink counts also bring up another clever feature of the Windows Vista \Windows\winsxs directory. Let's have a look at the 32bit MPEG 2 decoder ("Hardlink Scanner.exe" /F C:\Windows\SysWOW64\Mpeg2Data.ax):

Breakdown for "C:\Windows\SysWOW64\Mpeg2Data.ax"
================================================
  Unique ID:     100000004f2ab
  Hardlink count:            4
  Naive file size:     278,528 bytes
  Unique file size:     69,632 bytes
  Kind of file:         normal
  Filenames:
    \Windows\winsxs\x86_microsoft-windows-v..e-filters-tvdigital_31bf3856ad364e35_6.0.6001.18061_none_dbbd58ec573f657a\Mpeg2Data.ax
    \Windows\winsxs\x86_microsoft-windows-v..e-filters-tvdigital_31bf3856ad364e35_6.0.6001.18000_none_dbfd382a570fa47d\Mpeg2Data.ax
    \Windows\SysWOW64\Mpeg2Data.ax
    \Windows\winsxs\x86_microsoft-windows-v..e-filters-tvdigital_31bf3856ad364e35_6.0.6001.18115_none_dbf76b9657133c48\Mpeg2Data.ax

Although there are three different versions of this package, Mpeg2Data.ax didn't change between versions and so \Windows\winsxs has used hardlinks between the packages as well as to the final destination. That's reduced the space consumption to just 25% for this file.

What does the saving look like for the whole of \Windows? ("Hardlink Scanner.exe" C:\Windows):

Hardlinks:    Files              Unique Files
  <total>         93,670             76,585 ( 81%)
  1               61,354 ( 65%)      61,354 ( 80%)
  2               22,750 ( 24%)      12,467 ( 16%)
  3                6,117 (  6%)       2,143 (  2%)
  4                  552 (  0%)         138 (  0%)
  5                1,365 (  1%)         273 (  0%)
  6                  796 (  0%)         133 (  0%)
  7                  329 (  0%)          47 (  0%)
  8                  200 (  0%)          25 (  0%)
  9                   18 (  0%)           2 (  0%)
  10                  30 (  0%)           3 (  0%)

Naive file size:        25,266,466,330
Unique file size:       19,881,302,264 ( 78%)
Difference:              5,385,164,066 ( 21%)

That's more than 5GB saved by using hardlinks within \Windows. Scanning my entire drive ("Hardlink Scanner.exe" C:), to include \Program Files (Internet Explorer and Media Player, for example) gives an overall difference of 5.9GB.

So, just takes those computed sizes from Windows Explorer (and other apps) with a little pinch of salt when dealing with Windows Vista's system files.

Code: Hardlink Scanner (x86), Hardlink Scanner (x64) and Hardlink Scanner source (Visual Studio 2008 Solution).

A feature new to Windows Vista is the Games Explorer, a folder dedicated to the games installed on the computer; games are required to exclusively add themselves there as part of the Games for Windows technical requirements, and Microsoft provide details of hundreds of pre-Vista games which appear automatically as a result.

Unfortunately, you can't search this folder directly from the Start Menu. While this is an annoying problem, it's not insurmountable. In fact, it's pretty easy to manually rectify with a short bit of scripting.

Update Games Explorer is a short Command Script to enumerate the contents of your Games Explorer and copy the shortcuts into the Games folder in the Start Menu, thus rendering them indexed and searchable. The script can be run directly or as a scheduled task, whichever suits best.

Reading Startup, part 1, where Vladimir Vukićević is measuring warm and cold start times for Firefox, he mentions that he is doing the work on Mac OS X rather than Windows because there is a simple tool to empty the system's file cache to test cold starts without actually restarting the OS. I like challenges.

There isn't, it seems, a nicely documented API for doing this on Windows - it certainly isn't something the majority of applications would want to do, though, either. However, there is an undocumented API for it: NtSetSystemInformation(SYSTEM_INFORMATION_CLASS, PVOID, ULONG) (it has a slightly documented sibling for getting information, NtQuerySystemInformation(SYSTEM_INFORMATION_CLASS, PVOID, ULONG, PULONG)). These are actually fairly generic wrappers around a whole load of kernel things; the undocumented information class of interest here is "SystemCacheInformation" (value 0x15), which lets you get and set information about the system file cache.

Each information class for NtSetSystemInformation/NtQuerySystemInformation has a single structure, which goes into the 2nd argument (and its size into the 3rd). For 32bit (applications; not OS) the cache information structure can be defined like this:

    typedef struct _SYSTEM_CACHE_INFORMATION {
        unsigned long CurrentSize;
        unsigned long PeakSize;
        unsigned long PageFaultCount;
        unsigned long MinimumWorkingSet;
        unsigned long MaximumWorkingSet;
        unsigned long Unused1;
        unsigned long Unused2;
        unsigned long Unused3;
        unsigned long Unused4;
    } SYSTEM_CACHE_INFORMATION, *PSYSTEM_CACHE_INFORMATION;

Along very similar lines to SetProcessWorkingSetSize, specifying the minimum and maximum working set values as 0xFFFFFFFF signals to flush as much as possible out of the system file cache, which gets it down to less than 100KB by the time I can check it afterwards.

Simple, really.

The rest of the code I wrote is to enable the SE_INCREASE_QUOTA privilege Administrator users have, which is necessary to call the API. I believe the executable will work on anything from Windows 2000 and up, with no external dependencies; I've tested it on Windows XP 32bit and Windows 7 64bit. You will obviously need to run it elevated (run as Administrator).

Executable and Code: purge.exe and purge.cpp.

I have a Matroska (.mkv) file with the following tracks (data streams):

Tracks : 2
Track 1 : Video
   - Codec : (V_MPEG4/ISO/AVC)
Track 2 : Audio
   - Codec : MPEG Audio 1, 2, 2.5 Layer III (A_MPEG/L3)

Nothing particularly special there; I have the following relevant DirectX Media Objects (DMOs), DirectShow and Media Foundation codecs installed:

• Haali Media Splitter: a DirectShow splitter filter for Matroska files, among other container formats (analogous to the AVI Splitter for .avi and others).
• ffdshow: a DirectShow decoder filter for just about anything, including MPEG-4 Video and MPEG-1 Audio Layer 3 (MP3).
• Windows 7's in-box DMOs decoder filters for MPEG-4 Video and MP3. These can be used by both DirectShow and Media Foundation.

Question: What happens if this Matroska file is played in Windows Media Player or Windows Media Center?

Answer: No video and audio stutters a lot.

Question: Why?

Answer: Both will try to use Media Foundation first and DirectShow second. As Media Foundation has no preferred splitter for Matroska files (either in-box or that I've installed), it hunts for a supported transform (similar to DirectShow's filters) with which to play the file; the MP3 transform duly indicates that it can play the file.

I believe this is because the MP3 decoder ignores the data at the start of the file which it doesn't understand (to allow for ID3 tags) and then picks up the first frame of the audio stream inside the file. The stuttering is most likely it attempting to play back the video frames of data (the two data streams are interleaved within the container).

The solution: Amazingly simple; the only thing that matters is that they're trying to use Media Foundation first, so set one registry key to indicate .mkv files prefer to be handled by DirectShow and it works great in both players.

HKEY_CURRENT_USER\Software\Microsoft\MediaPlayer\Player\Extensions\.mkv
    Runtime    REG_DWORD    0x7

Done.

Windows Live Mesh has a remote connections feature, similar to Remote Desktop, which can be accessed from the Windows Live Mesh client and the Windows Live Devices website. I've used it frequently when I needed to access my home machine from work - it connects despite no ports being forwarded in the router and it doesn't mess up my multi-monitor configuration at home (normal Remote Desktop will change the resolutions and such).

That was until I changed my multi-monitor configuration at home.

Old arrangement: 1280x1024 / 1600x1200* / 1280x1024 (* primary)

New arrangement: 1280x1024 / 2560x1440* / 1600x1200 (* primary)

Then, every time Windows started, shortly after the login screen appeared, all the monitors would jumble themselves up in to something very closely resembling the old arrangement: 1280x1024 / 1280x1024 / 1600x1200* (* primary). It seemed clear something was attempting to put the monitors into the old arrangement based on some saved information, but it wasn't obvious what that something was.

To diagnose the issue, I carefully timed when the monitors first started showing signs of rearrangement after boot and consulted the list of processes and their start times (from "wmic process") to see what was starting at or just before the rearrangement.

That's when I spotted "C:\Program Files\Windows Live\Mesh\wlcrasvc.exe", the Windows Live Mesh remote connections service, starting just seconds before the rearrangement.

So up came Registry Editor (regedit.exe) and a look through HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft until I found HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Live Mesh. Hiding under there, at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Live Mesh\Remote Desktop\DisplayDevices, is a key for each display device on the machine and some monitor arrangement data (x, y, width, height).

I stopped the Windows Live Mesh remote connections service and deleted the entire HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Live Mesh key, since it didn't appear to contain anything except the display devices information. Upon restarting the service, some parts of the key came back but no monitors got rearranged and, upon connecting from another machine, the display devices keys came back, but with my new arrangement. I restarted the service again to be sure, and nothing rearranged itself.

Fixed!

If you've got a crashed process that WER has handled but you either know the JIT debugger is set wrong or you haven't got one set up at all (so no "Debug" button on the crash dialog), you can leave the dialog open and attach any debugger of your choice to the suspended, crashed process.

However, there's a problem. By attaching the debugger to the suspended process, the process' last-exception information has been lost; this is because the way the debugger sucessfully attaches to a suspended (or hung) process is to inject a new, running thread and have that thread crash. So your debugger, and any minidumps it generates with .dump, will not be able to find the original program's exception information. Oops!

The solution is very similar to Raymond Chen's post on Sucking the exception pointers out of a stack trace. The difference is how we find the pointers and what we do with them.

Starting with the stack trace from kb:

RetAddr           : Args to Child                                                           : Call Site
000007f9`d88212d2 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!NtWaitForMultipleObjects+0xa
000007f9`dae8d20e : 00000000`02300000 000007f6`96e75000 00000000`00000000 00000000`000001dc : KERNELBASE!WaitForMultipleObjectsEx+0xe5
000007f9`dae8cfd2 : fffff8a0`00000080 00000000`80004005 00000000`000001ec 00000000`00000000 : KERNEL32!WerpReportFaultInternal+0x1fa
000007f9`d889fc87 : 00000000`00000000 00000000`00195c30 00000000`00000030 00000000`00195c30 : KERNEL32!WerpReportFault+0x42
000007f9`db56a43d : 00000001`00000000 00000000`00196990 00000000`0019f620 00000000`003441d0 : KERNELBASE!UnhandledExceptionFilter+0x1d7
000007f9`db4b4ad4 : 000007f9`d8eeabdd 00000000`00196990 00000000`00000000 00000000`00000000 : ntdll!LdrpLogFatalUserCallbackException+0x4d
000007f9`db4d464d : 00000000`00000000 00000000`00195de8 00000000`00195da0 000007f9`d8f7f000 : ntdll!KiUserCallbackDispatcherHandler+0x20
000007f9`db4d567c : 000007f9`d8ee0000 00000000`0019f5c0 000007f9`0000e4f0 00000000`00000000 : ntdll!RtlpExecuteHandlerForException+0xd
000007f9`db4b4bba : 00000000`00000000 00000000`00000000 000007f6`96e7e300 00000000`00000000 : ntdll!RtlDispatchException+0x392
000007f9`db4b2acd : 000007f9`d8bbc36c 00000000`00360f00 00000000`00360f00 00000000`00360f00 : ntdll!KiUserExceptionDispatch+0x2e
000007f9`d8bbc36c : 00000000`00360f00 00000000`00360f00 00000000`00360f00 00000000`00000000 : ntdll!memcpy+0x21a

The EXCEPTION_POINTERS structure address seems[1] to be passed as arguments 2 and 4 of the call to "KERNEL32!WerpReportFault". From this, the exception and context records can be displayed - but we only really need to include the EXCEPTION_POINTERS address in the minidump, since adding this one address will allow the !analyze command to work.

Create the minidump using the command ".dump /ma /xp 00195c30 dump.dmp" and you're done. (Apart from all of the actual debugging - have fun!)

[1] This is on Windows 8 64bit running the 64bit WinDbg debugging a 32bit executable. YMMV.