Archives for category: Vista

Now that I no longer rely so much on my “work” laptop (a Dell Latitude D820), I’ve been a bit more open about rebuilding it and playing a bit with it.

Windows 7 PDC Alpha

A couple of weeks after coming home from the PDC in Los Angeles, I bit the bullet and repaved the machine with the Windows 7 Alpha we got. Installation went fine and everything seemed to work fine.

I was, however, not particularly impressed with it. Sure, there are a few nice UI and usability enhancements, but nothing that would make a really significant impact on my day-to-day usage. Performance was OK, but not great, either:

  • General usage performance was, as far as I could see roughly similar to Vista on the machine.
  • Aero was felt significantly slower than on Vista. It was particularly noticeable with effects turned on, like when windows are minimized/maximized, with very choppy animation.
  • Using it as a host OS for virtualization using Virtual PC 2007 didn’t worked too well. It worked, but was noticeably slower than on Vista for me.

Neither of this is really surprising since it is still an early alpha and well, VPC isn’t great at supporting new OS releases anyway. However, it does tell me that we probably shouldn’t expect any major performance changes with Win7 over Vista (Heck, we’d be very lucky if performance remains the same with minor improvements here and there).

Ubuntu 8.10 (Intrepid Ibex)

Last week I wiped Win7 and installed Ubuntu 8.10. This is the first time I’ve installed Ubuntu on this machine. I already hade Ibex running on my older Dell Inspiron 6000, where it works great and with very acceptable performance, and was curious how it would work out on the D820.

For the most part, it went well. Installation worked flawlessly, and all the hardware seems to work (though I haven’t exercised it too much yet). Performance-wise, it seems to behave very well, with good boot times and applications loading in very reasonable times.

screenshot

The big difference between the two machines (aside from the D820 having a dual core processor) is that this one has an NVidia graphics card instead of the ATI on the Inspiron. I installed the NVidia proprietary drivers (version 177) and it almost works very well.

The reason I say this is that the driver works fairly well, with good video performance and so on. However, the Linux Achilles heel raises it’s ugly head again. Surprisingly enough, Suspend (sleep) seems to work fine and even pretty fast to get in/out of.

Hibernation, however, doesn’t work at all: The machine tries to get into hibernation and appears to almost succeed, but right away restarts as if had been rebooted instead. Haven’t yet dug in to see what exactly the problem is yet.

On the good news good front: On this clean installation I was able to get font rendering right away working correctly, and even succeeded in having the terminal application (gnome-terminal) render Envy Code R correctly!

Like most other people making a living out of working with computers, I'm first line technical support for my friends and family. This morning my sister came up asking why her computer wasn't booting anymore, so I go to take a look.

It's not pretty.

My sister got a Dell Inspiron 1525 laptop a few months ago, running Windows Vista Home, and it has been working mostly fine since then (except for a minor issue with the wireless network). Last night, however, Windows Update popped up asking her to install the latest batch of critical updates. So she installed them, of course.

This morning, when she turned on her laptop, Vista greeted it with an empty black screen, with just the cursor in it. Shut it down (forcefully), and restarted only to get stuck at the same place.

So I tried the obvious list of things to check:

  1. Was the machine hanging up? Not really. You could still move the cursor, and the keyboard seemed to be responding; you just couldn't do anything at all because the black screen came before the logon desktop appeared.
  2. Try starting in Safe Mode? All of the three safe mode variants (regular, with network, with command prompt) get stuck at the same black screen.
  3. Try booting with default VGA drivers? Nope; still gets stuck.
  4. Try booting with the "Last known good configuration"? Nope. Apparently black screen was considered a good configuration. Go figure.

I then tried the recovery console, which did manage to start correctly. Unfortunately, it's useless. I checked for booting problems, and it found none. I then tried going to a previous restore point, only to find to my dismay that the system drive did not contain a single restore point. I'm pretty sure neither me nor my sister disabled system restore, so I can only guess that Dell disabled it when it shipped it from the factory. Why? Who knows.

