Shell Context Menu Slow to Open

Recently I've had a problem on my home machine where when right clicking on various shell items (not every shell item) could take 1-2 minutes to bring up the context menu. Explorer would go 'Not Responding', yet take up 0% CPU. Obviously something was blocking in Explorer, and I figured it to be one of my context menu handlers. Context menu handlers are buried within the registry in an expansive set of keys for literally every type of file system object on your computer. Locating every context menu handler is a tall order, but with a little help from Google, I found that NirSoft has an amazing tool called ShellExView which allows you to view all hooks into the Shell, and disable them en masse.

The first step I took was disabling every Context Menu and Property Sheet handler. Then I restarted my machine, and prepared to slowly re-enable them until I found the offending handler. ShellExView has a cool sort method to sort by company, which I tried first, but found no relief. Eventually I discovered that no matter how many things I disabled, my context menu was still slow as dirt.

Then I cut off my network card. Windows loves to take its time trying to find UNC paths--as you're well aware if you've ever mistyped a network share into Start/Run--so I chanced to gather that some shell verb pointed to something on a network path that was no longer there. Viola! Without a network connection my shell context menu's came up at regular speed.

How on earth do I easily find the culprit? There is some shell verb with a UNC path being referenced, and the Registry is a mighty large place. Once again NirSoft¹ came to the rescue with their Registry search tool RegScanner. Set it to search for "\\" and stand back for the deluge of UNC paths found in your registry. Open and delete² any branches that look like [Something\shell\*\command] and have a UNC path in the key. Mine was a program I used once on a Samba share that somehow made its way into my Open list.

Once I removed the offending key, it was back to business as usual.

1. nota bene: I did not intend for this to be a NirSoft shill post, but they really do have the two most useful tools for diagnosing Shell hook problems.

2. nota bene: if you aren't willing to live with toasting your Windows install, you may be inclined to export any keys you delete. I, however, am not so inclined.

MPICH.NT, MPICH2, and TCP Offloading (continued)

Well we tried updated drivers for the NC373i but with no avail. We were still seeing TOE errors which resulted in MPICH.NT and MPICH2 hanging. Luckily the machines have second NIC's, NC380T PCIe DP Multifunc Gigabit Server Adapters. Unluckily for us, those network cards exhibited the same problem as the embedded NC373i.

This leads me to believe that there is a problem with the Windows 2003 R2 Scalable Networking Pack. Specifically with the Chimney TCP Offloading portion. There may even be an issue in MPICH.NT and MPICH2 and Windows 2003 R2's SNP. However, that just seems highly unlikely as MPICH.NT and MPICH2 are wildly different under the hood.

We've initiated a case with Microsoft to get to the bottom of this issue. Meanwhile our new servers have TOE disabled, which isn't bad, but it isn't good either.

KB925902: X is not a valid Win32 application

Recently we've had a number of new hires and interns come in as the business expands and schools get out. They've been given new computers, Core 2 Duo's and Xeon 51XX's. Last week a few users reported no longer being able to run certain older applications. Windows XP SP2 stated that "X is not a valid Win32 application."

Yet earlier in the day or in the week they had been able to run the same executable without any issues. On my XPSP2 machine I could run the executables fine, and Win2ksp4 had no problems either. At this point a massive search for "what changed" began.

The executables were compiled on MSVS6 and Compaq Visual FORTRAN, so perhaps it was their newer processors coupled with the way the executables were compiled. Sure enough recompiling under MSVS8 or Intel Visual FORTRAN allowed them to run the executables. However, one of the executables still had a problem. Thankfully, we got a new error (I hate old errors):

XXXXX.EXE - Illegal System DLL Relocation
The system DLL user32.dll was relocated in memory. The application will not run properly. The relocation occurred because the DLL C:\WINNT\system32\HHCTRL.OCX occupied an address range reserved for Windows system DLLs. The vendor supplying the DLL should be contacted for a new DLL.

Lovely, a Windows OCX control bumped user32. A quick google search brought up KB925902 as the offending patch. I went to one of the machines to look for the patch, but it appeared from Add/Remove Programs that this patch was never installed!

Before giving up saying the patch is not installed, a useful thing to note is you can browse to %WINDIR% and take a look at all the NTUNINSTALL$KB* folders to see every patch that has been applied. This list is much more exhaustive than the Add/Remove Programs list.

Sure enough, there was %WINDIR%\ntuninstall$kb925902\, and after uninstalling the patch, everything was fine on these machines. I wonder what KB925902 could have possibly changed to cause such a colossal error.

MS07-017: Vulnerability in GDI could allow remote code execution

So, a security bug in the graphics subsystem gets a patch which affects the ability to run console applications? You should read the article on MS07-017 to get a feel for how many subsystems are affected by their patch. Thank you Windows for making my life so wonderful.

Drive Letter Economics

On Windows there is a fun property of the command line (not quite DOS) where you cannot change directory to a UNC path. This effectively makes it impossible to set your working directory to a UNC path from a batch file. To address this issue Microsoft has two methods of switching to a UNC path.

You can NET USE the path as a drive letter. However, you have to be sure that the drive letter you chose is not in use. When running in a large multi-user environment, you can see how this would become troublesome. More importantly, NET USE is semi-permanent, living for as long as the computer is on. You must unuse the drive letter assignment to free this up for other people.

Your other option is pushd which pushes a path name onto a virtual stack, making the path you specify the current working directory. If you pushd a UNC path, it is assigned a drive letter from the pool of open drive letters. Now, this too is semi-permanent (i.e. outlives the cmd instance it was done in). This assignment lives on until you unuse it or use popd. The more vexing part is on Windows 2000 Server these drive letter assignments affect everyone who uses the machine.

Let's say user A has a script that calls pushd without popd, if his script gets run enough times, eventually Windows 2000 Server machines begin running out of drive letters. So when user B's script runs on a machine without free drive letters, they are greeted with this fun message:

C:\>PUSHD \\machine\unc\path\here\
' ' is an invalid current directory path.  UNC paths are not supported.

Aren't you glad you get an error message which reflects the problem?

Now on Windows 2003 Server this problem is non-existent. Users can only muck up drive letter assignments for themselves, not for everyone logged in to a machine. However, upgrading production servers to another operating system is not always a valid fix. The problem does not go away, just users are insulated from other users.

The correct solution is to follow the best practices and have a matching popd for ever pushd call you make. Of course, it wouldn't be a best practice if nobody ignored it.