Scott Blomquist

Every once in a while, I think I know exactly what the code that I’m writing is doing, and then I discover, often through some catastrophe, that I didn’t quite understand all the details.  One particularly instructive (or would that be destructive?) example that comes to mind is a T-SQL mistake that ended up deleting every row in a table instead of just the three or so that I was expecting to delete (feel free to play along on your own SQL Server using the Northwind sample database):

delete from Suppliers
where ContactName
  in
  (
    select ContactName 
      from Shippers
     where ShipperID >= 3
  )

What happened is that ContactName is not a valid column name in the Shippers table, but even inside the parentheses the ContactName column from the Suppliers table is in scope. In fact, just because you mentioned a column that only lives outside the parentheses, SQL Server is happy to treat this as what is called a “correlated subquery”, and it’ll go to the trouble of doing a cross join on the two tables to give you every possible pairing of rows. Needless to say, this result set includes every ContactName under the sun even after being filtered against the where clause, which means the delete statement has the full authority to drop every row in the Suppliers table.  Ouch!

I really wish that I could ask SQL Server to give me some sort of warning in cases like this, as it seems to me that most people who haven’t done much with the ‘in’ syntax would, like me, not expect SQL Server to even cooperate if the stuff inside the parens doesn’t parse when taken alone. But now I know better. And try as I might, I just can’t stay upset as I had a backup from earlier in the day, and it sure made for a good puzzle.

Stupid Remote Desktop trick #1

1. Connect to a remote machine using Remote Desktop.
2. In device manager, right-click on your network card and choose “Disable“.
3. Kick yourself for being so stupid, go to the machine’s console (hopefully it’s within walking distance), and re-enable your network card.

Stupid Remote Desktop trick #2

1. Connect to a remote machine using Remote Desktop.
2. Press Ctrl-Alt-End, and choose to shut down your machine. (It seems that Windows Server 2003 warns that you may be shooting yourself in the foot, but Windows XP Pro doesn’t.)
3. Kick yourself for being so stupid, go to the machine’s console (hopefully it’s within walking distance), and turn the machine back on.

Stupid Remote Desktop trick #3 (most recently discovered, and all-time favorite)

1. Connect to a remote machine using Remote Desktop.
2. Get prompted to change your password while logging in (i.e. log in while it’s nearing its expiration date).
3. After typing your old password, but before typing your new password, accidentally hit Enter instead of Tab.
4. Windows will congratulate you on your new password.
5. Windows will tell you that you can’t log in because you have a blank password.
6. Kick yourself for being so stupid, go to the machine’s console (hopefully it’s within walking distance), and change your password to something that’s not blank.
7. Set group policy to prevent blank passwords.

Let’s begin with a simple experiment that you can perform on your own computer:

1. Count the number of icons in your Taskbar Notification Area, including any rarely used icons that Windows XP may have hidden under the little blue less-than button. The Taskbar Notification Area is that part of your Windows taskbar near the clock where lots of little icons go. [1]
2. Kill explorer.exe. (If you’re a command line type running Windows XP or later, “taskkill /im explorer.exe /f” will do the trick. If you’re a GUI type, start Task Manager (Ctrl-Shift-Esc or your preferred method), choose explorer.exe and choose “End Process”.)
3. Restart explorer.exe. (From a command line: “explorer”. From TaskMan: File->New task… “explorer”.)
4. Once your taskbar is back, recount the number of icons in your notification area.

Chances are enormous that you have fewer notification icons than you started with. On my computer, the number went from 10 to 4! (Only Outlook, Windows Messenger, eTrust Anti-virus, and the Windows volume control survived. Lots of stuff didn’t.)

Those icons will probably stay gone until you stop and restart the program responsible for each of them. Where did they go? Why did they go there?

It turns out that explorer.exe [2] loses all information about what icons were displayed there when it dies (and who can blame it for that?). It is up to each application that wishes to use the Taskbar Notification Area to remind explorer.exe’s reincarnated self what it wanted displayed. The method by which your application properly gets notice of the reincarnation of explorer.exe (or, more specifically, the creation of the Taskbar) is described by MSDN Library as follows:

With Internet Explorer 4.0 and later, the Shell notifies applications that the taskbar has been created. When the taskbar is created, it registers a message with the TaskbarCreated string and then broadcasts this message to all top-level windows. When your taskbar application receives this message, it should assume that any taskbar icons it added have been removed and add them again. This feature generally applies only to services that are already running when the Shell begins execution. [Search for “Taskbar Creation Notification” at [3]]

This obscure little MSDN Library gem makes it sound like there’s no reason a normal app should care about notification that the taskbar was just created, but as we just saw, real apps can be affected in a case where explorer.exe crashes or gets killed. While explorer crashes are not a terribly common occurrence in modern Windows releases, they are not unheard of. There is little reason not to get this behavior right considering that you can probably implement it by adding 6 or fewer lines to your window proc as shown in the example code in the above-linked MSDN Library article.

Excuse me while I restart so as to get back my other notification icons…

Footnotes
[1] You may know this as your “tray” or “systray” but Raymond Chen explains why you might think that, and why you would be wrong.
[2] The Windows process responsible for drawing much of the Windows desktop, including the taskbar.
[3] inline link to MSDN Library article

Tribal Librarian? What on earth does that mean?!

To understand where I got such a strange name for my blog, we first need to understand “tribal knowledge”. iSixSigma.com defines tribal knowledge as “any unwritten information that is not commonly known by others within a company” [1]. For our purposes here, I’m using it slightly more generally to refer to any information (either correct or not) that is “known” by the people close to a particular subject, but is otherwise hard to come by. I notice cases of tribal knowledge all the time. It happens at work in the form of going on a hunt for the right person instead of the right reference document to answer some trivial question that I know has been asked a hundred times before me. It happens in my spare time in the form of encountering the same pitfalls that ever other consumer of some API has encountered during his first use of it, but that even still no good documentation exists to explain. Everywhere I encounter tribal knowledge, it just bugs me.

With this blog, I want to help stamp out tribal knowledge to the extent that I can, and that’s where the “librarian” part of the title comes in. Calling myself a librarian probably misses the mark a bit. After all, a librarian technically does more along the lines of managing a collection of existing knowledge than collecting new knowledge. But “tribal documentarian” and “tribal blogger” just don’t sound as nice. Besides, I hope to be in the position of managing a good-sized collection of existing knowledge here soon. In the meanwhile, I’ll get to work doing the collecting.

[1] http://www.isixsigma.com/dictionary/Tribal_Knowledge-488.htm

Postscript–something about me
I figure since this is my first post in this blog, you might want to hear a little bit about me. I’m a developer on the Windows Client Performance Team, and have been at Microsoft for nearly five years. I love working here because of the cool people and the cool projects that surround me on all sides. Aside from computer technology, my interests include writing and solving puzzles of most any kind, reading (mostly sci-fi with a little bit of fantasy thrown in), and studying language (natural and constructed, human and computer). I also enjoy hiking, camping, and backpacking, though I do less of these than I would like to admit. I expect to include articles from time to time on all of the above and probably some other stuff too. Let me know if there’s anything in particular that you’d like to hear more about.

Until next time when we’ll talk about the systray taskbar notification area, let’s contemplate it on the tree of woe.