Off to Google I go. Apparently, we're not the only ones to get hit by this issue. I was able to find at least one other Inspiron 1525 owner stuck with the same problem, but no solutions.

I then turned to Dell support, which was, predictably, useless. Without even bothering to look up any details or see if anyone else had reported a similar issue I got the standard "reinstall windows" response. Oh, well, I also got told that "Dell recommends that you turn off automatic Windows Updates after installing Windows". Not sure what to even respond to that.

Of course, at this point, there's really no other choice, but the fact that is that, for all I know, Windows Update might crap the machine again after repaving it; and for obvious reasons not getting the updates doesn't strike me as a good alternative.

A Suspect

At this point, I still don't know for sure what might have cause the issue. I do, however,  have a suspect. I noticed this morning that Vista had also downloaded and applied the updates on my own laptop (a Dell Latitude D820), without any nasty side effects.

So I checked the list of updates installed and ran into the hotfix mentioned by KB951618:

A black screen issue occurs on a Windows Vista-based computer or a Windows XP Service Pack 2-based computer that has Onekey Recovery 5.0 installed when you upgrade the operating system.

Well, the article never explains what a "Black Screen Issue" really is, but it sounds familiar. We don't have OneKey Recovery (at least in theory), but it's the only thing that sounds even somewhat related.

To be honest, though, I'm not even sure if that update got installed on my sister's laptop or not, since the recovery console doesn't really let you do much spelunking around (and I'm not very familiar with it).

Looks like I get to spend some quality time installing Vista again. Yippee!

Technorati tags: , ,

I started having some problems on my Windows Vista machine lately regarding sleep/hibernation: Sometimes (but very often) the machine would not wake up. Well, actually it seemed it had woken up correctly and the keyboard seemed to work, but the screen would stay black no matter what I'd do.

I also noticed that when this happened, trying to shut down the machine again wouldn't work either, so I had to resort to completely shut down power to it and reboot from scratch. Looking at the event log, though, it would indeed appear the machine partially woke up, even to the point that the network cards would pick up an IP address. No errors at all on the event log.

