This is not really a Win32 Perl related blog entry, but a problem that my team recently experienced. I am adding this to our blog site with the hope that someone else experiencing the same problem may find it useful and (hopefully) save them some time troubleshooting.

Recently I ran into quite the system administrator emergency. Our Active Directory network started acting flaky. How odd it was that our servers were unable to talk with each other. Client machines were not able to boot onto the network. Attempts to access resources were confronted with ungodly long blocking wait times only to eventually fail.

Applications and services that normally execute flawlessly were suddenly cast into a bottomless pit of error massages such as:

There are currently no logon servers available to service the logon request


The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.

Of course the big question was why were there no logon servers available and why was there an attempt to compromise security? Needless to say it took several hours until my team could locate the root cause of the problem. Of course finding the cause is one thing, fixing it and understanding how the problem occurred is another.

Today I was debugging a problem with a script I was writing when I stumbled upon an interesting problem. The script takes data from my clipboard, processes it, formats an HTML report then creates an Outlook email message which it inserts the formatted report and sends it out to a list of recipients.

The script did everything that it should but ran into a problem when it called into the Outlook object model using COM. The standard way to instantiate a COM object is to first attempt to connect with Outlook if it is already running, otherwise run Outlook specifically for the sake of the script:

use Win32::OLE;
my $Class = "Outlook.Application";
my $Outlook = Win32::OLE->GetActiveObject( $Class ) || new Win32::OLE( $Class );
die if ! defined( $Outlook );

This is exactly where my script was failing. The calls into Win32::OLE would pause for several seconds but always return undef. How odd. Calling into Win32::OLE->LastError() to determine the error yielded an equally confusing error message:

0x80080005: "Server execution failed"

Of course there was no easy way to learn why the COM server execution had failed. Needless to say, after tinkering around a bit I discovered that if I first quit Outlook the script executed perfectly. It was only if I was running Outlook that the script failed. How odd.

So this entry isn’t about Perl but it is about a distant cousin, PHP, and the WordPress blogging software (v2.1+) spell checking bug that results in the notorious message:

Could not execute AJAX call, server didn’t return valid a XML

First let me start by saying that WordPress is a tremendous piece of software. I only have good things to say about it. Now that that is out of the way…

In WordPress v2.1+ there is a WYSIWYG option for writing posts, pages and comments. It isn’t full featured, but it is easy to use and provides the basics. It even includes a spell checker (which I am using as I write this). It is this spell checker that is causing so many people problems. When many people try to use the spell checker they receive the error message cited above. has a thread on this:

Having run into the same problem I decided to spend a couple of hours tracking down the problem and I can say that I have fixed it (on my system at least). My platform is running Windows Server 2003 with IIS and WordPress v2.2. I have patched my system and spell checker is working like a champ.

Along with Vista’s UAC security infrastructure Microsoft implemented something very clever, but has caused administrators and Perl coders frustration: User File and Registry Virtualization.

The concept of UAC (  is useful since it places finer control over what non-administrators can and cannot do. One of the core tenets of UAC is that a non-administrator should not be able to make changes that impact other users. For example if I make changes to an application’s settings they should only impact me, not other users of the computer. To accommodate this non-administrative access Vista virtualizes access by creating an alternate location for files and registry keys. The OS tries very hard to make this seamless so when an application tries to access a file or registry key it is redirected to the user’s virtual storage area.

In general this virtualization works, however for technical folk who want to access files directly they may be surprised to find the files are “missing”. Let say, for example, you want to manually edit an application’s configuration file. If the application was installed in the “Program Files” directory you may expect to find the file at C:\Program Files\MyApp\MyApp.cfg. But the file is really located in the path C:\Users\userID\AppData\Local\VirtualStore\Program Files\MyApp\MyApp.cfg.

Say what you will about Windows Vista but don’t think that it isn’t a big deal. Regardless of how you may feel about Microsoft, they put a lot of work into the Vista operating system. Sure the UI may not be as snazzy as Apple’s OS X and it is barren of some features from the promised land like WinFS. But there is an awful lot under the hood. Yes it is true that a Vista box really should have a recently upgraded machine to afford the resource costs the OS takes. But if you can afford the machine that runs the OS well rest assured that there are changes worth having. The problem that Microsoft faces is that these changes are not easy to quantify for the average consumer. How would you explain to your Mother about the benefits of the new media APIs? Or try convincing your boss to upgrade the entire IT department so that your machines could leverage PnP-X and Function Discovery. No, the innovations that underline the OS are not obvious to the layman. However there is one exception: security. 

Among the various annoying aspects of running x64 versions of Windows (XP or Vista) is that the registry is split into two sections: x64 and x86. When 64 bit applications access the registry they do so directly, as you would expect. However if a 32 bit application access the registry it is mapped into a special 32 bit section.

Scripts that interact directly with the registry may yield unexpected results if you are running a 32 bit version of PERL.EXE on a 64 bit version of the operating system. More details can be found in Microsoft’s KB article 896459:

For those not following Seattle news, we had the biggest wind storm since 1993–most argue it was stronger than that. Winds were clocked up to 90 MPH. Needless to say it knocked over trees and power line poles. Over 750,000 people were left in the dark for several days.

The Roth Consulting labs were offline 6 days. During this time the forum, blog, web, ftp and email services were down. We apologize for the inconvenience, but just like code, life has bugs.

Over in the RC forums ( someone posted about having problems with Crypt::SSLeay on a Windows server. Of course I was curious so I started digging and uncovered an interesting blog entry from Brian Kelly over at He explains why ActiveState does not offer the standard encryption extensions either by default or in their online repositories. It is worth a quick read:

My tech editor recently pointed out something that I found quite astonishing about the Win32::TieRegistry. If you are not familiar with this extension, it is quite useful: by tie-ing a hash to the Windows registry it is quite simple and easy to access registry hives, keys, values and data–as easy as using a simple Perl hash.

This extension is a Godsend for everyone who has have never programmed to the Win32 registry APIs or used Perl’s Win32::Registry (which pretty much mirrors the Win32 registry APIs). The registry APIs are not the most intuitive, even though they are logical (once you bother to learn them).

But what amazed me was that Win32::TieRegistry makes some pretty vast assumptions about permissions. As he explained to me, when you load the extension in your script it attempts to open the registry with read and write privileges. This is fine if you are running a script as an administrator or only accessing keys that you have been granted such permissions. But if you are not an elevated user then attempts to only read keys, values and data will fail — without tripping a fault or some kind of noticeable error.

One of the annoyances that Win32 Perl bothers me with is the lack of traversing the PATH. There are some Win32 specific functions built in such as Win32::GetFullPathName() and Win32::ExpandEnvironmentStrings() which are very useful when dealing with Windows’ paths, but suck when dealing with a PATH relative file.
For example, if you have a path like "rundll32.exe" there is no way for Perl to easily determine that this represents c:\Windows\System32\RunnDll32.exe. This should be pretty simple to do since "%SystemRoot%\System32" listed in the PATH variable by default. The closest Win32 Perl comes to solving this is to use Win32::GetFullPathName(), but this would prefix the file with a path based on the current working directory (from Win32::GetCWD()), not traverse the PATH looking for a file match.
It is too bad that there isn’t a simple solution to this. However, until the day when such functionality is added to Win32 Perl you can use the script in our Perl Script Repository called which does traverse the PATH looking for files: