Data Centers

SolutionBase: Discover Windows problems specific to 64-bit systems

Intel and AMD have recently started shipping 64-bit processors, and Microsoft has released a 64-bit version of Windows. Eventually, you'll wind up running 64-bit systems in your own environment. Here are some of the pain points you may encounter.

Now that Microsoft has finally started shipping 64-bit operating systems and that computers with 64-bit processors have prices similar to their 32-bit counterparts, you might be tempted to make the transition to 64-bit computing. Before you do though, you should know that not everything works the way that you might expect in a 64-bit environment. There are a number of issues that are specific to 64-bit versions of Windows. Some of these issues have workarounds, and others you will just have to learn to live with. In this article, I will explain what type of issues you can expect to encounter as you make the transition to 64-bit computing.


The first issue that I want to discuss has to do with dial up networking. If you attempt to dial into a RRAS Server, you may receive an Access Denied message even if you have entered the correct credentials. This issue tends to occur if the network that you are dialing into is using a third party RADIUS server to authenticate the login (rather than Microsoft's Internet Authentication Service), and the machine that you are attempting to login through has cached credentials.

The trick to getting around this issue is to force Windows not to cache authentication credentials. To do so, use the Windows search tool to locate the phonebook file that contains the entry for the network that you are trying to connect to (you can search on *.PBK). Once you locate the phonebook file, open it in Notepad. Now, locate the following entry:


Change this command to:


Save your changes and close Notepad. The change that you have made will prevent Windows from using cached credentials when dialing into the remote network. This should allow you to login to the remote network.

DNS problems

Another common networking related problem is that Active Directory related functions may not work. As you may know, the Active Directory is dependant on the DNS services. If the DNS services are not working, then Active Directory connectivity is impossible.

With this particular problem, the domain controllers and the DNS servers are not to blame (assuming that they are working for 32-bit clients). Instead, the problem is related to a particular set of registry entries on 64-bit clients that has a tendency to become corrupted. To correct this issue, you will have to delete the corrupt entries and then recreate them. You will then have to stop and restart the Net Logon service. Before I show you how to perform these tasks, I need to point out that modifying the registry is dangerous. Making incorrect registry modifications can destroy Windows and / or your applications. You should therefore make a full system backup before continuing.

Open the Registry Editor and navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters. Once you have selected the Parameters container, you must locate and delete the Domain, Hostname, NV Domain, and NV Hostname keys. After deleting these keys, you must create four brand new keys named Domain, Hostname, NV Domain, and NV Hostname. After creating the new registry keys, you must assign some values to them. For the Domain and NV Domain keys, you will enter a string value that contains the domain name in format. For the Hostname and NV Hostname keys, you will create a new string value and enter the computer name. For example, if you had a computer named Posey in the domain, then the Domain and the Domain NV keys would be assigned the value The Hostname and NV Hostname keys would be assigned the value Posey.

ATM errors

So far I have discussed some minor network related glitches that have easy work arounds. There are however at least two network related issues that are more serious. One issue pertains to computers that use Asynchronous Transfer Mode (ATM) for network connectivity. Computers running 64-bit versions of Windows lose their ability to establish an ATM connection. At the moment, Microsoft does not have a fix or a workaround for this problem. According to my sources, ATM will eventually be supported, but at the current time it does not work due to an unknown bug.

Hardware detection

Another issue that's not quite as severe, but that effects more people is that during installation, Windows may fail to automatically detect the machine's NIC. Furthermore, you may be unable to manually install the device driver for the NIC once the installation completes. The reason for this problem is that when you are running a 64-bit version of Windows, any components running at the kernel level must also be 64-bit. As you might have already figured out, device drivers are kernel level components.

The only solution to this problem is to contact the NIC's manufacturer and obtain a 64-bit device driver. If the NIC's manufacturer does not offer a 64-bit driver then you will have no choice but to either buy a NIC that does offer 64-bit drivers, or you might be able to get away with using the network interface that's built into the computer's system board. If you decide to use the integrated NIC, you will still need a 64-bit driver, but that shouldn't be a problem since the NIC is a part of a 64-bit system board.

Other device driver issues

As you may know, device drivers are based on .INF files. When Microsoft released Service Pack 1 for the 64-bit version of Windows Server 2003, they changed the INF file syntax requirements. As such, device drivers that worked previously may not function once Service Pack 1 (or later) is applied. This change does not effect 32-bit versions of Windows.

The change has to do with decorated device drivers. Device driver decoration was something that Microsoft quietly slipped into the device driver format when they released Windows XP. Although Windows XP and Windows Server 2003 have both supported decorated device drivers for years, device driver decoration was never actually required. The idea was that by not making driver decoration mandatory, Windows would be able to use device drivers that were written for older versions of Windows.

So what is a decorated device driver anyway? If you've ever looked at an INF file, you know that it is divided into various sections that are designated by the section name in brackets. An example of this would be the Models section, which is designated as [Models]. Each section contains a number of assignment statements that specify the way in which the device should interact with the operating system. Decorating a device driver refers to adding a line to the [Models] section and to the [Manufacturer] section of a device driver that designates what operating system the device driver is intended for. The decoration name is TargetOsVersion. The TargetOsVersion variable can be set to either .ntia64 for 64 bit Intel systems or to .ntamd64 for AMD systems

The way that Windows enforces device driver decoration is actually a little strange. As I mentioned earlier, 32-bit systems are not effected. A 32-bit system can install a device driver whether it's decorated or not. If you visit the Microsoft Web site, you will see that the very first line of text on the page says "Microsoft Windows Server 2003 SP1 and later versions of Windows do not install driver packages with undecorated INF sections on x64-based systems." However, the very next line of text goes on to say "For compatibility with Intel Itanium systems, Windows Server 2003 SP1 will install driver packages with undecorated INF sections; however, INF decorations are required by the "Designed for Windows" Logo Program for Hardware, so a driver package with undecorated INF sections cannot qualify for the Logo." Basically, it seems that what Microsoft is saying is that at the present time, the decorated file requirement is only being enforced for 64-bit AMD systems.

The reason why Microsoft has decided to begin enforcing the driver decoration requirement is because of an effort to bring down support costs. Consumers don't necessarily know what versions of Windows a device driver is designed for. If a consumer were to install a device driver that was inappropriate for their operating system, the results would be unpredictable. It is a lot easier to prevent the incorrect driver from being installed in the first place than it is to clean up the mess made by the driver. Decorating drivers insures that the driver can only be installed on its intended operating system.

So what does the device driver decoration requirement mean to you? It means that you won't be able to install any new device drivers unless they have been decorated. It also means that if you were using a pre-SP1 version of Windows Server 2003, that some of your device drivers may cease to function once Service Pack 1 is applied.

There is also a bug within Windows Server 2003 SP1 that can cause problems with undecorated drivers as well. As you probably know, the Windows Setup program contains an option that allows you to press the F6 key and then load any necessary mass storage device drivers. However, there is a bug in the Windows Setup program that will allow you to load mass storage device drivers whether they have been decorated or not. The problem is that the next time the system reboots, Windows will produce a Bug Check 7B error. The reason for that is that Windows now detects the undecorated device driver and produces an error as a result. Of course if the driver that you loaded after pressing F6 was decorated, you would never receive this error.

If you've got a lot of driver files that you rely on, having to find new decorated versions can be a royal pain. As I mentioned earlier though, an INF file is nothing more than a text file, and text files can be edited. It is possible to manually decorate a device driver yourself. By doing so, you don't have to worry about tracking down new versions of the driver. You can find some references to manually decorating device drivers on Microsoft's Web site.


Although most of this article has been devoted to discussing networking and device driver related issues, there are also a couple of printing issues that you may encounter when you transition to 64-bit systems. The first issue that I want to discuss has to do with print drivers being updated. Normally, if a server is hosting a network printer, then workstations will automatically download the print driver from the server the first time that they attempt to print to the printer. If the server's print driver is updated, then the workstations will automatically download the updated driver the next time that they attempt to print to the printer. The updated driver will simply overwrite the workstation's existing print driver.

That's how network printing is supposed to work in a Windows environment. However, if you are hosting a network printer off of a cluster of 64-bit servers, then there is a bug that may prevent workstations from acquiring updated printer drivers from the cluster. There are three different ways that you can get around this problem, but two of the tree methods have some negative implications from a security standpoint. Those methods involve either adding the user's account to the domain's Printer Operators group or adding the user's account to the cluster's local Power Users group. If you are having this problem and you would rather not jeopardize your network's security to fix the problem, you can usually get around the issue by deleting and reinstalling the print driver on the server.

The other printer related issue that you might encounter has to do with printers that are hosted by non-Windows systems (Linux, NetWare, etc.). Users of 64-bit systems may find that when they attempt to print to these printers, that the print jobs come out incomplete. For example, watermarks may be missing.

This problem occurs because Windows systems spool print jobs in a raw data format. Normally, the machine that hosts the printer contains a print processor. The print processor takes the raw data and converts it into the job that is eventually spooled to the print queue. If the printer is hosted by a non-Windows system though, there is no print processor. Therefore, raw data is transmitted directly to the print queue and anything that the printer doesn't natively understand is not printed.

Since 64-bit Windows systems have trouble determining that a printer is hosted on a non-windows system, you can get around this problem at print time by clicking the Advanced button and then selecting the Print Directly to Printer check box. This will cause the system to act as its own print processor and spool a complete print job to the print queue.

Not quite ready for prime time

As you can see, the 64-bit versions of Windows are anything but perfect. As with any new technology, there are some kinks that will need to be worked out. As more people transition into 64-bit systems though, it is inevitable that the bugs will gradually be corrected.

Editor's Picks

Free Newsletters, In your Inbox