41x-ejLHVqL._SS400_ However, I suspected this was the fault of a recent hardware change: I had recently gotten a Microsoft LifeCam VX-7000 to replace my older VX-6000 and I had installed its drivers and software (which I'm sorry to say is still crap).

Next time the machine hung while trying to come out of hibernation, I tried disconnecting the LifeCam from the USB port before turning the machine on. No dice; it still hung up.

But then I noticed that if I disconnected the LifeCam before putting it to sleep/hibernate, it would wake up without a hitch! Weird, to say the least. I still don't know what the LifeCam drivers do or why they might cause the issue, but at least I know how to work around it for the time being.

Technorati tags:

I spent some time this weekend organizing a few files and source code repositories. As part of this process, I wanted to take advantage of NTFS hard-links and junction points, both of which are supported on Windows Server 2003/8 and Vista.

I had no problems with hard-links at all. I'm using the ln.exe tool from http://www.flexhex.com/docs/articles/hard-links.phtml to create them, and it worked great right from the start (I could also use the "fsutil hardlink create" command).

Junction points, however, gave me quite a bit more trouble. I've used Junction points in the past very successfully. I work with some code bases that for many reasons expect to have certain directories in the C:\ drive, but I keep all my code in the E:\ drive.

For this I've used cross-drive junction points to have the folder in C:\ point to the real folder in E:\ and it's worked great for a couple of years. One other tool I've used for this sometimes is Junction Link Magic.

Yesterday, however, I discovered that on Windows Server 2003, if the junction folder was on the same drive as the target folder, it just wouldn't work correctly. I could create the junction just fine, and I could even see the contents of the directory through the junction using explorer, cmd.exe or PowerShell.

Actually trying to access any of the children through the junction would result in the error:

The filename, directory name, or volume label syntax is incorrect.

I tried both of the tools I mentioned before, and it just wouldn't work. I tried creating the junctions from WinServer2K8 (where they worked perfectly) and then using the drive from 2003, and it still wouldn't work. This was easy to test, by the way, since this is a VHD image I share between several virtual machines.

Eventually, fellow MVP Juan T. Libre insisted I tried the linkd.exe tool in the Windows Server 2003 Resource Kit. I was reluctant to it since the other tools could create working cross-drive junctions and I was starting to suspect an OS limitation, but I gave it a go.

Much to my surprised, linkd.exe was able to create working same-drive junction points on Windows Server 2003. My guess is that there's some (probably undocumented) detail about how the APIs need to be called that can affect whether this works correctly or not.

Looking at the junctions using the "fsutil reparsepoint query" command clearly shows that the Reparse Data is slightly different between cross and same drive junctions, but not sure what it means from the API point of view. Just something to watch out for.

The lesson: Use linkd.exe on Windows Server 2003 to create same-drive junctions.

Technorati tags: ,

The Net.MSMQ Binding in Windows Communication Foundation has some built-in support for detecting and handling "Poison Messages".

One of the most useful ways of handling Poison Messages in queuing systems is to get them out of the way so that following messages can still be processed (if you're not doing in-order processing), but still keep the messages around so that they are not lost.

Unfortunately, this behavior is only supported by WCF in MSMQ 4.0 with the use of a poison sub-queue, which is new in the Vista and WinServer2k8 versions of MSMQ. It's really a shame because, honestly, this could've been implemented on MSMQ 3.0 just by using a separate queue instead of sub-queues.

Instead, we're stuck with the PoisonErrorHandler sample included in the SDK. The sample provides a way to mimic this behavior by introducing an IErrorHandler implementation that detects the poison message and moves it to another queue. To be able to do this, you need to set the binding properties so that the ServiceHost listening to the queue faults when the poison message is detected. The error handler then moves the message to a new queue and starts a new service host instance to resume processing of following messages.

The Sample itself isn't all that bad, but does provide insight into a rather significant feature left out of the way the Net.MSMQ Binding reports poison messages: All it provides the error handler with is the MSMQ LookupId of the poison message. Unfortunately, this LookupId is queue-specific and the exception does not provide information on which queue or at least which endpoint was the one that received the poison message, which is a huge gaping hole in this feature.

Because of that the LookupId is useless without more information provided out-of-band [1]. The sample works around this limitation by adding an entry in the <appSettings/> section of the app.config file with the path to the queue where messages are being received and the path to the queue to move poison messages to.

This works OK, until you need a single service host listening on multiple endpoints, and then the sample won't really work anymore because you don't know which of the endpoints caused the error.

Working around the limitation

I spent some time recently playing around with WCF and ran into this same problem, so I tried to find a way of working around this limitation and still use the basic functionality the sample provided.

I found one possible workaround, which seems to work so far in my limited tests. I'm not sure yet how well it will hold, as it seems to me there's always the possibility of some race conditions here, but let me illustrate at least the basic mechanics.

First we keep the basic code of the PoisonErrorHandler class. However, instead of using appSettings to keep track of the queue we're listening to, we just try to find out dynamically which endpoint configured for the service is causing the error, and extract the path to the queue from there based on the URI of the endpoint address.

To do this, in my implementation of IErrorHandler.HandleError() I grab the current OperationContext, reach out to the ServiceHost associated with it, and then iterate over the ChannelDispatchers attached to it. The one that's in the Faulted state is very likely the one that caused the MsmqPoisonMessageException in the first place.

Code could be something like this:

private String FindFaultedQueue() {
   ServiceHostBase host = OperationContext.Current.Host;
   Uri faultedQueue = null;
   // the queue that fired the exception will be the faulted one
   foreach ( ChannelDispatcher chd in host.ChannelDispatchers ) {
      if ( chd.State == CommunicationState.Faulted ) {
         faultedQueue = chd.Listener.Uri;
      }
   }
   // translate URI into a regular MSMQ format name 
   StringBuilder fn = new StringBuilder("FormatName:DIRECT=OS:");
   fn.Append(faultedQueue.Host).Append("\\");
   string path = faultedQueue.PathAndQuery;
   if ( path.StartsWith("/private/") ) {
      fn.Append("private$\\");
      path = path.Substring("/private".Length);
   }
   path = path.Substring(1);
   fn.Append(path);
   return fn.ToString();
}

This lacks some error handling and a few other things, but it illustrates the point. Now that we have the FormatName of the queue where the poison message came from, we can try to move it to the poison message  queue. We could handle this by convention: for queue Q1, the corresponding poison message queue could be Q1Poison. The rest of the sample is pretty much the same.

I probably wouldn't use this in production, as it doesn't feel very reliable given the basic limitations imposed by the WCF implementation, but it was interesting to take a stab at. YMMV.

[1] I'll leave to you, dear reader, to wonder about the sense of providing a sample that so clearly points out such a giant hole in a product feature rather than actually fixing it. Oh wait, guess they did fix it by changing MSMQ for Vista and WinServer2k8.

Technorati tags: , , ,

In Unix, it's common to name files and folders with names starting with a '.' to make them "hidden". This convention is not really needed in Windows, since there's a file system attribute for that, but still interesting.

See, a few tools ported from Unix that relied on this convention use a different one in Windows, replacing the '.' with a '_'. So, for example, your Vim settings file will be "_vimrc" instead of ".vimrc" and so on. Seems pretty obvious they did this because at some point in time file/folder names could not start with a dot.

Windows 9x probably had this limitation, and probably still lives on in FAT-based file systems (but I don't have one anywhere to test this assertion, nor do I particularly care about it). However, modern Windows and NTFS have no such limitation. Almost.

See, NTFS certainly let's you create a folder named ".vimfiles" or a file named ".txt" for that matter. You can do so programatically using the standard file handling APIs. You can do it from the command line using mkdir/echo.

But you can't do it using Windows Explorer. For example, Vista and WinServer2k8 will complain that "You must type a filename" if you attempt to name a folder/file with a dot as the first character in the name.

Why Explorer explicitly disallows it, I'm not sure, but seems pretty funky. There are probably thousands of applications or utilities out there that might get confused with a file or folder named like that, though.

Technorati tags:

I haven't noticed many issues with Vista SP1, despite some stuff I've read around; though overall haven't really noticed any significant performance difference besides file operations using Windows Explorer.

That said, I've noticed one nasty issue: I use an external USB drive that has a bunch of virtual machines, my music and other stuff. I'm usually very careful and always use the "Safely Remove Hardware" icon in the system tray to remove the drive before disconnecting it from the computer or turning it off.

However, ever since installing SP1, this operation fails about 50% of the time, saying the volume is in use and cannot be removed, even though there are no applications open that could be using the drive at all.

The past few times it's happened, I've fired up Process Explorer to try and locate what is holding on to the drive, only to find that the only process that has file handles opened in the drive is the "System" pseudo-process:

EjectDrive

No idea which driver is holding on to the handles, but based on the file names, I might guess it has something to do with the Kernel transaction manager and NTFS transactions. Why those handles are being kept there, I have no idea; but once this happens, those don't get released, meaning I have to shut down the drive improperly. Not good.

Technorati tags:

WinServer2k8

Am I the only one that thinks the Windows Server 2008 logon screen, with it's very simple blue background, is so much better looking that Vista's ugly and distracting "aurora" background?

There's just something highly appealing to me about keeping things simple and elegant...

Technorati tags:

Size of %WINDIR%\winsxs:

  • Clean Windows Server 2008 Enterprise installation: 2.6GB
  • Used Windows Vista SP1 installation: 6.52GB

I know that Side by Side installation is important for compatibility and serviceability, but this might just be going a bit overboard....

Service Pack 1 for Vista is now available for download from MSDN (I guess the Windows Update rollout will still wait to march or something). For some reason, though, it is a 434MB, 5-language pack.

I downloaded it last night and installed it this morning without too much fuss, except for Windows Live Messenger now keeps triggering Windows Installer on startup and failing (but it works after that, funky).

Haven't really noticed many improvements yet, though moving/copying stuff around in explorer seems quite bit faster (that alone might be worth it).

Technorati tags: